Comment 28 for bug 537241

Philip, the 247 reporters of the original report (#512096) didn't intentionally break their system. I suppose that most of them don't even know what data=writeback is.

To reproduce it on a fresh lucid setup:
- to be sure that the right mount options are set add "auto_da_alloc,data=ordered" to the ext4 line in fstab and remount.
- install a previous version of dpkg (e.g http://archive.ubuntu.com/ubuntu/pool/main/d/dpkg/dpkg_1.15.4ubuntu2_i386.deb)
- simulate a crash:
$ apt-get install bsdgames ; sleep 5; echo b > /proc/sysrq-trigger

When your system as rebooted, see all those 0 bytes files:
$ ls -l /var/lib/dpkg/info/bsdgames.*
$ ls -ld $( dpkg -L bsdgames )

auto_da_alloc doesn't even detect the replace via rename situation (in fact it does, but only in the simplest cases)

Once the files in /var/lib/dpkg/info/ and /var/lib/dpkg are corrupted there is no other to recover than running some manual operations. Which are like black magic to the common user who generally end up with a complete reinstall. Users can complain about performance but won't complain about loosing their data.

This situation is not specific to dpkg. Try :
$ ar x dpkg_1.15.4ubuntu2_i386.deb; sleep 5; echo b > /proc/sysrq-trigger
it will leave 0 bytes files too.

It's not the place to discuss about it since this report is about performance, but I don't think the solution is to add fsyncs to all the applications around and it is not realistic.
The solution is to fix ext4 itself. To draw a parallel, there is no single database engine leaving empty rows when a transaction failed. Why should a fs behave differently ?