Date:   Fri, 12 Apr 2019 15:34:04 -0400
From:   Phillip Susi <phill@...susis.net>
To:     linux-ext4@...r.kernel.org,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: defrag

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.

Powered by blists - more mailing lists