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

Javier Martinez <[email protected]> Thu, 14 May 2026 16:53:22 +0200
Newsgroups	gmane.linux.gentoo.user
Message-ID	<[email protected]>
El 14/5/26 a las 12:30, Michael escribió:
> 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.

Yep, I don't remember where was the last time I did a "defragmentation", 
I think never.... I usually do the trick moving dirs to and rollback to 
reduce it. Normally last files written are those which usually gets 
fragmented
OpenPGP_0x57E64E0B7FC3BEDF.asc (application/pgp-keys, 3 KB)
OpenPGP_signature.asc (application/pgp-signature, 840 B)