Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.gentoo.user > #116281

Re: [gentoo-user] File system defragmentation. Something that can resume after stopping.

Show all headers | View raw

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 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.

> 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.

> 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

> :-)  :-)

-- 
Alan Mackenzie (Nuremberg, Germany).

Back to linux.gentoo.user | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

[gentoo-user] File system defragmentation. Something that can resume  after stopping. Dale <rdalek1967@gmail.com> - 2026-05-13 00:50 +0200
  Re: [gentoo-user] File system defragmentation. Something that can  resume after stopping. Jack <ostroffjh@users.sourceforge.net> - 2026-05-13 01:10 +0200
    Re: [gentoo-user] File system defragmentation. Something that can  resume after stopping. Dale <rdalek1967@gmail.com> - 2026-05-13 04:30 +0200
    Re: [gentoo-user] File system defragmentation. Something that can resume  after stopping. Michael <confabulate@kintzios.com> - 2026-05-13 12:50 +0200
    Re: [gentoo-user] File system defragmentation. Something that can  resume after stopping. Dale <rdalek1967@gmail.com> - 2026-05-13 13:40 +0200
        Re: [gentoo-user] File system defragmentation. Something that can resume  after stopping. Michael <confabulate@kintzios.com> - 2026-05-13 14:10 +0200
        Re: [gentoo-user] File system defragmentation. Something that can  resume after stopping. Dale <rdalek1967@gmail.com> - 2026-05-13 18:00 +0200
          Re: [gentoo-user] File system defragmentation. Something that can  resume after stopping. Alan Mackenzie <acm@muc.de> - 2026-05-13 18:50 +0200
            Re: [gentoo-user] File system defragmentation. Something that can  resume after stopping. Dale <rdalek1967@gmail.com> - 2026-05-13 20:20 +0200
              Re: [gentoo-user] File system defragmentation. Something that can  resume after stopping. Dale <rdalek1967@gmail.com> - 2026-05-14 00:10 +0200
                  Re: [gentoo-user] File system defragmentation. Something that can resume  after stopping. Michael <confabulate@kintzios.com> - 2026-05-14 12:40 +0200
                [gentoo-user] Re: File system defragmentation. Something that can resume after stopping. Holger Hoffstätte <holger@applied-asynchrony.com> - 2026-05-14 18:20 +0200
                  Re: [gentoo-user] Re: File system defragmentation. Something that can resume  after stopping. Michael <confabulate@kintzios.com> - 2026-05-14 19:40 +0200
                Re: [gentoo-user] File system defragmentation. Something that can  resume after stopping. Dale <rdalek1967@gmail.com> - 2026-05-14 19:10 +0200
                Re: [gentoo-user] File system defragmentation. Something that can  resume after stopping. Dale <rdalek1967@gmail.com> - 2026-05-15 21:40 +0200
                Re: [gentoo-user] File system defragmentation. Something that can  resume after stopping. Dale <rdalek1967@gmail.com> - 2026-05-17 23:30 +0200
                Re: [gentoo-user] File system defragmentation. Something that can  resume after stopping. Mitchell Dorrell <mwd@psc.edu> - 2026-05-14 19:50 +0200

csiph-web