Messages in this thread Patch in this message | | | Date | Sun, 5 Sep 1999 18:15:54 +0100 | From | Steve Dodd <> | Subject | Re: Amanda VFAT Incremental Backups Broken in linux-2.2.1[12] |
| |
On Sat, Sep 04, 1999 at 01:07:19PM -0500, Martin Gallant wrote:
> So the question is, what changed in VFAT support from 2.2.10->2.2.11? > Is there some magic switch I can use to revert to legacy behavior?
From patch-2.2.11:
+++ linux/fs/fat/dir.c Mon Aug 9 12:04:41 1999 @@ -9,7 +9,7 @@ * * VFAT extensions by Gordon Chaffee <chaffee@plateau.cs.berkeley.edu> * Merged with msdos fs by Henrik Storner <storner@osiris.ping.dk> - * Plugged buffer overrun in readdir(). AV + * Rewritten for constant inumbers. Plugged buffer overrun in readdir(). AV */
AIUI - and I may well be wrong, hopefully Al Viro will correct me if so (I've dropped him from the cc: list 'cos I'm sure he's sick to death of this subject by now):
FAT keeps /all/ of its metadata inside directories, and is thus Broken as Designed. The old behaviour of the Linux fat driver was to assign inode numbers based on the metadata location -- this meant that the inode number was not constant across rename(). Not only did this louse up exporting fat filesystems over NFS (I think), but it also meant that there were a not inconsiderable number of races inside the FAT driver. These had been seen to cause real-life data corruption.
I'm not sure what the new code does, but IIRC it guarantees that inumbers will not change while the file is open. I don't know whether they can change if the file is shut and the inode uncached, but the fs is still mounted; I suspect they can. I'm certain they will change across mounts. While this is not good, it's much, much better.
On Mon, 19 Jul 1999, Alexander Viro wrote:
"On Mon, 19 Jul 1999, Alan Cox wrote:
> o FAT now uses cluster numbering for inode info It doesn't. It generates inumbers on the fly. Cluster numbering is unusable for that - truncate() *shouldn't* change inumber. FAT *has* no file invariants that would survive (a) rename, (b) truncate(), (c) write and (d) umount. Of all those umount give the least pain wrt races. New code guarantees constant inumbers for opened files.
The bottom line - inumbers on FAT will suck anyway. There is no inodes in normal sense. And inumbers changing after reboot are *much* better than exploitable races. On FAT usage of (old) inumbers for any backup stuff was broken - rename() would go unnoticed."
There's more info in <Pine.GSO.4.10.9907201115360.4963-100000@weyl.math.psu.edu>, if you want. > Normally I don't come here begging for help, but this time I am stuck. > Rolling back to 2.2.10 does not help me or other amanda users long term.
I'm afraid the only long term is solution is to stop using FAT. If you have no other operating systems accessing the data, convert the partition to something sane (ext2 would be my recommendation). If you have, let that operating system do the backups. Hell, even NTFS has inode numbers (though they don't call them that). Let's not get into the long/short filename backup issues.
To quote Mr. Viro once more: "yes, FAT is in sore need of pointed stick, mallet and garlic; no, even its authors can't kill the bloody thing and they would *like* to do that."
-- "People get annoyed when you try to debug them." -- Larry Wall
- 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/
| |