So the other day I ran a dump of my root fs (ext4) to /dev/null and it took 8.5 minutes. This fs has been around for some time so I figured it may be somewhat fragmented. I formatted a fresh fs on a new (lvm) volume and used dump | restore to clone my fs to that, and dumping that to /dev/null took 3 minutes. Quite an improvement. I was curious so I formatted the scratch volume with btrfs, dump|restore to clone, and used btrfs-send to dump the volume to /dev/null and it took 3.5 minutes ( after our course dropping cache ). Not bad. I broke out the old defrag utility and had to make a few fixes to get it to compile and run properly again ( been several years since I touched it ), and after using e2image to clone the fs to the scratch volume, and running e2defrag on it, dumping that to null took 2m36s, so it seems that it does still improve on the default allocation policy of a real mounted filesystem, though not by a huge amount. Next I went back and cloned the fs again with e2image and ran e4defrag (as root) on it. It said it had a bunch of failures so I ran it a second time and it seemed to do some more work ( why didn't it do it all the first time? ). Or does it just print every file name ( no switches ) even if they are already not fragmented? Anyhow, dumping the fs after 2 runs of e4defrag took 9m37s. That seems to be no better than before running e4defrag. Odd. I re-cloned the fs and dumped it without e4defrag and it was 9m46 seconds, so this is probably due to the scratch volume being located further down the disks in a slightly slower area than the original, but it still is worth noting that running e4defrag did not really improve the dump time, whereas e2defrag made a huge difference.
