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

Javier Martinez <[email protected]> Wed, 13 May 2026 21:13:20 +0200
Newsgroups	gmane.linux.gentoo.user
Message-ID	<[email protected]>
El 13/5/26 a las 20:11, Dale escribió:
> On 5/13/26 11:48 AM, Alan Mackenzie wrote:
>> Hello, Dale.
>>
>> On Wed, May 13, 2026 at 10:56:21 -0500, Dale wrote:
>>> On 5/13/26 7:05 AM, Michael wrote:
>>>> On Wednesday, 13 May 2026 12:35:50 British Summer Time Dale wrote:
>>>>> Well, as it is, I'm kinda stuck.  I'd have to buy at least 3 or 4 hard
>>>>> drives to put a different file system on and then transfer everything
>>>>> over.  Given the price of hard drives, I don't plan to buy any hard
>>>>> drives any time soon.  Plus, for most of my uses, ext4 does fine.
>>>>> The biggest thing on this one file system, the files are always being
>>>>> added to and plus new stuff being added.  My other file systems, I
>>>>> copy files over but they are all done with one long write since they
>>>>> are complete which makes them more likely to not be fragmented.  Once
>>>>> they there, they don't change anymore.
>>>>> I was just hoping someone with some serious scripting skills had
>>>>> invented this wheel already.  If they have, it sure is well hidden. Me
>>>>> and Duck Duck Go couldn't find it and it seems no one else is aware
>>>>> of it either.  LOL
>>>>> I'll just have to leave it running and maybe skip updates this
>>>>> weekend.  Maybe it will finish by next weekend.  I should have ran it
>>>>> within screen.  I just wonder how long it will stay with the lower
>>>>> amount of fragmentation.  It's not like it isn't going to continue to
>>>>> change a lot.  Heck, it's adding about 5 to 6MB/s as I type.  By the
>>>>> time it finishes running, it may need to be run again.  :/
>> Maybe these constant changes on the file system are making the
>> defragmentation take longer, possibly a lot longer.  Could you not
>> temporarily make these changes on a different file system, then update
>> the main one later when it's ready?
> 
> Well, it's probably not helping it any.  I kiinda like to keep that 
> software running but I could stop it.  The defrag is moving pretty fast 
> tho.  It sure is doing a lot of files tho.  Some are really needing some 
> work.  This is a example, name of files removed because they are very long.
> 
> 
> 
> [70691/162725]/home/dale/Desktop/Data/file1  extents: 33 -> 17 [ OK ]
> [70692/162725]/home/dale/Desktop/Data/file2  extents: 34 -> 6  [ OK ]
> [70693/162725]/home/dale/Desktop/Data/file3  extents: 34 -> 11 [ OK ]
> [70694/162725]/home/dale/Desktop/Data/file4  extents: 33 -> 13 [ OK ]
> 
> 
> I'm no guru or anything but that 34 to 6 looks like a improvement. Some 
> don't change or change very little but some are like that or more.
> 
> 
>>>>> Well, it was a thought.
>>>>> Dale
>>>>> :-)  :-)
>>>> Another thought, are all the files requiring defragmentation in the 
>>>> same
>>>> directory?  If not, then you can create directories/subdirectories and
>>>> defrag them individually.  The defrag operation will not be any more
>>>> efficient in itself, but directories which have had no changes in their
>>>> content will not need to be defragmented again.  After the first run
>>>> future defragmentation operations will last a shorter time.
>>>> Someone more capable at scripting could probably hack something to 
>>>> check
>>>> file modification times and feed the output directories to e4defrag, to
>>>> save you the trouble performing the above manually.
>>> I may be wrong on this but I think when you defrag, it kinda has to be
>>> done from start to finish.  I notice that file 1 is not the first file
>>> when I sort alphabetically but seems to be close when sorted by created
>>> first.  If I recall correctly, when you defrag a file somewhere in the
>>> middle of the drive, it changes other files as well as it is trying to
>>> make things fit.  That is what I sort of recall Spinrite and such doing
>>> way back in the day.  It could be that ext4 has a new method of doing
>>> this tho.  To be honest, I'm not sure it is going to do any good to have
>>> a resume option as it may not actually work if files it previously
>>> defragged has changed, which on this file system is totally possible and
>>> even likely.
>> I vaguely recall using a defragmenter on a proprietary operating system
>> arount 40 years ago.  It worked (when it worked) by repeatedly copying
>> the fragments of a file to a piece of contiguous disk space, updating
>> file pointers, then freeing up the fragments.  It used a "fail-safe" way
>> of updating the pointers such that an update was either done completely
>> or not done at all (to protect the disk against power failures).
>>
>> This decades old defragmenter could be restarted in the middle of a run,
>> for example when one broke off an operation to power the PC down and go
>> home.
> 
> Back in the day, We used Spinrite on whatever Windows 98 and such used 
> back then.  Crap, can't recall what it was called now.  Most likely not 
> used much today.  I'm sure ext4 is a lot different than whatever was 
> used back then.  I don't think they even had the idea of a journal or 
> anything for a file system.
> 
> 
>>> It could be that the reason that e4defrag doesn't have this option is
>>> because it doesn't work well.  It may trip over its own feet or
>>> something.  It might be why no one else has did something to work around
>>> it either.
>> I can't really imagine that modern free software is going to be less
>> capable than 40 year old proprietary stuff.  Maybe e4defrag is more able
>> than you're giving it credit for, though with a multi-day operation under
>> way, I wouldn't do anything to disturb it either.
>>
>> Maybe your disk has become just a little bit too full (it happens to all
>> of us), such that the amount of contiguous empty space is less than the
>> size of the files to be defragmented.
> 
> 
> I think it is more that ext4 is way different than what was used 40 
> years ago.  To be fair, my other file systems don't have much if any 
> fragmented files.  When I check, out of a ton of files, I may have a 
> few, 4 or 6 or so, files that are slightly fragmented.  What makes this 
> one so bad is that it downloads a little bit of the file, then other 
> files are written.  Then it goes back and downloads a little more of the 
> first file, which now has to be written somewhere else. It rinses and 
> repeats this on hundreds of files before the file is complete.  I'm not 
> sure any file system could do any better given the way the files are 
> changed.  Even if ext4 would try to defrag itself on occasion, that file 
> system stays busy.  I'm not sure how much my manual defragging is going 
> to help.
> 
> This file system that is so fragmented is at 79%.  My other file system 
> that has very few fragmented files is at around 91%.  I'm hoping the 
> price of drives will come down at some point.  I really need to expand 
> that one at 91%.  I try to stay below 90% at least.
> 
> 
>>> Oh well.  Maybe it will finish, in a week or two.  It's on file 74,041
>>> of 162,725.  It's eating the elephant.  One bite at a time. LOL
>> I wish you all the best!
>>
>>> Dale
>>> :-)  :-)
> 
> 
> Thanks much.  I need all the good wishes I can get most days.  o_O You 
> have a great day as well.
> 
> Dale
> 
> :-)  :-)
> 
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
OpenPGP_0x57E64E0B7FC3BEDF.asc (application/pgp-keys, 3 KB)
OpenPGP_signature.asc (application/pgp-signature, 840 B)