Re: File system defragmentation. Something that can resume after stopping.

On 5/14/26 5:30 AM, Michael wrote:
> On Wednesday, 13 May 2026 23:07:42 British Summer Time Dale wrote:
>> On 5/13/26 2:13 PM, Javier Martinez wrote:
>>> Maybe you can try to move some big dirs to an external filesystem and
>>> move them back again, with a bit of luck if you have free space enough
>>> in your original filesystem kernel could assign more contigüous sectors
>>> reducing fragmentation
>> Well, right now, my plan is to just let it run.  It will finish,
>> eventually.  Maybe nothing will happen that makes me have to stop it.
>> If I do, oh well.  I'll just have to start it over again.  See how far I
>> make it that time.
>>
>> Dale
>>
>> :-)  :-)
> I must ask, does your ext4 fs actually *need* defragmenting?  Are read
> operations perceptibly slow/slower now than when the fs was not as full, both
> measured while the disk is *not* being written to?
>
> There's this archived paper from a 2007 Linux Symposium which explains how
> linux filesystems intelligently delay writing data to disk until the last
> moment so that data is allocated as contiguously as possible.  Also, after a
> file is committed to disk, contiguous blocks following the file are reserved
> in order to allow for future changes to the file.
>
> https://web.archive.org/web/20191230032039/https://ols.fedoraproject.org/OLS/
> Reprints-2007/sato-Reprint.pdf
>
> Unlike DOS/NTFS which have a fragmentation problem, especially if file
> compression is applied after initial storage, linux filesystems do not suffer
> as badly, if at all.
>
> When you run 'e4defrag -c' it will report which files are badly fragmented and
> provide you with a score, e.g. I just run it here on /usr which is not
> suffering from fragmentation.  It came up with 5 files and then reports:
> ===================
> [snip ...]
> Total/best extents                             162851/157871
>   Average size per extent                        76 KB
>   Fragmentation score                            1
>   [0-30 no problem: 31-55 a little bit fragmented: 56- needs defrag]
>   This directory (/usr) does not need defragmentation.
>   Done.
> ====================
>
> I can't recall if you mentioned this, but do you get a score as high or higher
> than 55?
>
> PS. As Javier suggests, if you're running out of space to defragment
> effectively, you can temporarily move say, the biggest ten files to a
> different fs to create some empty space, defragement the rest and then move
> back the ten large files.  These large files will be stored in as contiguous
> blocks as possible in the available space.
>
> PPS. It has already been mentioned the defragmentation operation may take
> longer than necessary if the fs is being written to at the time and
> particularly if there isn't much free space to start with.  Stopping
> intentional write ops should help with this.
>
> PPPS. I don't know if 'e2fsck -D' will make defragmenting faster, run in
> advance of e4defrag.  Some people think it does, but I have not read a clear
> explanation on why this might be so.


It showed the defrag info at the end of me running fsck on the file 
system.  I'd think it would be correct enough.  Even if it is only half 
right, it's quite a lot of fragmented files.  Running e4defrag -c shows 
it is fine tho.  I'm not sure why fsck shows one thing and e4defrag 
shows a very different result.  If I had to guess tho, I'd bet the 
results shown with fsck is more correct.  That file system is having 
files written to it in a disastrous way when it comes to keeping a file 
together.  Also, as it prints to the Konsole the results, it is changing 
from some larger number of extents to smaller, much smaller, in some 
cases.  It appears to be doing something.  I also notice that some files 
of about the same size take much longer for it to process which makes me 
think there is a lot of data being moved for some of the files.

Well, it has several TBs of free space.  Moving even 100GBs isn't going 
to matter that much.  A little info.


FILESYSTEM          %USED   USED AVAILABLE  TOTAL MOUNTED ON
/dev/mapper/data        79.7%   47.6T     12.2T          59.8T 
/home/dale/Desktop/Data
/dev/mapper/crypt        91.0%  42.9T      4.2T           47.1T 
/home/dale/Desktop/Crypt


The one I'm defragging is the one named Data.  The one for Crypt is more 
full and it shows very little fragmentation.

It has 12TBs free.  I'd think that would be more than enough for it to 
play around with.  Wouldn't it??

Well, it is moving along pretty well on defragging.  131750 of 162725 so 
far.  It may actually finish before I do my weekend updates.

I haven't used e2* commands in a long time.  The man page makes it sound 
interesting tho.  I'd guess it would be safe as well.  After all, ext4 
is ext2 with some added features.  ;-)

Either way, once this defrag is done, I'll run fsck again and see what 
it reports for the file system.  Just to see what it says and if it has 
improved.  I've already read that ext4 is really good at keeping files 
together.  I just thought the way files were being written may make it 
very hard for ext4 to keep up.

Dale

:-)  :-)