Am 21.11.19 um 21:30 schrieb Christian Pernegger: > Definitely enabled, then. ... ... ... There it is: Timeshift has a > pre-selected checkbox "enable BTRFS qgroups (recommended)" [translated > from German]. Since I've never used qgroups myself, I'll only comment on the parts where I can. However, I would say "(recommended)" just to get an estimate of space consumption is a rather hard label for the option in Timeshift. You can check the known issues on qgroups: https://btrfs.wiki.kernel.org/index.php/Quota_support#Known_issues This contains, amongst other things, the observed performance issues and also: "- After deleting a subvolume, you must manually delete the associated qgroup." which you observe, too. But it does indeed seem btrbk can help out here: https://github.com/digint/btrbk/issues/49 Manpages of btrfs-quota and btrfs-qgroup contain quite some warnings about the existence of these known issues, the status page at: https://btrfs.wiki.kernel.org/index.php/Status links them, etc. So I believe the recommendation by Timeshift is somewhat hefty. Other downstreams (see e.g. https://wiki.debian.org/Btrfs or https://wiki.archlinux.org/index.php/Btrfs#Quota ) explicitly recommend not to use qgroup unless really needed. Apparently this has also been raised to the developer: https://github.com/teejee2008/timeshift/issues/127 which has at least led to the addition of the checkmark to allow not enabling qgroup. > 2) I'm wondering if this couldn't be improved. Considering qgroups are > only used (in this case) for reporting on allocated space, not > limiting it, and btrfs free space reporting is notoriously lazy [not > meant in a bad way, can't think of a better word right now] anyway, > why does anything need to block at all? Even if I were using quotas, I > might prefer fuzzy quotas [that can be be hit too early/late because > accounting is catching up] to a temporary standstill, as an option. You can check e.g. the man page btrfs-quota(8) for a short discussion on why doing quota correctly with btrfs is not as easy as it may seem. I'll leave more comments (and how to disable them safely) to those who have experience with qgroups ;-). >> Another interesting test could be to adjust btrbk configuration to: >> btrfs_commit_delete = each > > Will do. ... > Hm. No freeze, this time (with btrbk set to commit after each delete). That might be a red herring if there was just less to delete, as Marc Joliet pointed out, at least, I think this means we identified the reason for the freezes you get. Cheers, Oliver
