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/