| |||||||||||||
Credit where credit is dueCredit where credit is duePosted Mar 15, 2009 3:54 UTC (Sun) by bojan (subscriber, #14302)In reply to: Credit where credit is due by sbergman27 Parent article: Ts'o: Delayed allocation and the zero-length file problem
> first uncovered and reported this flaw in ext4
And if you repeat a lie enough times, it becomes the truth.
(Log in to post comments)
Credit where credit is due Posted Mar 15, 2009 14:06 UTC (Sun) by sbergman27 (guest, #10767) [Link]
Please present your evidence. Who found it and reported it before the launchpad bug documented in the launchpad link in Ted's own blog posting? And do please provide source.
The lengths to which some people will go to avoid crediting Ubuntu is simply amazing. I've never seen such a notable sour grapes response in the community as the reactions I see today from advocates of less popular distros. Most of the really notable ones seem to come from the Fedora camp, where the perceived threat level is apparently particularly high. But then, Fedora has always had more than its fair share of spiteful advocates.
Credit where credit is due Posted Mar 15, 2009 19:03 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link]
It seems that the side effect of delayed allocations and the new multi block allocator was well known to Ted and others for a while.
http://lxer.com/module/newswire/view/116126/#ext4
"Ext4 isn't all good news though, the new allocator that it uses is likely to expose old bugs in software running on top of it. With ext3, applications were pretty much guaranteed that data was actually written to disk about 5 seconds after a write call. This was never official but simply resulted from the way ext3 was implemented. The new allocator used for ext4 means that this can take between 30 seconds and 5 minutes or more if you are running in laptop mode. It exposes a lot of applications that forget to call fsync() to force data to the disk but nevertheless assume that it has been written."
I recommend that you listen to
http://fosdem.unixheads.org/2009/maintracks/ext4.xvid.avi
His talk actually goes into quite a bit about how to avoid this problem and potential workarounds he was looking at. He mentioned that Eric Sandeen, XFS developer now working on Ext4 in Red Hat had talked to Ted about how XFS had some hacks at the filesystem level to workaround this problem of applications writers relying on Ext3 like behaviour. The current Ext4 patches are based on the same ideas. The rawhide kernel already had backported patches already
https://www.redhat.com/archives/fedora-devel-list/2009-Ma...
It appears that proprietary kernel modules causing more instability aggravates the problem as well. Good to get more exposure on the gotchas however. It looks like Btrfs has now similar patches as well in part as a result of such wider discussions.
Credit where credit is due Posted Mar 15, 2009 21:14 UTC (Sun) by bojan (subscriber, #14302) [Link]
> Please present your evidence.
The lie is that there was a flaw in ext4. There is no flaw in ext4 (not when it comes to this, at least) - applications are broken, because they don't do what's required. They are falling short.
Ted put a workaround into ext4 to address the shortcomings of applications.
The evidence is in your manual pages. Just read them.
|
|||||||||||||