> I reported this earlier, for 2.2.10-ac10, so I thought I'd try
> 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.
> backups and when it notices an inode change between backups it assumes
> a rename and does a backup. Needless to say, the fact that vfat
> partitions don't have constant inode #'s plays havoc with my backup
> scheme. This didn't happen with 2.0.36 and 2.2.10-ac10 is the first
> 2.2.x series kernel I've used.
>
> Is this "varying inode" behavior on vfat drives going to be the
IM(NSH)O - yes.
> standard now or is something wrong with my setup?
Yes. Inumbers on VFAT *never* were reliable. Ditto for SMBFS.
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
(rename()) and extremely race-prone - you have to protect the places where
the directory entry of unlinked-but-still-opened file used to be and that
leads to living horror. It's not just a matter of horrible code - old
driver *had* all sorts of exploitable races. Including bad data
corruption (reported on l-k - it's not a theory).
You are dealing with inherently sucking filesystem. Sorry. There
is *no* out-of-directory metadata and thus there is no persistent inodes.
We can choose between breaking the expected semantics for opened files (+
having tons of races) and inumbers that may change when file is not opened
by anybody. The latter may screw backup stuff that relies on persistent
inumbers. Said stuff *is* broken anyway: even on the normal filesystems
usage of stat() for those purposes means a race - only fstat() is safe.
-
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/