Re: [RFC] What should we do with FAT inode numbers?
Alexander Viro (viro@math.psu.edu)
Sat, 16 Jan 1999 18:41:51 -0500 (EST)
Hmm... OK, folks. What about the following?
a) we don't give any warranties about preserving inode number of opened
file.
b) for linked files we use the coordinates of directory entry.
c) when file gets unlinked we change its inode number so that it would not
clash with the inodes of linked files (mod 32 trick). We make those inode
numbers unique (32*event++ + 1, if it is already used - add powers of two,
then - linear search (should be very rare)). Oh, we do it only if there
are other owners of inode, indeed.
d) we add a new method that gives user- and knfsd-visible inode number. If
it's NULL we simply use i_ino. It will save use from changing i_ino if the
fs is ugly.
e) for msdos and friends we keep a copy of directory entry in fs-specific
part of in-core inode. write_inode() simply writes it into the right place
if the file is still linked and does nothing if it's unlinked. Everybody
else would use in-core copy.
f) FAT cache becomes indexed by starting cluster, not inode number. No
need to fat_inval_cache(), if file was empty it had no entries in FAT
cache, if it wasn't - we are completely fine, since the starting cluster
didn't change. Truncate to zero would simply remove the entries for all
chain, as it does now.
That way we preserve the warranties wrt. uniqueness of inumber and
can get rid of the directory entry as soon as it gets unlinked. I can do
that. I know very well that we are in the code freeze, but I'm afraid that
fixing all races in msdosfs _and_ preserving the current setup would be
trickier than that. Objections, comments?
Al
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/