On 2022/10/12 20:56, David Sterba wrote:
On Tue, Oct 11, 2022 at 10:50:06AM -0400, Sasha Levin wrote:
From: Qu Wenruo <wqu@xxxxxxxx>
[ Upstream commit e562a8bdf652b010ce2525bcf15d145c9d3932bf ]
Introduce a new runtime flag, BTRFS_QGROUP_RUNTIME_FLAG_CANCEL_RESCAN,
which will inform qgroup rescan to cancel its work asynchronously.
This is to address the window when an operation makes qgroup numbers
inconsistent (like qgroup inheriting) while a qgroup rescan is running.
In that case, qgroup inconsistent flag will be cleared when qgroup
rescan finishes.
But we changed the ownership of some extents, which means the rescan is
already meaningless, and the qgroup inconsistent flag should not be
cleared.
With the new flag, each time we set INCONSISTENT flag, we also set this
new flag to inform any running qgroup rescan to exit immediately, and
leaving the INCONSISTENT flag there.
The new runtime flag can only be cleared when a new rescan is started.
Qu, does this patch make sense for stable on itself? It was part of a
series adding some new flags and the sysfs knob. As I read it there's a
case where it can affect how the rescan is done and that it can be
cancelled but still am not sure if it's worth the backport.
Considering the qgroup still lacks a way to handle large subvolume drop,
and a lot of things can mark qgroup inconsistent halfway, I think
backporting this patch itself is not that bad.
The problem is, why only backporting this one?
To me, it would make more sense to backport either all or none.
Sure, if we can cancel rescan it's an improvement, but rescan itself is
already relatively cheap compared to other qgroup operations.
Thus I prefer to backport all the qgroup patches.
Thanks,
Qu
