[RFC] What should we do with FAT inode numbers?
Alexander Viro (viro@math.psu.edu)
Sat, 16 Jan 1999 08:08:19 -0500 (EST)
Problem: inode numbers on FAT-derived systems are completely
fscked up. Period. Amount of races in msdosfs code may exceed one in
MSDOS kernel (after all, the later is single-tasking). I hoped that we
might postpone fixing that stuff till 2.3, but...
FAT-derived filesystems use directory entry location as inode
number. Fine, except that we have to take care of unlinked-but-opened
inodes (avoid reusing the same number). Thus we may have to declare a
directory busy even if all files are unlinked (otherwise we might reuse
the same block and thus inode numbers later) [not done; race in msdos and
umsdos]. Thus we have to do all sorts of ugly stuff in link creation.
Rename may change the inode number of inode. Thus we either have
to prohibit renaming opened files (real funny, Scotty...) [msdos, umsdos]
or accept that fstat() may return different i_ino being called twice on
the same opened file [vfat].
Moreover, when we rename over the opened file we may end up with
-ENOSPC (target's directory entry can't be reused, may have to expand
directory).
There are assorted races around rename(), mostly due to inability
to cannibalize target's directory entry.
There is a lot of other messy places over the code, but they are
easier to fix.
The real question being: what warranties do we want wrt the
contents of st_ino? Almost all this stuff is fixable if we allow st_ino
change during the lifetime of the file. *All* this stuff is fixable if we
allow fstats on a different opened files return the same st_ino - we'll
have to divorce i_ino from the value returned in st_ino, but that would be
the right thing anyway. Both POSIX and Single UNIX say *nothing* on st_ino
(good thing, since when they say something it usually turns out to be a
fossil from Missed'em'Five). 4.4BSD docs (and D&I) also say nothing, but
from the look at *BSD kernels it seems that for msdosfs they care only
about conflicts between readdir() and fstat(). OTOH they may have bugs
there...
-
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/