Re: [PATCH] btrfs: make qgroup rescan work to handle fs freezing

[Qu Wenruo <wqu@suse.com>]

在 2026/9/22 16:00, Andrei Borzenkov 写道:
> On Tue, Sep 22, 2026 at 12:46 AM Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>>
>>
>>
>> 在 2026/9/21 22:42, David Sterba 写道:
>>> On Mon, Sep 21, 2026 at 04:36:51PM +0800, Dongjiang Zhu wrote:
>>>> 在 2026/9/21 15:03, Qu Wenruo 写道:
>>>>> [BUG]
>>>>> There is a bug report that a running qgroup rescan can fail a pm
>>>>> suspension:
>>>>>
>>>>>     [ T278489] Freezing remaining freezable tasks
>>>>>     [ T278489] Freezing remaining freezable tasks failed after 20.003 seconds (0 tasks refusing to freeze, wq_busy=1):
>>>>>     [ T278489] Showing freezable workqueues that are still busy:
>>>>>     [...]
>>>>>     [ T278489]   pwq 56: cpus=0-13 flags=0x4 nice=0 active=1 refcnt=16
>>>>>     [ T278489]     in-flight: 205929:btrfs_work_helper [btrfs] for 111s
>>>>>
>>>>> [CAUSE]
>>>>> Btrfs qgroup rescan is running in a workqueue, and when the fs is
>>>>> frozen, btrfs_start_transaction() will sleep on sb_start_intwrite().
>>>>>
>>>>> But a sleeping workload still counts as active for the workqueue until
>>>>> the workload exits.
>>>>>
>>>>> So the qgroup rescan item will sleep on the frozen fs, and fail the pm
>>>>> suspension.
>>>>>
>>>>> [FIX]
>>>>> I strongly doubt whether we should even use a workqueue for the qgroup
>>>>> rescan workload, a kthread would be a more suitable choice and can handle
>>>>> fs and process freezing way better.
>>>>> But that will be a long term solution.
>>>>
>>>> Hi Qu,
>>>>
>>>> Thanks for working on this.
>>>>
>>>> I recently posted an RFC series addressing qgroup rescan lifecycle
>>>> issues around quota disable/enable, error cleanup, and remounts [1].
>>>>
>>>>    From the recent discussion, I got the impression that full qgroups
>>>> might be phased out or substantially reworked. Is that a fair
>>>> understanding?
>>>
>>> Do you have link to the dicussion? Phasing out current qgroups in the
>>> full mode would be a functionality loss and we don't have a replacement.
>>> On the design level, the qgroups are general enough to cover the COW
>>> design, sharing. The compression was originally intended but IIRC we
>>> don't account compressed extents separately.
>>
>> The biggest problem is the insolvable nature of tracking the owner of
>> every extent vs changing all extent owners in one snapshot
>> creation/deletion.
>>
>> This means qgroup is only reliable with rigid subvolume layout, which is
>> never the common use case.
>>
>> And all the current workarounds are killing qgroup limit functionality,
>> requiring endless rescans again and again.
>>
>>>
>>> Reworking could happen, the performance hit of qgroups in full mode has
>>> been a problem since beginning, but I don't see any easy change there.
>>> If the sematics change we'd need to add another mode, like we have the
>>> simple quota mode.
>>
>> For now the only major user of qgroup original mode is snapper (for
>> subvolume cleanup policy), and we're already pushing snapper to not
>> enable qgroup by default (although no good progress yet).
>>
> 
> The major use case of qgroup-like functionality is snapshot
> management. Whether it is implemented by snapper or by something else.
> Without the ability to get an accurate estimation of the real
> subvolume space consumption (how much space will become free after
> deleting this subvolume) any snapshot based workflow becomes a
> nightmare.

Then let me give you a very simple example.

There are a dozen of directories in a non-btrfs fs, then one wants to 
delete some of those directories to free up space.

What would a regular user do to determine how many bytes can be freed by 
deleting a directory? They run "du -sh".

I see no difference between running "btrfs fi du" on btrfs, and "du -sh" 
on a non-btrfs for this particular case.


Furthermore, even snapper didn't need to use qgroup for 90% or even 99% 
of users.
Just disable qgroup on an openSUSE/SLE systems (and that's already most 
people do), snapper will still do regular snapshot rotation all fine.

You're asking 99% of end users to take the burden that only 1% users 
really need.
That's not how things should work.

> 
>> I'm open to new designs like simple-quota, or maybe "reference" only
>> accounting (making it almost the same as the quota files supported by
>> all other fses).
>>
> 
> I do not see how "reference only" is useful in any way. We already
> have enough tools showing us "used" space exceeding the physical
> device size by an order of magnitude.
> 
>> But I do not think full quota mode should be a feature that should be
>> enabled by default.
>>