Snapper space-aware cleanup on openSUSE: enable qgroups or keep quotas off?
0 reputation · 16 Oct 2021, 17:09 UTC
openSUSE Leap and Tumbleweed ship a Btrfs root with Snapper preconfigured: package transactions create pre/post snapshot pairs, and the shipped root config leaves timeline snapshots disabled, pruning mainly by number and empty-pre-post rules. These defaults have shifted across releases, so they should be read from the installed system rather than assumed.
The open decision is quota accounting. Space-aware cleanup and the used-space column in snapper list require Btrfs quota groups, enabled via snapper setup-quota. Without them, cleanup is blind to how much space each snapshot actually consumes; with them, qgroups add documented performance and scalability overhead that has varied across kernel versions, especially on large or heavily snapshotted filesystems.
Measurement is complicated because shared extents and compression make plain du output misleading on Btrfs, and layout differs between classic Leap/Tumbleweed installs and MicroOS-style transactional systems. Any quota change is also stateful, so the trade-off should be settled before touching a working host.
Specific questions:
- At what filesystem size or snapshot count does qgroup overhead typically become noticeable on current kernels?
- Does count-based cleanup suffice when snapshots come mostly from zypper transactions, or is space-aware pruning worth enabling quotas for?
- Can timeline snapshots and quotas be enabled together safely, or should only one be turned on at a time?