http://bugzilla.suse.com/show_bug.cgi?id=1049574 http://bugzilla.suse.com/show_bug.cgi?id=1049574#c20 --- Comment #20 from Nikolay Borisov <nborisov@suse.com> --- (In reply to Oliver Kurz from comment #19)
Created attachment 791669 [details] snapper log, blocked tasks, backtrace of all snapper and snapperd threads
I managed to observe what looks like exactly the same problem on a SLES12SP3 host which got upgraded from SLE12SP1->SLE12SP2->SLE12SP3.
Please find attached the logs from snapper, the backtrace of both snapper and snapperd threads as well as the output from "sysrq w", all blocked tasks. The output from /proc/$(pidof snapperd)/stack:
[<ffffffff81222a45>] poll_schedule_timeout+0x45/0x60 [<ffffffff81223eac>] do_sys_poll+0x38c/0x4f0 [<ffffffff812240cd>] SyS_poll+0x5d/0xe0 [<ffffffff8161de61>] entry_SYSCALL_64_fastpath+0x20/0xe9 [<ffffffffffffffff>] 0xffffffffffffffff
Both snapper and snapperd seem to be running since Dec 01 on that host, that is since the last reboot.
I don't see anything related to btrfs in those logs. The blocked_tasks log is essentially empty, it just shows the scheduler's statistics and no kernel-level blocked tasks. The stacktrace you've shown here means that snapperd's main thread is waiting to be woken up and this is confirmed from the bt log of the main thread: Thread 1 (Thread 0x7fe23ec43880 (LWP 4330)): #0 0x00007fe23d8a630d in poll () from /lib64/libc.so.6 The snapperd process is comparing dirs according to the log in tmp/snapperd_bt_all.log and has submitted some ioctl to btrfs from the context of thread 18169. If the machine is still in this state could you provide the output of : /proc/18169/stack ? -- You are receiving this mail because: You are on the CC list for the bug.