Posted 5 February 2012 - 16:15
Quick conclusion for those eager to know: If you want ext2 behavior, disable "delayed allocation" on the ext4 driver. This will make it perform slower, but more predictable (but still faster and more reliable than ext2). To do so, specify "nodelalloc" in the mount options, e.g.: "mount -o nodelalloc /dev/sda1 /media/hdd"
I've been doing some more tests myself this weekend. Re-formatted my disk as ext3, and used the different ext2/3/4 drivers to mount it with varying options. To test their "recording" behaviour, I start a recording on one HD channel, and then "torture" the system with "dd if=/dev/zero of=/media/hdd/blanks2 bs=188k count=10000" to dump about 1.8 GB on the disk, erase it, then dump it again. Enigma2 measures and writes the time it takes to write each 188k block to its output.
As for details:
With ext4 "fully functional", I see write times of ~5ms. Under torture, most aren't affected, but some are detained for 100..1000ms. This effect is larger when data=ordered is active, data=writeback tampers it. The ext2 and ext3 drivers show slightly larger overall write times, but when under stress, the load is spread more evenly amongst calls, so instead of a single call taking up 100ms, you now see 5 calls of 20ms, or something similar to that. This is much easier to cope with. Since the ext4 driver uses features not previously seen in ext2/3, shutting one of them down should bring back that old behavior. Indeed, "delalloc" showed to be the one. If I tell the ext4 driver to stop using delayed allocation, it behaves much more like the ext2/3 drivers when mounting an ext3 disk. Even better, when I converted the disk to ext4, and then added the "nodelalloc" option to the mount command, this effect remained in place. What I did notice is that the "torture" command now had to pay the price. It was writing significantly slower (from 50 to 30MB/s).
I have to check the documentation, but my understanding is that the system, instead of allocating blocks at each call to write(), it just collects them and allocates them in bigger chunks. This does help file transfer significantly, but on the typical load from recordings, causes the long delays on some of the calls when there are other threads performing IO as well.
Real musicians never die - they just decompose