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

On 5/15/26 2:31 PM, Dale wrote:
> On 5/14/26 12:01 PM, Dale wrote:
>> Either way, once this defrag is done, I'll run fsck again and see what
>> it reports for the file system.  Just to see what it says and if it has
>> improved.  I've already read that ext4 is really good at keeping files
>> together.  I just thought the way files were being written may make it
>> very hard for ext4 to keep up.
>>
>> Dale
>>
>> 🙂  🙂
>
> It finished while I was trying to finish up that tree.  This is the end
> result.
>
>
>           Success:                        [ 145562/162777 ]
>           Failure:                        [ 17215/162777 ]
>           Total extents:                  1828237->777364
>           Fragmented percentage:           69%->32%
>
>
> I suspect some files are to large or something.  Either way, it claims
> to have improved the fragmentation quite a lot.  It seems that the fsck
> output was more correct than the output of the e4defrag -c test.
>
> At least I can do my updates in the morning and not have to stop it.  I
> didn't think it would make it.  I do plan to run it again after my
> updates are done to see what it does.  I plan to do a fsck first, then
> run e4defrag -c, compare the fragmentation info of the two, then run
> e4defrag again.
>
> Now back to work on that tree.  I'm getting close to done.
>
> Dale
>
> :-)  :-)


I finished my updates and ran fsck again.  This is what I get now, even 
after the software was running for a few days after the defrag finished.


data: ***** FILE SYSTEM WAS MODIFIED *****

       163559 inodes used (0.02%, out of 1007124480)
         1178 non-contiguous files (0.7%)
          219 non-contiguous directories (0.1%)
              # of inodes with ind/dind/tind blocks: 0/0/0
              Extent depth histogram: 127071/36363/117
  12854547386 blocks used (79.77%, out of 16113983488)
            0 bad blocks
         5039 large files

       151716 regular files
        11833 directories
            0 character device files
            0 block device files
            0 fifos
            0 links
            0 symbolic links (0 fast symbolic links)
            0 sockets
------------
       163549 files



So, it was at about 40% before and is less than 1% now.  At least we 
know e4defrag works well.  Also, it seems the e4defrag output isn't 
always correct about fragmentation.  It seems whatever method the fsck 
tool uses is more accurate as to how much fragmentation there is.  If it 
still showed a high number, I'd suspect the fsck tool was wrong.  It 
seems that if one wants a true fragmentation number, run the fsck tool 
and then check the output when it is done.

At least now I know the file system is in good shape.  The fragmentation 
is also at a minimum amount.  Plus, I learned something.  It might be 
that several of us did.

Dale

:-)  :-)

P. S.  Now I want to run fsck on the other large file systems and see 
what it reports there.  :/