Hi,
maybe my ramblings will be useful for other inodeless fs implementations
later.
It turned out that all variations I proposed so far won't work. There are
the following requirements:
The node->cache_id (usually inode number) given to a specific file must be
unique among all used cache_id's at any given time
constant for the whole duration references are hold to the file
(as it is copied to diskfs_fhandle data.cache_id)
meaningful to the translator, read: refer to a specific node
Usually, you just use inodes and you're done. What about FAT or ISO9660?
The three following possibilities have been recognized, interestingly, each
of them violates exactly one of the points above:
1. Storing the beginning of the file on disk:
This is a workable solution as long as you don't have zero bytes file, which
don't have a unique beginning of the file (for example, start_cluster for
all FAT zero files is cluster 0). So, this violates the uniqueness of the
cache_id (this problem is partly reparabel by following ideas similar to
suggestion three below).
2. Storing the location of the directory entry:
This is not constant under rename operations, thus it fails to fulfill
requirement two.
We could reflect this by changing the node cache, but we can't change the
filehandle cache_id's in diskfs, so diskfs will disagree with us.
3. Making up inode numbers on the way:
Simply start with 1 and go up for every new file cached. This could be
called "virtual inodes". The problem is that there is per se no efficient way
to regain the virtual inode numbers from the file information, when looking it
up (The answer to the question: Do we have the file "foobar" in the cache?).
So, this violates the meaningfulness of the cache_id, but, as it turns out,
in a repairable way.
"virtual inodes" seem to be the only promising solution that is
generic enough to cover all cases. As they are chosen as seen fit, they can't
conflict with anything. They also don't need to change ever, and we can
change the underlying data (directory entry location, file start etc) as
needed, without corrupting libdiskfs idea of the file.
It allows for simple but efficient node cache implementations, btw.
To implement this properly, there should be a reverse lookup cache,
which maps directory entry locations to virtual inodes. This time the
requirements above don't apply, as this table can be changed freely when
files are renamed (and their directory entries moved). So this is indeed
different from suggestion 2 above. OTOH, a reverse lookup repairs the
"meaningfulness" of the virtual inode number.
It turns out that a filesystem with simple data structures can be more
complicated to implement. We learn that adding a bit complexity to the data
structures (like inodes) can lead to more efficient and easier to implement
operations on the data. ;)
As usual, any comments are appreciated.
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server
Marcus Brinkmann GNU http://www.gnu.org for public PGP Key
[EMAIL PROTECTED], [EMAIL PROTECTED] PGP Key ID 36E7CD09
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
