Date: Tue, 05 Sep 2017 11:38:18 +0200 From: Nikolaus Rath <Nikolaus@rath.org> To: freebsd-fs@freebsd.org Subject: Re: umount() taking minutes for FUSE filesystems Message-ID: <87k21dzdrp.fsf@thinkpad.rath.org> In-Reply-To: <29de6425-9f92-3bd8-f446-1c9dded33b15@freebsd.org> (Stefan Esser's message of "Tue, 5 Sep 2017 10:42:07 %2B0200") References: <87bmn44ruu.fsf@vostro.rath.org> <87o9qyrbs8.fsf@vostro.rath.org> <CAG6CVpWX1TPtR65dXkC4A_-hiSrh0L524mcPtcQM=K28RM7vWw@mail.gmail.com> <2FAD66DE-031B-4B36-9E85-C7BC6B52B5E6@gmail.com> <29de6425-9f92-3bd8-f446-1c9dded33b15@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sep 05 2017, Stefan Esser <se@freebsd.org> wrote:
> Am 04.09.17 um 23:14 schrieb Ben RUBSON:
>> I managed to reproduce the issue.
>> unmount takes exactly 60 seconds, as if a timeout was running.
>>=20
>> # procstat -kk $!
>> COMM TDNAME KSTACK=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20
>> printcap - mi_switch+0xd2 sleepq_catch_signals+0xb7
>> sleepq_timedwait_sig+0x10 _sleep+0x26f fdisp_wait_answ+0x171
>> fuse_vfsop_unmount+0xf5 dounmount+0x9b6 sys_unmount+0x41b
>> amd64_syscall+0x4ce Xfast_syscall+0xfb
>>=20
>> # uname -sr
>> FreeBSD 11.0-RELEASE-p9
>
> I have given the exact position of this 60 second msleep() in multiple
> mails before. It is in fuse_ipc.c, the particular msleep with "fu_ans"
> (line 333 in -CURRENT).
>
> I did not try to diagnose, why this particular umount() takes so long,
> while others are fast, but it is obvious that the kernel module does
> wait for a signal at the end of some IPC and the signal is either lost
> or never sent. There is a check for a dead connection, just before the
> msleep() and the connection is considered alive at that point (and
> should be, to support the umount() result being reported).
>
> I did not have time to look into this during the previous week and
> won't during this week, but it should not be too hard to see, what's
> going on. A starting point could be to compare this test with those
> that perform the unmount without delay.
Probably the crucial difference is that the test that takes long exits
its main loop on its own and then informs the FUSE kernel module about
that, while the other tests terminate the main loop because the kernel
module tells them to do so.
Best,
Nikolaus
--=20
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
=C2=BBTime flies like an arrow, fruit flies like a Banana.=C2=
=AB
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?87k21dzdrp.fsf>