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 ? -- My computer updates are very slow since latest dpkg update https://bugs.launchpad.net/bugs/537241 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
