On 2021/8/24 上午1:24, David Sterba wrote:

On Sun, Aug 22, 2021 at 03:01:56PM +0800, Qu Wenruo wrote:

quoted

There is a long existing window that if we did some operations marking
qgroup INCONSISTENT during a qgroup rescan, the INCONSISTENT bit will be
cleared by rescan, leaving incorrect qgroup numbers unnoticed.

Furthermore, when we mark qgroup INCONSISTENT, we can in theory skip all
qgroup accountings.
Since the numbers are already crazy, we don't really need to waste time
updating something that's already wrong.

So here we introduce two runtime flags:

- BTRFS_QGROUP_RUNTIME_FLAG_CANCEL_RESCAN
   To inform any running rescan to exit immediately and don't clear
   the INCONSISTENT bit on its exit.

- BTRFS_QGROUP_RUNTIME_FLAG_NO_ACCOUNTING
   To inform qgroup code not to do any accounting for dirty extents.

   But still allow operations on qgroup relationship to be continued.

Both flags will be set when an operation marks the qgroup INCONSISTENT
and only get cleared when a new rescan is started.


With those flags, we can have the following enhancement:

- Prevent qgroup rescan to clear inconsistent flag which should be kept
   If an operation marks qgroup inconsistent when a rescan is running,
   qgroup rescan will clear the inconsistent flag while the qgroup
   numbers are already wrong.

- Skip qgroup accountings while qgroup numbers are already inconsistent

- Skip huge subtree accounting when dropping subvolumes
   With the obvious cost of marking qgroup inconsistent


Reason for RFC:
- If the runtime qgroup flags are acceptable

- If the behavior of marking qgroup inconsistent when dropping large
   subvolumes

- If the lifespan of runtime qgroup flags are acceptable
   They have longer than needed lifespan (from inconsistent time point to
   next rescan), not sure if it's OK.

How is this related to the patch from Marcos?

https://lore.kernel.org/linux-btrfs/20210617123436.28327-1-mpdesouza@suse.com/ (local)

If there's way to cancel the rescan, does this patchset fix the possible
problems?

It's a coincidence, as my primary objective here is to solve the final
piece of qgroup slow down from subvolume dropping.

Although the solution I take would not require ioctl to cancel a rescan
and also works for cases like qgroup inherit.

Thanks,
Qu