Re: Enabling qgroups causes 2+ minute hangs

[Max Chernoff <git@maxchernoff.ca>]

Hi Qu,

On Fri, 2026-05-01 at 19:36 +0930, Qu Wenruo wrote:
> 在 2026/5/1 19:10, Max Chernoff 写道:
> > Yesterday, I accidentally enabled qgroups on my root filesystem, and I
> > started experiencing severe system hangs. When I disabled the quotas
> > again, the problem went away completely.
> >
> > I'm currently using "btrfs-progs v6.19.1" with "Linux
> > 6.19.14-200.fc43.x86_64" on Fedora 43 x86_64. I have "/boot/" and "/" in
> > the same btrfs filesystem, which is on 2 NVMe disks with RAID0 data and
> > RAID1 metadata. I have a swap partition on both disks, and I'm not using
> > a swap file. When I booted into the "initrd" for my rescue kernel
> > ("6.15.8-200.fc42.x86_64"), I saw the exact same issue. My filesystem
> > has 309 snapshots and 17 subvolumes;
>
> This is the problem, btrfs qgroup performance is directly bounded to the
> number of shared extents.
>
> If you have over 50 snapshots, it's going to be ugly, if you have 300,
> it's going to be hell.
>
> And it has no good way to resolve, the qgroup rescan (triggered by the
> enabling) normally should not block normal operations, but for such
> heavily snapshotted systems, even doing qgroup accounting for a single
> extent can take a very long time.
> As such backref walk will need to iterate through all the subvolumes
> that own that extent, in your case it can be 309 subvolumes.
>
> This long time of accounting just one extent will block the transaction
> for a long time.
>
> There are a lot of optimizations merged, but nothing can resolve the
> root problem.

That makes a lot of sense to me, thanks.

> >      WARNING: qgroups enabled on a filesystem with lots of snapshots, expect poor performance
>
>  From btrfs-quota(8):
>
>       When quotas are activated, they affect all extent processing, which
>       takes a performance  hit.  Activation  of qgroups is not
>       recommended unless the user intends to actually use them.
>
> >
> > to dmesg to make it easier to debug?
>
> Normally it's not that a huge problem as the normal amount of snapshots
> are only around one or two dozens.
>
> Furthermore, if you only have subvolumes but no snapshot, and no shared
> extent (aka, no dedup), then the qgroup performance impact should be
> very tiny.
>
> But unfortunately that's not the case for you.
>
> Even with that dmesg warning, if your system is already hanging, I'm not
> sure if the end user will even be able to see that message.

The system does eventually recover after 10 minutes or so, so I would
see the warning _eventually_. But yeah, for the message to be useful, it
requires the combination of lots of snapshots + qgroups enabled
unknowingly + a user who reads dmesg---all of these apply to me, but
probably not to very many other people :).

> I can try to add a check inside "btrfs qgroup enable" command, which
> will checks how many snapshots, if that's beyond 10, give a warning with
> timeout before enabling traditional qgroups.

That won't help me in this specific case, since another program enabled
it via an ioctl:

    https://github.com/systemd/systemd/issues/41903

    https://github.com/systemd/systemd/blob/v260.1/src/shared/btrfs-util.c#L584-L609

Thanks,
-- Max