| |||||||||||||
|
| |||||||||||||
O_PONIESO_PONIESPosted Jul 5, 2009 22:50 UTC (Sun) by sbergman27 (guest, #10767)In reply to: O_PONIES by nix Parent article: In brief
Yes. That's the only change that I recall that would affect reliability. But you were also saying that once you turn on data=ordered that you get back all the latency issues. Much of what was done to ext3 and the default io scheduler in 2.6.30, aside from changing the default journaling mode, was aimed at cutting latencies on fsync. (That work was important enought that Linus threatened to change the default i/o scheduler of Jens couldn't fix the problems it was causing ext3. Jen's quickly complied.) The fact that there was an "obvious" reason (data=ordered) for ext3 latencies resulted in the *real* reasons going undetected for years because "everybody knew" it was just the penalty of the way daya=ordered worked.
After the real problems were resolved, setting the default to data=writeback seemed mostly a final flourish, since Ted had patches to help mitigate the worst of the unreliability it would cause. I suspect that the default would not have been changed if the latency thing had not been such a long-standing issue. (One tends to swat hard-to-swat flies harder when one finally does get them.) And, of course, Ted really wanted to see the data=ordered default go away, since it was making ext4 look bad by comparison.
It's the combination of the change of default journaling mode *and* the relative painlessness of fsync on 2.6.30+ ext3 that make ext3 a very different animal from pre-2.6.30 ext3 for developers. They really have to be talked about separately.
And yes, the default journaling mode can also be specified in the superblock. But that is still *totally* irelevant to the developer. The developer can mount his own filesystems with any options he wants. But it doesn't make a bit of difference to what happens when his *users* try to run his software on *their* machines.
(Log in to post comments)
O_PONIES Posted Jul 5, 2009 23:55 UTC (Sun) by nix (subscriber, #2304) [Link]
Actually my understanding is that nobody realised how bad the latencies
could get. Linus insisted on the data=writeback default after running tests with all the other patches in place showing enormously variable and sometimes terrible fsync() latencies from tiny file writes when there was a large dd going on in the background. Switching to writeback eliminated those latencies.
So, not a 'flourish', unless you consider taking 10s to save a 500 byte
O_PONIES Posted Jul 6, 2009 0:45 UTC (Mon) by sbergman27 (guest, #10767) [Link]
No. Not 10s.
Linus was specifically *trying* to see how long he could make it stall. And by the time the the other problems were fixed, it was hard for him to force a 2 second latency:
http://lwn.net/Articles/328381/
Once the data=writeback default was put into place, it became hard for him to force a 600ms latency.
The original latencies were *far* longer than 2s. (30 seconds had been reported by some. Though such reports did not seem common.) The change of journaling mode ended up bringing the worst case down by a mere 1400ms.
And considering that the common case (as opposed to the relatively rarely seen worst case) was livable enough that it took 8 years for anyone to care enough to attack the problem, I'd call the final change of default journaling mode to cut the worst case by a final 1400ms a flourish.
And Linus never "insisted" on the data=writeback default. Ted suggested it. And in view of the ext4 patches that Ted was suggesting be moved over to ext3 to mitigate the worst (but not all) of the resulting reliability issues, Linus said OK, let's do that.
|
|
||||||||||||