Re: Mount/df/PAM login hangs during rsync to btrfs subvolume, or maybe doing btrfs subvolume snapshot

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

On 2019/9/12 下午2:28, Nikolay Borisov wrote:
>
>
> On 12.09.19 г. 9:11 ч., Nikolay Borisov wrote:
>>
>>
>> On 12.09.19 г. 7:38 ч., David Newall wrote:
>>> On 11/9/19 8:22 pm, Nikolay Borisov wrote:
>>>>> I saved it tohttps://davidnewall.com/kern.1
>>>> Nothing useful in that log, everything seems normal.
>>>
>>> Thank you, again, for your help.  I am grateful.
>>>
>>> If I understand the output, both df and mount are waiting for
>>> show_mountinfo which is waiting for btrfs_show_devname which is waiting
>>> to get a lock.  They have to wait to find the devname for ten minutes. 
>>> Is that really normal?
>>
>> It's normal for them to wait for the lock, it's not normal for the lock
>> to be taken for 10 minutes.
>>
>>>
>>> I'm not saying that btrfs is behind it, but it does seem like something
>>> is not right.
>>
>> From my POV what's wrong is the fact that btrfs transaction commit is
>> taking a long time. Is it possible that the underlying storage is
>> exhibiting problems e.g. a dying disk/ssd?
>
> Actually when the issue occurs again can you sample the output of echo w
>> /proc/sysrq-trigger. Because right now you have provided 3 samples in
> the course of I don't know how many minutes. So they just give a
> momentarily glimpse into what's happening. E.g. just because we saw
> btrfs transaction/btrfs_show_devname doesn't necessarily mean that's
> what's happening (Though having the same consistent state in the 3 logs
> kind of suggests otherwise).

I see all dumps are waiting for write_all_supers.

Would you please provide the code context of write_all_supers.isra.43+0x977?

I guess it's wait_dev_flush(), which is just really waiting for disk writes.

Would you please check how fast (or how slow in this particular case)
the related disks are?
To me, it really looks like just too slow devices.

Thanks,
Qu

>
>>
>>>
>>> I notice that there's a waiting btrfs-transation, too.  I don't know
>>> what the transaction would be, and no doubt it's completely appropriate,
>>> even though the use of btrfs at that point is merely one mount (and one
>>> mount of ext2 over a sub-directory, probably no involvement by btrfs.)
>>>
>>> I see, too, that systemd is waiting for btrfs_show_devname.  It's a
>>> pattern.
>>>
>>> I take your point about the kernel being somewhat old and accept that
>>> I'm unlikely to get far without confirming the problem on a recent kernel.
>>>
>>>
>>