Re: storeGet() -> storeGetPublic() ?

On Sun, Jan 07, 2001, Henrik Nordstrom wrote:
> Alex Rousskov wrote:
>
> > I am afraid your change will effectively disable Cache Digests. It is
> > probably prohibitively expensive to generate digests from scratch if
> > every object's meta-data has to be read from disk.
>
> Any change which moves away from having a full in-memory store index
> makes it quite inpractical to maintain cache digests.
>
> Adrian:
>
> It is not that easy to move digests to the FS layer for the purpose of
> digests. In order to support cache digests (between caches, not
> internal-only) the digest building routines must be able to walk the
> store index in a reasonably efficient manner, getting the MD5 hash and
> expiry time of each object, and to get notifications on
> addiditons/deletetions (not used today IIRC).
>
> Having something digest-like internally to speed up index checks on
> misses is an entirely different matter.

Ok, good point. I was planning on having each FS export a cache digest,
but this may be impractical for some filesystems. Instead, what could
happen is that each FS *could* export a cache digest, for example the
reimplementation of ufs/aufs/diskd will require an in-memory index
anyway, so building a digest from that shouldn't be terribly difficult.
Something like reiserfs_raw might not be so easy because the index
is on-disk.

In this way, cache digest building becomes part of the FS rather than
squid, and if the administrator chooses to use a FS which doesn't build
a digest then he doesn't get them.

I'm all up for suggestions here. :)

Adrian

-- 
Adrian Chadd			"Here's five for the cake, and
<adrian@creative.net.au>	  five to buy a clue."
				    - Ryan, Whatever it Takes