Messages in this thread | | | Date | Sun, 17 Jan 1999 10:24:56 +0200 | From | Itai Nahshon <> | Subject | Re: [RFC] What should we do with FAT inode numbers? |
| |
> Hmm... OK, folks. What about the following? > a) we don't give any warranties about preserving inode number of opened > file.
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/
| |