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/