Re: FAT data corruption in 2.2.3

Alexander Viro (viro@math.psu.edu)
Thu, 11 Mar 1999 08:34:28 -0500 (EST)


On Thu, 11 Mar 1999, Tom Holroyd wrote:

> I'm on an AlphaPC164LX, egcs-1.1.1 compiled, stock 2.2.3.
>
> I can reliably demonstrate data corruption when writing to a FAT floppy.
> I never see data corruption when using an ext2 floppy, nor do I see
> corruption on raw writes. Only mounted vfat or msdos floppies.

Tom, I know what it is, but that's a common problem with FAT
implementation. What really happens: inodes are indexed by position of
directory entry. Suppose you delete a link. Inode gets dirty (OK so far)
and instead of marking inode with "don't write to disk" the dirty trickery
is used to make this 32 bytes of disk be skipped in readdir() and
lookup(). Guess what happens if (emptied) directory is removed and the
block gets reused by data. Exactly. FAT is *full* of such races. See the
thread with subject "[RFC] What should we do with FAT inode numbers" in
l-k archives for other examples. I have a alpha-quality patch for that,
but I'ld rather wait for a week or so before posting it for testing. It's
not a VFAT problem - shit hits the fan on the lower level. Sigh... The
fact that there are 3 filesystems layered over it also doesn't help -
especially since one of them depends on another and tries to implement
filesystem stacking outside of VFS (UMSDOS). Bogus changing of inode under
living dentry (finally fixed in rename patch) also doesn't make life
easier... So there. Let the mess with rename settle down. Then FAT stuff
will become much easier.
Cheers,
Al

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