Re: store module abstractions

>>> "Robert Collins" wrote
> Hi,
> I've been thinking about the store modules recently (toying with the idea
 of a native win32 store module - to further integrate
> romeo's NT port with the main codebase, and doit cleanly :])
>
> It occured to me that we really only have 3 store modules at the moment (not
counting new under dev stuff):

;) sfs is on hold pending the current round of modio changes - we kept
running into awkwardness in trying to make it talk nice with squid.

> NULL, COSS & "local filesystem". The "local filesystem" happens to come in 2
async flavours "aufs" & "diskd", and "ufs" which is
> synchronous.
>
> I'd like to propose that we turn the current 2 level abstraction of "store" &
 "fs" into a three level abstration: "store" &
> "storefs" & "io".
>
> Then the majority of the duplicate code that implements the store logic for t
he "local filesystem" store becomes a module, and the
> i/o calls that are the real difference between diskd & async & ufs can be spl
it out.

Adrian, this is part of the stuff we talked about re: storeRebuild and
similar, yeah? There is duplicate code there, really the bits that talk to
the actual drive should have a clear interface, the rebuild and similar logic
should be shared, and should present a single interface to squid itself.

Ah - except reading on in your post, you're suggesting a common interface
_below_ the fs module. I'd be wary of that - some fs'es (reiser, fi) may
implement themselves in kernel on some platforms, hence have a different more
efficient way of operating, I'd imagine. Loosing that would be unfortunate.

I _think_ that's what you're referring to, I'd be very interested in taking
this on myself (as it leads directly to being able to make sfs work). If you
do branch it out, can you let me know if/where I can help? I'm more than
happy to bog into asyncio/ufs/diskd code - I've been there once long ago with
Stew, it's fun code to work with :)

KevinL
Received on Sat Feb 17 2001 - 21:44:21 MST