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

Michael <[email protected]> Thu, 14 May 2026 11:30:34 +0100
Newsgroups	gmane.linux.gentoo.user
Message-ID	<9620917.CDJkKcVGEf@lenovo>
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.
signature.asc (application/pgp-signature, 870 B)