Re: [PATCH] btrfs: add test case to verify that btrfs won't waste IO/CPU to defrag compressed extents already at their max size

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

On 2022/2/1 23:14, David Sterba wrote:
> On Thu, Jan 27, 2022 at 01:53:06PM +0800, Qu Wenruo wrote:
>> There is a long existing bug in btrfs defrag code that it will always
>> try to defrag compressed extents, even they are already at max capacity.
>
> As commended under the patch, this not considered a bug, because the
> defrag ioctl is expected to reshuffle the extents, with or without
> compression and improving the compression ratio if asked to recompress
> with hither level. What is not perfect is the kernel side that could try
> harder to merge extents into bigger contiguous chunks, but as long as
> the compression is involved it's not possible to decide if the extents
> should be skipped or not.

What I can do is to add extra test to make sure if "btrfs fi defrag -c"
always defrag the file no matter whatever.

To me, these two factors don't conflict with each other at all.

Thanks,
Qu