Re: store module abstractions

>>> "Robert Collins" wrote
> ----- Original Message -----
> Right. That sounds like what i'm talking about. That layer is async itself.
> It *should not* intergace to reiser/coss IMO. They don't have process's anala
gous to dirRebuild do they?

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.

Note, applying async to a filesystem that doesn't expect it is not as trivial
as it sounds - at the very least, you'd be asking for each fs to implement
identical open/read/write/close-type functions that async can work around
before having an "async" module is worthwhile, and that proves more difficult
than you'd expect. So the aufs stuff is very ufs-specific.

KevinL
Received on Sun Feb 18 2001 - 01:41:48 MST