From owner-freebsd-fs@freebsd.org Tue Sep 5 09:38:29 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A6535E22D44 for ; Tue, 5 Sep 2017 09:38:29 +0000 (UTC) (envelope-from Nikolaus@rath.org) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 77D0567A39 for ; Tue, 5 Sep 2017 09:38:28 +0000 (UTC) (envelope-from Nikolaus@rath.org) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 5C58E20A80 for ; Tue, 5 Sep 2017 05:38:22 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Tue, 05 Sep 2017 05:38:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=YGIyLkd60lZgI3/Ottz41vomlnBvRiEB+kNkGEjm+Y0=; b=C3USkgcj ZC4YGrz2G6og6STJEHRnHP7u6iYKKT1O/7JGf66wXTKBxiHtfKvQMRHDKrrKlQro SBgvfzS8WaeGoV2ZQsmOK0W1QOwGeis2zcjPDFGpgEBL+I+dWjQPs3Nb40saZMNc WqPlPNne8WAt0WMs4oNGToHxyquJxBbu4n1DMrXovr9xxlbAajCQ/i0xKRhi3V/d cgKeeKRwB3VZIHlI2hKCFAF53qGz7PFHBEzRZv4K6kdrcSSOpCbLAZqqK2s+qE+T FTz8RtStD6w8JHHIyE8NWFA/W++6KvDc988TYiwL8yR5HR8MrBlBroX9IbH4RuIH AkcWI0KSnvh2sA== X-ME-Sender: X-Sasl-enc: I09yrkcvKO3YMZs1Lo/nYJrEd4gCzPS9tKYryPkemk2A 1504604302 Received: from ebox.rath.org (ebox.rath.org [45.79.69.51]) by mail.messagingengine.com (Postfix) with ESMTPA id 1ADE02418B for ; Tue, 5 Sep 2017 05:38:22 -0400 (EDT) Received: from thinkpad.rath.org (thinkpad [192.168.12.2]) by ebox.rath.org (Postfix) with ESMTPS id DCECC11C for ; Tue, 5 Sep 2017 09:38:20 +0000 (UTC) Received: by thinkpad.rath.org (Postfix, from userid 1000) id 6EA8BBFCB5; Tue, 5 Sep 2017 11:38:19 +0200 (CEST) From: Nikolaus Rath To: freebsd-fs@freebsd.org Subject: Re: umount() taking minutes for FUSE filesystems References: <87bmn44ruu.fsf@vostro.rath.org> <87o9qyrbs8.fsf@vostro.rath.org> <2FAD66DE-031B-4B36-9E85-C7BC6B52B5E6@gmail.com> <29de6425-9f92-3bd8-f446-1c9dded33b15@freebsd.org> Mail-Copies-To: never Mail-Followup-To: freebsd-fs@freebsd.org Date: Tue, 05 Sep 2017 11:38:18 +0200 In-Reply-To: <29de6425-9f92-3bd8-f446-1c9dded33b15@freebsd.org> (Stefan Esser's message of "Tue, 5 Sep 2017 10:42:07 +0200") Message-ID: <87k21dzdrp.fsf@thinkpad.rath.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 09:38:29 -0000 On Sep 05 2017, Stefan Esser 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