[Fwd: Re: The store interface]

Duanes answer, which he sent to squid@ircache.net and not squid-dev.

/Henrik

    [ Part 2: "Included Message" ]

Date: Fri, 11 Jun 1999 20:52:16 -0600
From: Duane Wessels <wessels@ircache.net>
To: Henrik Nordstrom <hno@hem.passagen.se>
Cc: squid@ircache.net
Subject: Re: The store interface

Henrik Nordstrom writes:

>I looked again at the new store I/O interface, and one important thing
>struck me:
>
>It should be up to the filesystem to determine what the sfileno should
>be. The sfileno is really filesystem dependent piece of information, and
>should be handled at that level. Also required for filesystems where
>sfileno is a non-linear space (for example in direct relation to disk
>location, where a single object may occupy multiple sfileno locations)

The swap file number is unrelated to the filesystem layout. There
is a one-to-one relationship between a StoreEntry and a swap file
number. Thus, a single object may not occupy multiple sfileno locations.

The swap file number is an index to the filesystem "directory." That
directory can specify which "block numbers" or filesystem units are
occupied by that file number.

>
>Proposal for callback notifications:
>
>CLOSED: The file is now closed. Also tells the sfileno assigned to the
>file.
>
>ERROR: An error occured. File is closed and possibly removed.
>
>SFILENO_CHANGE: The file has been assigned a sfileno to be used in
>successive open requests. This may be indicated at any time the file is
>open.

This is a significant change because now a swap file number can
be in three states: unused, used, and maybe-used.

>And a possible extension: (see also below)
>FILESYS_UNSUITABLE: The filesystem beleives this file is not suitable to
>be stored in this filesystem, and should if possible be moved to another
>filesystem.

That may be a desirable feature, but I don't think it belongs as
a callback. Surely that can be done at the time when the swap
directory is selected, before a swap file number is allocated.

>Filesystems who may allow both reading and writing simoultaneously can
>use SFILENO_CHANGE to tell this to the store manager. Filesystems not
>capable of supporting readers while the file is being written don't.
>SFILENO_CHANGE can also be used if a "swapin"-time optimisation decides
>that the file should be moved somehow (it is up to the filesystem to
>take care of multiple readers).

I think it would be better to require the filesystem to support reading
and writing at the same time.

If not, you only have to return an error for the read open and
then the client-side gets a SWAPFAIL_MISS.

>
>Also, it would be very nice if open could be told the estimated file
>size when it is known (content-length available, or object fully in
>memory before being swapped out).

thats easy.

>Ideally the whole store maintenance should also be pluggable, preferably
>interconnected with filesystem types. I'll try to draw something up
>during the weekend (I will spend a lot of time on trains travelling and
>need something to do). What I will do is probably to split the store in
>access methods and maintenance, where the access methods talk to the
>filesystems, who talks to store maintenance. This is a requirement for
>efficient implementation of my "log baced cyclic filesystem with some
>LRU properties" store design, and many other approaches may benefit from
>it as well.

ideally.

Duane W.
Received on Tue Jul 29 2003 - 13:15:59 MDT