with 2.6.38, 2.6.39, 3.0.0-rc:
Disconnect usb device, boom kernel panic
Add usb device boom kernel panic
some other reasons, kernel panic
your psu gets flaky
your mobo gets flaky
your fans clog up unnoticed
your ram overheats
your graphics drivers lock up the system
some in kernel driver locks up the system.
there are MANY reasons for a hard reboot. Power fluctuations are such a rare occurance (in civilized countries) they do not matter compared to kernel bugs or hardware failures.
Or even the occasional 'oops, tripped over the cord'.
Barriers are a must. Disabling them is a typical ext3/redhat/fedora move to blind the stupid. They want to look good in benchmarks made by people without a clue. Disabling barriers is like hitting the user in the face and telling him 'hey, I don't care if you lose all you files. I want to look good in stupid benchmarks'.
Thanks for the link, it helped me understand what barriers are. But as commits are usually written at the end, when can it happen that one block is not written and a commit is made? Some kind of disk I/O error? Even if that happens, the filesystem has to find out the anomaly pretty soon and fix it, so the risk is just those few seconds that the filesystem is in an inconsistent state.
Originally Posted by Zapitron
it is not only the problem of 'inconsist' state but also that there might be a HUGE window of a minute and more of 'you told the system to save the data and nothing happend' or 'you told the system to rename the file and it is still in progress'.
Lots of people have lost lots of data because of idiotic defaults that are only set that way to look good in benchmarks conducted by people who
a) don't have a clue or
b) don't touch defaults or
c) don't care or
d) all of the above
Write barriers don't directly help against data loss. They help against filesystem corruption.
Kernel developers used to think that write barriers are slow and it is mostly safe to disable them, but Chris Mason came up with a write barrier torture test. It demonstrated that on certain workloads, there is a 50% chance of your filesystem ending up corrupted when write barriers are disabled and the power fails.
Unless your UPS breaks.
Originally Posted by Zapitron
and reiser4 show them that a fs using barriers can be fast. R4 went so far going into sync mode when barriers are not available.
Of course r4 was blocked. Breaking and blocking had a long tradition. Breaking reiserfs had such a long tradition (demonstrating that 'get your code into the kernel and it will be fixed by us when we break it through changes elsewhere' was nothing but a lie). Reiser4 was blocked because of 'layer violations' - worse violations are ok with btrfs.
The fact stands: fedora/redhat people don't care about your data. Only about looking good when stupid people run stupid benchmarks. Just like ext3.
Tell me the good mount settings for EXT4 and I'll use them.
Originally Posted by energyman
luckily ext4 does use barriers by default - and the fs can't do much if the layer above does not honor them. Well, reiser4 does something about it, but ext4 can't. So the defaults are ok, as long as you don't use barrier-destroying-lvm-setups.
LVM supports barriers too, since 2.6.33. Why they weren't enabled in the Fedora install I have no idea.
Again, I don't think that fedora DISABLES them, the link I gave says the exact opposite.
Originally Posted by chithanh