Re: Linux 2.2.11pre2 proposed patch

Craig Milo Rogers (rogers@isi.edu)
Tue, 20 Jul 1999 10:59:37 -0700

>> 2.2.11pre2, and I get the same behavior, namely the inode numbers on
>> vfat partitions change between boots. I use tar for incremental
>
>Yes, they do. VFAT has *no* reliable inumbers. Never had. You have to
>choose between inumber changing on rename(), lots of races or inmuber
>changing across umount;mount. The latter is the smallest breakage.
...
>Let me put it that way - inumber is a key allowing to identify the file.
>It should not change while the file is opened. Thus we can't use directory
>entry location (rename()) or the first cluster number (truncate() and
>write()). The latter is obviously unacceptable. The former is nasty
...
> You are dealing with inherently sucking filesystem. Sorry. There
>is *no* out-of-directory metadata and thus there is no persistent inodes.

If you are willing to accept the still-not-ideal constraint
that the inode number stays constant so long as only Linux (or, in any
case, another system employing the same algorithm) performs directory
operations on the filesystem in questions, you might implement an
auxiliary file that holds persistent inode mappings.

The natural place to put the inode map would be on the same
underlying FAT filesystem, but for extra brownie points you could
perhaps arrange for it to be located on a different filesystem. To
protect against external meddling (e.g., renaming a file with
Ms. Windows), the persistent inode map should contain checksums of
the VFAT filesystem's underlying directory pages.

This is piling cruft upon cruft, but it could be made to work
under the given constraint. It could even be yet another layered
filesystem (PVFAT?) in the towering FAT ensemble. Future generations
will not thank you, though.

Craig Milo Rogers

-
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/