RE: storeGet() -> storeGetPublic() ?

From: Robert Collins <robert.collins@dont-contact.us>
Date: Tue, 9 Jan 2001 17:26:20 +1100

> -----Original Message-----
> From: Alex Rousskov [mailto:rousskov@measurement-factory.com]
> Sent: Tuesday, 9 January 2001 4:59 PM
> To: Adrian Chadd
> Cc: squid-dev@squid-cache.org
> Subject: Re: storeGet() -> storeGetPublic() ?
>
>
>
> On Mon, 8 Jan 2001, Adrian Chadd wrote:
>
> > So, why not just make digest building part of the FS?
>
> I think this is a design issue. Both FS-based and global-hash based
> designs are possible to implement. Which one is the best? IMHO, it
> depends on what Squid is (or supposed to be):
>
> * If Squid should be highly optimized using a very specific low-level
> architecture (e.g., reiser-fs), then digests can be merged with FS
> level. When one is striving for the "last mile" of optimization,
> everything tends to be "integrated". In the extreme case, every new
> protocol can be supported by adding an extra spoon of spaghetti.
>
> * If Squid should be a portable, general-purpose, "reference
> implementation" of a cache as well as a playground for new caching
> ideas, then, perhaps, low-level optimizations with side-effects should
> not be allowed to take over the rest of the code. That is, cache
> inter-communication should remain separate from storage module. In the
> extreme case, if the next level of optimization requires merging of
> logically-separate modules, that level of optimization should not be
> allowed.

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

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.

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?

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.

Rob
Received on Mon Jan 08 2001 - 23:30:05 MST

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