Am Donnerstag, 21. November 2019, 22:34:41 CET schrieb Christian Pernegger: > > > 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). > > In other news, > - I seem to be leaking cgroups. There are currently 191 subvolumes > (most of which are ro snapshots), but 547 "0/*" qgroups. Should > deleting a subvolume take care of removing its (auto-created) cgroup, > or does that always have to be done manually (or by setting the > experimental *_qgroup_destroy options in btrbk.conf)? Any elegant ways > to remove orphaned cqroups? > - Timeshift, at :00, triggers this as well, it's just less severe > (maybe because that's 1 subvolume instead of 3). > > Cheers, > C. As Qu said, the freezes should only happen on snapshot deletion. Depending on how you have btrbk configured and how regularly it runs, not every btrbk run will delete snapshots. Therefor not every run will cause the system to lock up. On a side note, I am also really annoyed by the lockups caused by qgroups. On my Gentoo systems (which use btrbk) I have it disabled for that reason, but I left it on on my openSUSE laptop (a Dell XPS 13 9360), which locks up for about 15-30 minutes while cleaning up snapshots a few times a week (usually after reboots or after "zypper dup"). Of course, that's with snapshots active for /home, which I do so that the file system doesn't change out from under borg while it's running. I'm tentatively considering turning it off there, too, but I'll experiment with the snapper configuration first. Greetings -- Marc Joliet -- "People who think they know everything really annoy those of us who know we don't" - Bjarne Stroustrup
Attachment:
signature.asc
Description: This is a digitally signed message part.
