You are not logged in.
I am using btrfs on LVM on LUKS on a ThinkPad T450 with an Intel i5-5300U processor.
I am facing the issue that while snapper runs its daily cleanup routine, all applications that need some sort of disk IO will hang for the duration of the cleanup. For example, the zsh autosuggestions, firefox, rofi etc. will hang for 30s to one minute.
I have snapper configured to create timeline based snapshots for the root subvolume (@) and the @home subvolume. I am also using snap-pac to create pre/post snapshots for pacman on the @ subvolume. I limited the amount of snapshots on @ to 25. On @ and @home I have also 5 hourly, 7 daily snapshots and 2 weekly snapshots set to be kept.
I am not using cron but the systemd timers provided by snapper and snap-pac.
If it makes a difference I can of course upload the snapper configurations.
Quotas are disabled as far as I am aware. I also put /var/log and /var/cache/pacman on different subvolumes.
Is this issue limited to my setup? Is there something I can change to fix the hangs or have the cleanup run so that I won't notice it as much (higer nice value/ running cleanup when I am not using it)?
Offline
How many snapshots? `btrfs sub list -ts / | wc -l` should approximate it.
Are quotas enabled? `btrfs qg show /`
If quotas are not enabled and snapshots are fewer than 200, then I suggest remote ssh with 'sysrq+t' ready to go (so that you just have to hit return), reproduce the problem and then hit return to issue the sysrq+t. During hangs, it can take the entire length of the hang to type in each character for the sysrq, so it's best to have it ready to go.
The sysrq output to dmesg is usually too big for the buffer, but it should all be in the journal. Use 'journalctl -k -o short-monotonic > kmesg.txt' and either put that up in a file sharing location (nextcloud, gdrive, dropbox), and post to the linux-btrfs@ development list.
If you have quotas enabled, disable them, and see if the problem goes away.
Offline
`btrfs sub list -ts / | wc -l` returns 56 and quotas are indeed disabled.
Since I created my post, I haven't really noticed the issue as much anymore. It seems to me that putting the logs on a different subvolume might have made the cleanup runs much faster.
If I notice the hangs again, I will check out your suggestion regarding checking out the logs from ssh.
Thanks, for your suggestions!
Offline