Re: store module abstractions

Kevin Littlejohn wrote:

> Most fs'es have _something_ akin to storeDirRebuild - that function checks the
> filesystem itself and extracts info about what files live where. The only way
> an fs might not have storeDirRebuild would be if it mapped url's directly to
> fs "handles" - so you could ask the store to open a url instead of a filename/
> indoe number/whatever. Even then, you need to support
> storeDirRebuildFromSwapLog, if only as an equivalent of "ls -l" :) Unless you
> planned on replacing even the internal list of cached data with your own
> structures... But that'd be undoing a whole batch of interface work/specs.

The responsibility for managing the indes of what files are in the cache
is being moved down to the FS/store layer, and support of retreival of
this index will be optional (today only required for cache digests).
This is move part of "modio round 2".

stores not implementing index retreival naturally cannot parcipiate in
functions requiring it (i.e. cache digests).

reiserfs_raw is a good example where this move is required. reiserfs_raw
does not really know what is in the cache until it is requested, and the
FS I/O layer does not allow for retreival of the cache index.

More stores sharing these properties will appear within the year.

This move is required to make the cache store scale on disk size, memory
efficiency and speed. Different approaches will suit different goals for
these parameters.

/Henrik
Received on Sun Feb 18 2001 - 04:14:07 MST