Messages in this thread | | | Date | Tue, 24 Aug 1999 12:09:11 -0400 | From | "Theodore Y. Ts'o" <> | Subject | Re: [PATCH] robust ext2fs against failure |
| |
Date: Tue, 24 Aug 1999 14:59:20 +0900 (JST) From: MIYOSHI Kazuto <miyoshi@sss.abk.nec.co.jp>
Last month I tried to compile linux 2.2.x kernel but it failed. Doubting that I made some mistakes, I checked error log and eventually I found that NTFS makefile had turned into a strange binary file. It is worth noticing that I have never touched NTFS makefile before (I do not use NTFS) and my machine crashes a few times per month.
I can not say positively, but perhaps it is because some new directory entry which contains garbage (on disk) was allocated for some new file. If the garbage data points NTFS makefile accidentally and system crashes before the directory entry is written back, new file and NTFS makefile are doubly hard-linked. Someone writes binary data to the new file, NTFS makefile would be also altered...
If you ran e2fsck after the each system crash, it would have detected any doubly allocated files and offered to clone the data blocks to avoid this problem.
According to the web page, the patches require that you run e2fsck anyway, because the patch doesn't guarantee the consistency of the allocation bitmaps. So if you didn't run e2fsck after the crash, that could easily explain why your makefile got corrupted (the block bitmap shows the block as being unallocated, and then that block got grabbed when some other binary file was allocated).
The funny thing is that if you have to run e2fsck after each system crash anyway, it's not worth it to do some of the things detailed in the tech note. For example, it talks about wanting to clear the indirect block to disk before linking it in to the inode, lest garbage in the indirect block look like valid blocks, and so you have blocks claimed by multiple inodes. True --- but e2fsck detects this case and fixes it. So it's not at all clear it's worth the performance hit to clear the indirect block first.
(The only advantage I can see is that e2fsck by default doesn't fix multiply claimed blocks automatically, since it wants the system administrator to note the problem so s/he can manually check the two files to see which one had gotten corrupted. If you don't care about this you can do an e2fsck -y, although at some risk because you might notice some serious corruption that requires repairs at the application data level.)
And more, needless to say, it is not so important to save data block contents (they are lost by crash anyway), but to save file system consistency.
E2fsck can repair this kind of filesystem consistency for you, and your patch doesn't obviate the need for filesystem consistency. If you must take the performance hit of doing synchronous updates, a bettter tactic to use is Kirk McKusick's Soft Updates technique, or wait for Stephen to get his Journalling extensions to ext2 done. They will allow you to skip the e2fsck on reboot while still maintaining filesystem consistency (this is important for high availability systems) and at a lower cost to the filesystem's performance.
- 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/
| |