Date: Tue, 5 Sep 2017 19:11:48 +0100 From: Martin Simmons <martin@lispworks.com> To: freebsd-fs@freebsd.org Subject: Re: umount() taking minutes for FUSE filesystems Message-ID: <201709051811.v85IBmbO005440@higson.cam.lispworks.com> In-Reply-To: <87k21dzdrp.fsf@thinkpad.rath.org> (message from Nikolaus Rath on Tue, 05 Sep 2017 11:38:18 %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> <87k21dzdrp.fsf@thinkpad.rath.org>
next in thread | previous in thread | raw e-mail | index | archive | help
>>>>> On Tue, 05 Sep 2017 11:38:18 +0200, Nikolaus Rath said: > > 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. > >> > >> # procstat -kk $! > >> COMM TDNAME KSTACK > >> 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 > >> > >> # 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. What does "informs the FUSE kernel module about that" do to inform it? __Martin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201709051811.v85IBmbO005440>