Re: [PATCH 1/2] btrfs: defrag: add under utilized extent to defrag target list

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

On 2024/2/7 07:11, Qu Wenruo wrote:
[...]
>>
>> item 6 key (257 EXTENT_DATA 0) itemoff 15810 itemsize 53
>> generation 7 type 1 (regular)
>> extent data disk byte 1104150528 nr 134217728
>> extent data offset 0 nr 8650752 ram 134217728
>> extent compression 0 (none)
>> item 7 key (257 EXTENT_DATA 8650752) itemoff 15757 itemsize 53
>> generation 8 type 1 (regular)
>> extent data disk byte 1238368256 nr 33292288
>> extent data offset 0 nr 33292288 ram 33292288
>> extent compression 0 (none)
>
> This behavior is unexpected, as we should redirty the whole 40M, but the
> first 8.25M didn't got re-dirtied is a big problem to me.
> Will look into the situation.
>

Got the cause.

The problem is related to a check in the existing code:

	range_len = em->len - (cur - em->start);

	/* Skip too large extent */
	if (range_len >= extent_thresh)
		goto next;

Since the range_len is to the end of the extent, thus at the beginning
8MiB it's always larger than the 32M extent threshold.

But at around 8M, we no longer meet the 32M extent threshold thus begin
to defrag the remaining 32M.

To me, the check itself is not correct, it should go em->len instead.

But on the other hand, that "goto next" would skip our wasted
ratio/bytes checks.

At least with that fixed, we won't make the situation worse though.

I'll submit a fix for it with a test case.

Thanks for exposing the bug,
Qu