LOL Thanks for confirming. There’s a Timeshift screenshot on this thread which triggered my memory that I most definitely toggled on qgroups since it said “recommended” in Timeshift:
Aren't quotas enabled by default on BTRFS? Hmm...
The bug referenced here:
opened 09:07PM - 02 Dec 20 UTC
closed 07:59AM - 28 May 22 UTC
If ...
* the option "Enable BTRFS qgroups (recommended)" is _disabled_ in the G… UI settings -and-
* btrfs quotas is disabled on the system (`sudo btrfs quota disable /`)
... Timeshift fails to completely remove snapshots on the first try.
**e. g. (sample output)**
```
-------------
[...]
E: ERROR: can't list qgroups: quotas not enabled
E: btrfs returned an error: 256
E: Failed to query subvolume quota
[...]
-------------
Removing snapshot: 2020-12-02_20-08-29
Deleting subvolume: @ (Id:1513)
Deleted subvolume: @ (Id:1513)
Destroying qgroup: 0/1513
E: Failed to destroy qgroup: '0/1513'
E: Failed to remove snapshot: 2020-12-02_20-08-29
-------------
```
**Problem:** On this first try everything except the snapshots "`info.json`" file is actually deleted. This causes Timeshift to still list this snapshot! A second remove attempt then successfully removes the already deleted snapshot from the list.
This behaviour seriously messes up scheduling because actually deleted snapshots are still counted.
I assume the check and failure to "destroy qgroup" error causes the remove process to exit before info.json and the snapshot folder are deleted.
---
**System:**
- Arch Linux with kernel 5.9.11-arch2-1
- XFCE
- Timeshift version 20.11.1
**Note:** I have experienced some serious system freezes on a low-spec machine caused by [btrfs-cleaner] and [btrfs-transaction] after removing snapshots through timeshift. This issue vanishes when btrfs quotas are disabled. That's when I noticed the above bug.
No longer seems to apply to those using Snapper, so thought it would be safe to manually disable quotas via commandline - and that helped with the HDD churn/IO.
5 Likes