Re: The store interface

>>> Henrik Nordstrom wrote

[snip]

> I think it is reasonable to expect that the FS-dependent code should be
> able to give each stored object a unique integer and find some method to
> map this to a on-disk location (filename for UFS, disk block for a block
> based filesystem like COSS, something else for another kind of
> filesystem).

Note, on the squidfs code I've got (which the company, in their infinite
wisdom, have scheduled me to work on early August *sigh*), file 'name' is
not known until _after_ file is opened - as any identifier for any file is
allocated by the fs-specific code on opening. For me, it makes more sense
to follow Henrik's suggestions.

> To do this cleanly sfileno should be separated into it's two components:
> cache_dir and filenumber. The high level code selects the cache_dir
> component, and the low level FS-dependent code selects the filenumber
> component.
>
> Oh, yes there is yet one more change I feel is needed to the store-io
> interface. The "methods" should know which StoreDir the are being called
> on, preferably by being passed a reference to it ("this" when using
> C++).

Yeah, I was just starting to wonder about that - the code I have is
part-converted to this new method, and I was just running into 'ok, so
which fs is this on?' issues.

I'll note also, though, that using the high byte of a ulong to identify
which cache_dir should be used seems to be a valid approach - depending
on various limitations for number of files per cache_dir, number of
cache_dirs, etc ;). Passing CacheDir, as mentioned below, would seem to
make more sense tho.

[snip]
 
> * Not all filesystems can support readers while writing a object,
> especially not during the early phases of development. Support for this
> should be optional, and can be supported by either revert to VM object
> model if the filesystem code does not support readers while writing, or
> deny additional readers during writing by keeping the object private
> until readers can be supported (the latter preffered by me, the first
> requires less changes).

I'll vote for latter also - if we can't read something when we're writing
it, then 'store_swap_fail' seems appropriate? I haven't looked at what
this does to neighbouring, etc, though - when do I announce I have
a given object?

> * When sfileno has been separated into it's two separate entities, the
> store-io interface should change to one more like a traditional
> object-oriented interface, i.e. instead of receiving a sfileno which
> (amongst other things) indicates cache_dir number it should receive a
> reference to the CacheDir the call operates on (preferably as first
> argument to all methods, to mimic the C++ call interface). This futher
> isolates the FS-dependent code from the rest of Squid as it now does not
> need to know where Squid keeps it's configuration details.

Hrm. That seems to make sense. 'course, that could be the coffee talking
;)

KevinL
Received on Tue Jul 29 2003 - 13:15:59 MDT