Date: Tue, 5 Sep 2017 10:42:07 +0200 From: Stefan Esser <se@freebsd.org> To: Ben RUBSON <ben.rubson@gmail.com>, Freebsd fs <freebsd-fs@freebsd.org> Subject: Re: umount() taking minutes for FUSE filesystems Message-ID: <29de6425-9f92-3bd8-f446-1c9dded33b15@freebsd.org> In-Reply-To: <2FAD66DE-031B-4B36-9E85-C7BC6B52B5E6@gmail.com> References: <87bmn44ruu.fsf@vostro.rath.org> <87o9qyrbs8.fsf@vostro.rath.org> <CAG6CVpWX1TPtR65dXkC4A_-hiSrh0L524mcPtcQM=K28RM7vWw@mail.gmail.com> <2FAD66DE-031B-4B36-9E85-C7BC6B52B5E6@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Regards, STefan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?29de6425-9f92-3bd8-f446-1c9dded33b15>