Re: store module abstractions

>>> "Robert Collins" wrote
> I envisage the follow modules to start with:
> storefs - coss, ufs, null, sfs, reiserraw
> storeio - ufsio, aufsio, diskd

Ok, that makes a lot more sense to me. Does it boil down to storefs
implementing open/close/read/write/mount/umount, and storeio implementing the
various callbacks etc to handle opening/reading/cbdata-type things, plus the
storeDirRebuild-type functions - basically, what's in, um, store_dir_fs.c and
store_io_fs.c?

sfs is kinda an interesting one as far as where it sits - it implements
async-ness itself atm, but also implements the "physical" layout of the fs. I
guess theoretically it could be used under aufsio or ufsio, but it would have
to be breaking the requests into blocks and scheduling them itself - hrm.
That gets kinda wierd. Lemme think more about that - it might mean
everything's done SYNC in sfs, and the async handling moves up to aufsio. But
I've got this niggling feeling that the async stuff isn't cleanly applicable
to different fs'es, for some reason - something to do with scheduling
strategies for the actual block operations.

> with coss utilising ufsio/aufsio/diskd on appropriate platforms
> and ufs utilising ufsio/aufsio/diskd on appropriate platforms
> and null using no storeio module
> and sfs using ?? (what is special about sfs - it's a kernel fs module using t
he standard io interface, but tuned for squids read
> write pattern & allowing metadata to reside in inodes yes? I'm guessing it ca
n be accessed via ufs/aufs& diskd easily enough. I also
> think it needs it's own storefs level module because rebuilds etc will be ver
y different for it.)

Um. sfs is not kernel level - it's userspace, it basically opens a block
device and builds it's own fs there (simplest cross-platform approach). It
holds data in inodes tho, yes, and it could lean on any of the storefs
modules, I guess, given it's using open/read/write/close for disk access now.
But as I say, I'd worry a little about taking the async stuff out of sfs.

> Cool. Well given the plethora of new modules it's introducing, I'd like to ma
ke it depend on the generic module work I'm doing..
> (but I haven't heard any feedback on that yet ...)

I was gonna take some time out and make sfs use your module stuff - saw the
cvs updates go through the other day - but, well, um, my SO and I bought
EverQuest, so gimme a day or two ;) Seriously, cleaning up squid's disk
interface is where I want to be pitching my help, I'm just loathe to go
jumping in myself, especially atm when Adrian's busy changing things from
underneath... ;)

KevinL
Received on Sat Feb 17 2001 - 22:23:37 MST