Re: [PATCH for v5.15 2/2] btrfs: defrag: use the same cluster size for defrag ioctl and autodefrag

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

On 2022/2/16 20:37, David Sterba wrote:
> On Wed, Feb 16, 2022 at 03:09:08PM +0800, Qu Wenruo wrote:
>> No upstream commit.
>> Since the bug only exists between v5.11 and v5.15. In v5.16 btrfs
>> reworked defrag and no longer has this bug.
>
> I'm not sure this will work as a stable patch. A backport of an existing
> upstream patch that is only adapted to older stable code base is fine
> but what is the counterpart of this patch?

The whole ill-fated rework on defrag.

>
>>
>> [BUG]
>> Since commit 7f458a3873ae ("btrfs: fix race when defragmenting leads to
>> unnecessary IO") autodefrag no longer works with the following script:
>
> The bug does no seem to be significant, autodefrag is basically a
> heuristic so if it does not work perfectly in all cases it's still OK.

Normally I'd say yes.

But I don't want to surprise end users by suddenly increase their IO for
autodefrag in the next LTS.

This bug is really setting a high bar (or low IO expectation) for end users.

And another thing is, I can definitely create a local branch with this
fixed to test against fixed autodefrag code, but that won't make much sense.

Thus getting this merged could provide a more realistic baseline for
autodefrag.


Finally, one lesssen I learnt from the defrag thing is, if we allow some
untested/undefined corner cases, it will bite us eventually.

So I really want autodefrag to behave just like ioctl defrag, with a
pre-defined and predictable (at least not under races) behavior.

Thanks,
Qu