Robert Collins wrote:
> This raises a question: are digests an aspect of FS state,
> or an aspect of cache state?
You can have digests for both, but the application and contents of the
two would probably be quite different.
The cache digest is for exchanging cache information between caches.
This needs to be
* compact
* only include fresh information
The FS digest typically has a completely different application,
screening which lookups needs to hit the FS metadata.
* does not need to be very compact
* should include all objects
> 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.
The only benefit from having the FS:es generate separate digests which
are then OR:ed together is that you can easily remove FS:es from the
published cache digest. This won't however solve the issue that the
cache digest needs to represent freshness.
> 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.
As shown before the information needed to correctly build cache digests
are the independent of the FS implementation. So all the FS:es should be
required to implement is the data feeds needed to generate cache
digests. To be flexible two different data models can be supported:
a) Index retreival
b) Staleness notifications
However, the method using staleness notifications is far from trivial.
There are big complications both in the cache digest generation (how to
represent freshness in a digest), and in how to manage the needed
information in the FS. It is most likely simpler to implement the index
retreival in any filesystem than trying to keep track of freshness
without having a easily retreived index..
/Henrik
Received on Tue Jan 09 2001 - 17:35:30 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:13:16 MST