> Am 21.11.19 um 17:44 schrieb Christian Pernegger: > > maybe to quotas. It's possible that Timeshift enables them, how can I check? > > You can test with: > $ btrfs qgroup show / Definitely enabled, then. ... ... ... There it is: Timeshift has a pre-selected checkbox "enable BTRFS qgroups (recommended)" [translated from German]. 1) How can I safely disable qgroups? Is it enough to uncheck the Timeshift option and then run btrfs quota disable or do I have to manually remove the qgroups somehow? 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. > This is an interesting observation. I believe this means it is happening when the snapshot deletes are actually going to the storage, > which usually happens only _after_ btrbk is finished (in case you catch it with top, a kernel thread "btrfs-cleaner" should be doing this job). Ok, so btrbk runs, finishes, soon (but not immediately) after that btrfs-cleaner indeed tops the CPU charts, pegging one core to 100 %. The system is still responsive at this point. A couple of seconds into the btrfs-cleaner run, the system becomes unresponsive (top still updates throughout, though). btrfs-cleaner drops off, and btrfs-transacti[obv. cut off] takes it's place, taking 100 % CPU. Still unresponsive. As soon as btrfs-transacti is done, the system immediately recovers. Then btrfs cleaner returns, briefly, with no impact on performance. (Keep in mind that top only updates every couple seconds, it's possible btrfs-cleaner is blameless and btrfs-transacti the culprit.) > Another interesting test could be to adjust btrbk configuration to: > btrfs_commit_delete = each Will do. Cheers, C.
