Messages in this thread | | | Date | Wed, 25 Aug 1999 17:42:38 -0400 | From | "Theodore Y. Ts'o" <> | Subject | Re: [PATCH] robust ext2fs against failure |
| |
Date: Thu, 26 Aug 1999 00:51:44 +0900 From: Kazuto MIYOSHI <kaz@earth.email.ne.jp>
The situation which I mean is that one new directory entry is allocated to point a newly-created memory inode, but corresponding disk inode still contains GARBAGE then:
dir-entry inode
fs/ntfs/ ---------- Makefile : ......: : /tmp/ ------+--> tmp990825
---> memory inode .... garbage on the disk (of cource, overwritten in future...)
If system crashes before the memory INODE is written back over the garbage, it causes doubly-linked file.
OK, this only happens where "Makefile" is a newly created file. (That didn't appear to be the case in your example --- was it? The other files in the directory were OK, or at least you didn't say that were garbage, so it didn't look like a case where the Makefile was freshly created before the crash.) But OK, let's assume that was the case. In that case, the inode which was freshly assigned to be Makefile will likely be on disk as a deleted inode. If you crash before the memory inode image is written out, it will look like a directory entry pointing to a deleted inode, and e2fsck will clear the directory inode.
The only way your scenario could happen is if the file /tmp/tmp990825 was deleted, and ntfs/Makefile was created instaneously before the system crash. Since metadata is synced to the disk every five seconds, and in order for this to happen you have to get fairly unlucky such that the ext2 file allocation algorithm picks the just-deleted-inode as the one to be used for the new inode, this is **not** a common case.
But in that case, yes, you could have a case where fs/ntfs/Makefile is linked to the /tmp/tmp990825 file, where /tmp/tmp990825 was a file intended to be deleted but which contains garbage data ---- but consider that in that case, the crash happend *just* before the ntfs/Makefile was created, which means even if you have synchronous metadata writes, the datablocks in the ntfs/Makefile will have in all likelihood not been synced to disk anyway, so you'd have the problem where you'll lose the data in ntfs/Makefile, or the data in ntfs/Makefile is garbage. You can't guarantee data integrity on an unclean shutdown, at least not without sacraficing a *lot* in performance. The patches you have will not protect you from this case!
>From my reading, e2fsck just copys DUP BLOCKS, but does not replicate files (inodes) pointed from two separate directory entries. E2fsck just adds 1 reference count to the inode.
Yes, because it's legal to have an inode which is pointed to by different directory entries --- that's what hard links are all about, after all. This would never cause garbage data to be appear in a file that has been created more than 5-10 seconds before an unclean shutdown, though. And for freshly created files, you'll get garbage data simply because the data blocks haven't been synced to disk yet.
- Ted
- 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/
| |