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

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

:-)  :-)