The store interface

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)

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.

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.

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).

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).

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.

/Henrik
Received on Tue Jul 29 2003 - 13:15:58 MDT