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