store module abstractions

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):
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 the "local filesystem" store becomes a module, and the
i/o calls that are the real difference between diskd & async & ufs can be split out.

Benefits:
The split out modules should be a lot smaller.
Code that is duplicated across ufs/aufs/diskd will now longer be duplicated.
Writing new platform specific modules becomes a lot easier. I.E. Win32 / OS/2 / pickanewioplatform- ie do sun have a high perf io
library ?

Downsides:
The currently trivial ufs code will become a little less efficient because it will always be acting as though the io is
asynchronous.

Possible benefits:
if done right, the low level calls could also be used to implement the i/o in things like coss, allowing different storefs types to
benefit from platform specific tuning without recoding.

I'm willing to give this a shot on my openBSD machine if it sounds sensible. New branch time for this I think.

Rob
Received on Sat Feb 17 2001 - 06:22:37 MST