Re: Store I/O interface

I am now working on a remodelled interface, in line with what I wrote
earlier and the discussion we had some time ago.

In short:

* Open operation split in three different operations
  - Open fileno for reading
  - Create a new object
  - Open a read handle from a existing handle
* fileno assignment will be done at the filesystem level to allow the
filesystem code to use the StoreEntry hash table as directory structure.
The Create method has a additional callback argument where the assigned
fileno is announced from the filesystem code to the higher levels
sometime while the object is open.
* The interface to the filesystem specific methods is extended to pass
the SwapDir structure as a initial first argument on all methods.
* swapfileno is masked to only include the FS-specific part when passed
to FS specific code.
* Size hints on Open and Create methods (exact on Open, expected to be
on Create).

I will present the updated code and Programmers Guide sometime during
this week.

After these changes the interface will allow me to begin experimenting
with some of my filesystem ideas, and I hope to get time next weekend to
begin some work in that area.

The next issue needed to be addressed at the interface level is store
maintenance. Some of my filesystem ideas involves storage management, so
after the initial experiments with a custom filesystem I will begin
looking at breaking out the store maintenance and how to move it closer
to the filesystem code, preferably pluggable per cache_dir in a similar
fashion like the disk I/O.

I will also look into disk cache state management, i.e. how the on-disk
cache state index is handled and transaction logged. It should be
connected to object creation & unlinking rather than handler separately.
The way I will do it is probably by sending the needed log information
to the Close and Unlink operations rather than sending it separately.
This will probably also result in that the Close-after-write operation
is split in two, one "Close and preserve", and one "Abort this object
storage".

I will NOT spend any additional time on current async-ufs code. In my
opiniton it isn't worth the effort to maintain and my time is better
spend in other areas. There are some subtle design problems with that
code. The idea is neat, but it does not quite work out the way it is
intended. A lot of cludges will be needed to get it to work reliably on
high load systems (which is where it is intended to be most useful..).

/Henrik
Received on Tue Jul 29 2003 - 13:16:00 MDT