OK, I will install kdump later and perform a dump after the hang.
One more noob question beforehand: does this dump contain sensitive
information, for example the luks encryption key for the disk etc? A Google
search only brings up one relevant search result which can only be viewed
with a redhat subscription...
Best regards,
Jürgen
Am 13. September 2018 14:02:11 schrieb Nikolay Borisov <nbori...@suse.com>:
On 13.09.2018 14:50, Jürgen Herrmann wrote:
I was echoing "w" to /proc/sysrq_trigger every 0.5s which did work also
after the hang because I started the loop before the hang. The dmesg
output should show the hanging tasks from second 346 on or so. Still not
useful?
So from 346 it's evident that transaction commit is waiting for
commit_root_sem to be acquired. So something else is holding it and not
giving the transaction chance to finish committing. Now the only place
where send acquires this lock is in find_extent_clone around the call
to extent_from_logical. The latter basically does an extent tree search
and doesn't loop so can't possibly deadlock. Furthermore I don't see any
userspace processes being hung in kernel space.
Additionally looking at the userspace processes they indicate that
find_extent_clone has finished and are blocked in send_write_or_clone
which does the write. But I guess this actually happens before the hang.
So at this point without looking at the stacktrace of the btrfs send
process after the hung has occurred I don't think much can be done
Mit AquaMail Android
https://www.mobisystems.com/aqua-mail
