Re: store module abstractions

----- Original Message -----
From: "Kevin Littlejohn" <darius@bofh.net.au>
To: <squid-dev@squid-cache.org>
Sent: Sunday, February 18, 2001 4:33 PM
Subject: 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)
>
>

Yes - thats where I'm heading with this. Basically a set of low level i/o routines to make porting the different store layouts
(storefs) to different o/s's much easier.

Rob
Received on Sat Feb 17 2001 - 22:36:03 MST