Re: store module abstractions

>>> Kevin Littlejohn wrote
> 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.

Ignore me. sfs implements it's own open/read/write/close, so in that respect
it can be treated as per a kernel module for fs. Leaning it on other storefs
modules would thoroughly defeat the purpose. But it also implements the
callbacks/cbdata handling/async-ness that ufs/aufs implement for squid - the
store_fs_io.c layer. Those would, I guess, have to be split off and
replaced by ufsio/aufsio. We walked this road once before tho, didn't we?
The original spec for the fs stuff has detail on open/read/write/close
operations, but we're duplicating code in store_fs_* and store_dir_* - so this
would move that code out into a "storeio" module.

KevinL
(thinking (slowly) out loud)
Received on Sat Feb 17 2001 - 22:33:29 MST