RE: storeGet() -> storeGetPublic() ?

From: Alex Rousskov <rousskov@dont-contact.us>
Date: Tue, 9 Jan 2001 00:01:14 -0700 (MST)

On Tue, 9 Jan 2001, Robert Collins wrote:

> This raises a question: are digests an aspect of FS state, or an aspect
> of cache state?

Cache digests represent cache state. FSs are free to have their own
digests, invisible to the rest of the Squid, of course.
 
> The digests sent from cache to cache certainly are, but they are rather
> trivially generated by combining the (hypothetical) digest for each FS
> using binary OR.

Sure. As I have said, everything can be implemented (let's ignore
the complexity for now; I think Henrik already raised some of the
reasons why digests merging is not that trivial).

Ideally, the cache should not know anything about FS digests though.
Whether it is a FS (or some other "global" module) that maintains
per-object hit/miss and expiry information is a design decision.
Clearly, maintaining global state is easier (it is already
implemented) but is more expensive compared to what some FS can do.

> I don't believe that allowing FS state to be presented in digest format
> is all that low level an optimisation. Certainly all the in-memory
> indexs used by ufs/aufs/diskd at the moment will need common digest code
> - perhaps a libmemdigest.a?

The problem with this "library" approach is that it is difficult to
abstract enough of the common code when you have a variety of FSs.
IIRC, there was already a discussion about some code being repeated
(with minor variations) in most FS modules...
 
> Requiring digests to be generated from on-disk metadata would be a low
> level optimisation - but that is not the goal as I understand it.
>
> I agree about deciding where you are going, but IMO this change does
> _not_ tie squid to either of the options you have presented above. It
> does mean a little more effort is needed to create a new FS, but given
> the common code can be grouped together when this change occurs, that
> extra effort would be around 20 lines of code. Copied from ufs.

If all the changes discussed on this thread are specific to, say,
reiser-fs module, then I was worried for nothing. If, however, every
FS will now have to support some kind of a digest, then I may be
right. What starts as 20 lines in UFS may quickly become a (100
similar lines * 10 modules) mess just to gain the most from the
reiser-fs.

Alex.
Received on Tue Jan 09 2001 - 00:01:23 MST

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:13:14 MST