* A possible way to reduce free space fragmentation?
@ 2025-01-31 19:01 Artem S. Tashkinov
2025-02-01 15:38 ` Andreas Dilger
0 siblings, 1 reply; 4+ messages in thread
From: Artem S. Tashkinov @ 2025-01-31 19:01 UTC (permalink / raw)
To: linux-ext4
Hello,
ext4 has no free space defragmentation and at most you can use e4defrag
to defragment individual files. I now have a 24GB ext4 filesystem that
has only 7GB of space occupied however it has small files scattered all
over it and now bigger files occupy more than one extent and I cannot
reduce fragmentation to zero. One way to approach that would be to
shrink the volume and then defragment it but that will involve a ton of
disk writes and unnecessary tear and wear. Is it possible to modify the
e4degrag utility to move small defragmented files, so that they were
placed consecutively instead of being randomly spread all over the disk?
Regards,
Artem
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: A possible way to reduce free space fragmentation?
2025-01-31 19:01 A possible way to reduce free space fragmentation? Artem S. Tashkinov
@ 2025-02-01 15:38 ` Andreas Dilger
2025-02-01 15:48 ` Artem S. Tashkinov
0 siblings, 1 reply; 4+ messages in thread
From: Andreas Dilger @ 2025-02-01 15:38 UTC (permalink / raw)
To: Artem S. Tashkinov; +Cc: linux-ext4
It should be possible to run "find $DIR -type f -size -1M | xargs e4defrag" to only defragment files below 1MB (or whatever you consider "small").
However, I don't recall if e4defrag will move a file if the new file has the same number of fragments as the original (presumably both "1") or leave it in place. That would be possible add an option to change.
Alternately, just run the "find" above to find small files and then "cp $F $F.tmp && mv $F.tmp $F" to rewrite those files into new blocks, and hope mballoc will move them to a better location.
Cheers, Andreas
> On Jan 31, 2025, at 14:02, Artem S. Tashkinov <aros@gmx.com> wrote:
>
> Hello,
>
> ext4 has no free space defragmentation and at most you can use e4defrag
> to defragment individual files. I now have a 24GB ext4 filesystem that
> has only 7GB of space occupied however it has small files scattered all
> over it and now bigger files occupy more than one extent and I cannot
> reduce fragmentation to zero. One way to approach that would be to
> shrink the volume and then defragment it but that will involve a ton of
> disk writes and unnecessary tear and wear. Is it possible to modify the
> e4degrag utility to move small defragmented files, so that they were
> placed consecutively instead of being randomly spread all over the disk?
>
> Regards,
> Artem
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: A possible way to reduce free space fragmentation?
2025-02-01 15:38 ` Andreas Dilger
@ 2025-02-01 15:48 ` Artem S. Tashkinov
2025-02-02 20:15 ` Theodore Ts'o
0 siblings, 1 reply; 4+ messages in thread
From: Artem S. Tashkinov @ 2025-02-01 15:48 UTC (permalink / raw)
To: Andreas Dilger; +Cc: linux-ext4
On 2/1/25 3:38 PM, Andreas Dilger wrote:
> It should be possible to run "find $DIR -type f -size -1M | xargs e4defrag" to only defragment files below 1MB (or whatever you consider "small").
I have smaller files completely defragmented already.
The issue is a dozen of 50-250MB files that span multiple extents (up to
30).
>
> However, I don't recall if e4defrag will move a file if the new file has the same number of fragments as the original (presumably both "1") or leave it in place. That would be possible add an option to change.
>
> Alternately, just run the "find" above to find small files and then "cp $F $F.tmp && mv $F.tmp $F" to rewrite those files into new blocks, and hope mballoc will move them to a better location.
cp doesn't even support posix_fallocate(), rsync does but this process
will be a complete guesswork as I have no idea which files are worth
moving and which are not.
Considering there are holes that can include files in their entity, this
must be done by something that knows what it's doing.
Best regards,
Artem
>
> Cheers, Andreas
>
>> On Jan 31, 2025, at 14:02, Artem S. Tashkinov <aros@gmx.com> wrote:
>>
>> Hello,
>>
>> ext4 has no free space defragmentation and at most you can use e4defrag
>> to defragment individual files. I now have a 24GB ext4 filesystem that
>> has only 7GB of space occupied however it has small files scattered all
>> over it and now bigger files occupy more than one extent and I cannot
>> reduce fragmentation to zero. One way to approach that would be to
>> shrink the volume and then defragment it but that will involve a ton of
>> disk writes and unnecessary tear and wear. Is it possible to modify the
>> e4degrag utility to move small defragmented files, so that they were
>> placed consecutively instead of being randomly spread all over the disk?
>>
>> Regards,
>> Artem
>>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: A possible way to reduce free space fragmentation?
2025-02-01 15:48 ` Artem S. Tashkinov
@ 2025-02-02 20:15 ` Theodore Ts'o
0 siblings, 0 replies; 4+ messages in thread
From: Theodore Ts'o @ 2025-02-02 20:15 UTC (permalink / raw)
To: Artem S. Tashkinov; +Cc: Andreas Dilger, linux-ext4
On Sat, Feb 01, 2025 at 03:48:16PM +0000, Artem S. Tashkinov wrote:
>
>
> On 2/1/25 3:38 PM, Andreas Dilger wrote:
> > It should be possible to run "find $DIR -type f -size -1M | xargs e4defrag" to only defragment files below 1MB (or whatever you consider "small").
>
> I have smaller files completely defragmented already.
>
> The issue is a dozen of 50-250MB files that span multiple extents (up to
> 30).
How big are the extents? If you are performing large sequential
reads, a few seeks every few megabytes is really not a big deal from a
performance perspective, and it's certainly not worth the huge amount
of time that a perfect defragmentation would take (since that would
require moving smaller files out of the way to free up enough
contiguous space for a big file).
This is why Windows defraggers have mostly fallen out of faver, and
why no one has really found it worthwhile to invest more effort in
improving e4defrag (either the userspace program or the underlying
kernel infrastructure).
> > > ext4 has no free space defragmentation and at most you can use e4defrag
> > > to defragment individual files. I now have a 24GB ext4 filesystem that
> > > has only 7GB of space occupied however it has small files scattered all
> > > over it and now bigger files occupy more than one extent and I cannot
> > > reduce fragmentation to zero. One way to approach that would be to
> > > shrink the volume and then defragment it but that will involve a ton of
> > > disk writes and unnecessary tear and wear. Is it possible to modify the
> > > e4degrag utility to move small defragmented files, so that they were
> > > placed consecutively instead of being randomly spread all over the disk?
Anything is *possible*. Whether anyone thinks its worth their
development time is a different question. Many years ago, at a
face-to-face ext4 developer's get together, we had sketched out some
ideas for how we might do this. It included ways to block certain
areas of the disk from being used for normal block allocation, and an
extended ext4-specific fallocate-like ioctl which e4defrag could use
to allocate blocks in a specific portion of the file system.
But no company has a business case where implementing this feature
would have a positive return on investment; no hobbyist has been
interested in doing in their free time; and unfortunately, this is too
complicated of a project for a Google Summer of Code, Outreachy, or
other Intern project.
If you're interested, I'm happy to chat. But basically, this is a
"patches are welcome; send us code and we'll be happy to review them"
sort of situation.
Cheers,
- Ted
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2025-02-02 20:18 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-01-31 19:01 A possible way to reduce free space fragmentation? Artem S. Tashkinov
2025-02-01 15:38 ` Andreas Dilger
2025-02-01 15:48 ` Artem S. Tashkinov
2025-02-02 20:15 ` Theodore Ts'o
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox