Re: store module abstractions

>>> "Robert Collins" wrote
> I need to get my hands dirty on this to answer. You've probably got a better
idea about it than me.
>
> I had vague thoughts along the line of
> storefs - physical layout of the store & rebuild logic & metadata logic
> storeio - o/s level calls to read/write/create/delete.

This _does_ run straight into the work Adrian's doing on modio, so I might
withhold from commenting _too_ much until he chimes in ;)

However, I'll foreshadow some problems with any of these splits - fs'es like
reiser and sfs throw spanners in the works be trying to implement everything
themselves or trying to reach into the guts of how squid maintains it's own
list of available files.

My preference at the moment is a very thin layer implementing store* calls -
storeDirRebuild, storeRead, storeWrite, storeUnlink, etc. - and then some hard
thought about a good interface for it to talk to reiser/sfs/coss/ufs. It'd be
nice to raise async up out of the bottom layer, so fs'es can be given
async-ness in a braindead manner, but I suspect that only applies to ufs -
sfs implements async-ness itself, for instance.

modio is supposed to be providing us with a standard way of feeding the data
from the fs back up into squid - that will help immensely in defining what
layers should exist, I'd envisage the storeRead/storeWrite interface would
manage a lot of that. However, that may lead us toward excessive memcpy'ing
to bring the data back up (or down, for writing).

If you're not planning on diving in immediately, then I'll keep prodding at
sfs with a view to understanding how it works currently, and keep hassling
Adrian to gimme more info about the data path for modio wrt fs ;)

KevinL
Received on Sun Feb 18 2001 - 00:01:18 MST