On 2022/2/2 08:07, Qu Wenruo wrote:
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.
Here comes the new test to make sure "btrfs fi defrag -c" can do what it
should do:
https://patchwork.kernel.org/project/linux-btrfs/patch/20220202083158.68262-1-wqu@xxxxxxxx/
And of course, current (with the max capacity check) kernel can pass
both tests without problem, proving those two aspects are not in
conflict at all.
Thanks,
Qu
Thanks,
Qu
