Credit where credit is due

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.