Performance regressions with ext4 under certain workloads
[…] In particular, the dpkg package manager is known to run significantly slower on ext4, causing installations using the server or alternate install CD to take on the order of twice as long as before. ext4 does not guarantee atomic renames of new files over existing files in the event of a power failure shortly after the rename, and so dpkg needs to force the contents of the new file out to disk before renaming it in order to avoid leaving corrupt zero-length files after power failures. This operation involves waiting for the disk significantly more than it strictly needs to, and so degrades performance. If fast package management operations are most important to you, then you should use ext3 instead. (570805)
Another thing which can be interesting too:
Write performance penalty for using unaligned partitions, took from Linux on 4KB-sector disks: Practical advice (and redrawn for readability). Tests do not reflect overall performance across file systems; a value of 1.00 means no speed penalty; higher values mean worse performance. — I believe that “alignment” is still a hit-or-miss, as the HDD’s firmware reports fictitious Cylinder-Head-Sector values, but it’s interesting to see that the FS algorithms matter. And I love XFS.