> Net Llama! wrote:
> >I really have to ask what you were running when you had that FS
> >corruption. I've never seen anything like that, and i've been using XFS
> >for about 3 years now on over 15 different boxes.
> >
>
> Simple as pie. Set up a machine running XFS. Start some disk activity
> (maybe a test mail server). When the FS is getting solid activity, yank
> the power out. When I saw this happen I had to mkfs and start over.
What probably hit you here is caused by the very simple fact that PC-class hardware is crap.
You see, when you yank the power cord out of the wall, not all parts of the computer stop functioning at the same time. As the voltage starts dropping on the +5 and +12 volt rails, certain parts of the system may last longer than other parts. For example, the DMA controller, hard drive controller, and hard drive unit may continue functioning for several hundred of milliseconds, long after the DIMMs, which are very voltage sensitive, have gone crazy, and are returning total random garbage. If this happens while the filesystem is writing critical sections of the filesystem metadata, well, you get to visit the fun Web pages at http://You.Lose.Hard/ .
Subscribe to:
Post Comments (Atom)
2 comments:
http://linuxmafia.com/faq/Filesystems/reiserfs.html
Why doesn't ext3 get hit by this? Well, because ext3 does physical-block journaling. This means that we write the entire physical block to the journal, and only when the updates to the journal are committed do we write the data to the final location on disk. So, if you yank out the power cord, and inode tables get trashed, they will get restored when the journal gets replayed.
XFS and ReiserFS do what is called logical journaling. This means that if you modify the mod time of an inode, instead of writing the entire inode table block to the journal, they just write a note in the journal stating that "inode X now has a mod time of Y". This takes much less space, so you can pack many more journal updates into a single disk block. For filesystem benchmarks that try to saturate the filesystem's write bandwidth, and/or that also have very high levels of metadata updates, XFS and ReiserFS will tend to do much better than does ext3. Fortunately, many real-world workloads don't have this characteristic, which is why ext3 tends to perform just fine in practice in many applications, despite what would appear to be much worse benchmarks numbers, at least for some benchmarks.
Post a Comment