This is almost as bad as not giving warranties about uniqueness of inode
numbers.
(How about - all FAT regular files use inode numner 13 :-< ).
"Native" file systems maintain persistent inode numbers for the life
time of
the file.
Non-native file systems should maintain that persistence at least while
the inode
is cached (ie., when it is opened or exec'ed or mmapped or the cwd of
some
process).
> 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.
What happenes when the file is renamed (may be moved to another
directory) -
it will always change the dir entry coordinates. Will the inode number
change
as well?
> 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.
What about sparse files? I think they are illegal on FAT file systems?
>
> 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?
I liked better the idea of using the first cluster for the inode number.
What would be the overhead/risk of pre-allocating a cluster when an
empty
file is opened (or on creat) and deallocating it when the inode is
closed
(but never written).
Impacts:
- it will limit the number of open empty files on a FAT filesystem .
- read only mounts?
Alternately - use the dir entry coordinates but maintain that while the
inode is open. The cached data should include the "new inode number"
which
is different from the used ino if the file was renamed or unlinked while
it was open. If an open file was deleted/renamed and a new file was
created
using the same slot, a temporary inode number can be allocated for the
new file (and maintained while this new file is open).
Alternately - (probably the right thing for 2.2.x) Return error from
rmdir if
the directory is not really empty (contains slots for unlinked open
files).
Itai
--
Itai Nahshon nahshon@actcom.co.il
Also nahshon@vnet.ibm.com
-
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/