From owner-freebsd-fs@freebsd.org Fri Sep 8 14:22:24 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 9A5D8E1AA2C for ; Fri, 8 Sep 2017 14:22:24 +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 690D181270 for ; Fri, 8 Sep 2017 14:22:23 +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 94AD821006 for ; Fri, 8 Sep 2017 10:22:22 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Fri, 08 Sep 2017 10:22: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=5OSY6kzqL0Zkm7MSNCvXHonGIjkCdZZ5/NvfdTQczn4=; b=Tkn+SY5Q pCtA8IQ1tdVJePdFONwwacSj9kBoG2Scx6XqdP16Gfto/ltJsy2udaqo7iZ89Qhx 6LWbpGfz+dvP5ctlFY/iD1SfuM26CDYUlaNWvEdOc+dlY7Hfg+VUFaQebFgM7B7y bc+lL/WNN48CccUAfzkbzEHcmEUZPHygIOuHY0v2CEEBJRQk3JBaSxcAIV4UB/4I Z9RjuBrub2X5o7xLJ4L3YcJ/xI2br/pzUwGOBCKADCzLJ85qMhZrD+BFrkawv1yU xC8pSyrD5MoZUJxzrAmBumjh79xugToX8Ar1odqpUuwb6aJvm6CjYnwJuxP7E8Ie v32wiSgrVorofw== X-ME-Sender: X-Sasl-enc: Pwr0zfPR2djfkEcKhKGTK/QnHD7It47nsUdJe/ng62c9 1504880542 Received: from ebox.rath.org (ebox.rath.org [45.79.69.51]) by mail.messagingengine.com (Postfix) with ESMTPA id 50D7C2494C for ; Fri, 8 Sep 2017 10:22:22 -0400 (EDT) Received: from vostro.rath.org (vostro [192.168.12.4]) by ebox.rath.org (Postfix) with ESMTPS id 6B273195 for ; Fri, 8 Sep 2017 14:22:21 +0000 (UTC) Received: by vostro.rath.org (Postfix, from userid 1000) id 19C62102B9C; Fri, 8 Sep 2017 16:22:20 +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> <87k21dzdrp.fsf@thinkpad.rath.org> <201709051811.v85IBmbO005440@higson.cam.lispworks.com> <87ingugw2v.fsf@thinkpad.rath.org> <201709081143.v88BhEOn001626@higson.cam.lispworks.com> Mail-Copies-To: never Mail-Followup-To: freebsd-fs@freebsd.org Date: Fri, 08 Sep 2017 15:22:19 +0100 In-Reply-To: <201709081143.v88BhEOn001626@higson.cam.lispworks.com> (Martin Simmons's message of "Fri, 8 Sep 2017 12:43:14 +0100") Message-ID: <87lglp6zj8.fsf@vostro.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: Fri, 08 Sep 2017 14:22:24 -0000 On Sep 08 2017, Martin Simmons wrote: >>>>>> On Thu, 07 Sep 2017 21:14:32 +0200, Nikolaus Rath said: >>=20 >> On Sep 05 2017, Martin Simmons wrote: >> >> 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? >>=20 >> It calls unmount. >> https://github.com/libfuse/libfuse/blob/master/lib/mount_bsd.c#L127 > > It seems to me that the following occurs: > > 1. The user program exits the main loop. > 2. The user program sends unmount to the kernel. > 3. The kernel sends FUSE_DESTROY to the user program. > 4. The kernel waits for the user program to respond to FUSE_DESTROY. > 5. The user program does not respond because it has exited the main loop. > 6. The kernel wait times out after 60 seconds. > > Perhaps the solution is to close the fd before calling unmount(), like the > Linux code in https://github.com/libfuse/libfuse/blob/master/lib/mount.c#= L275 > does? That sounds reasonable, will give it a shot. > That will prevent the kernel from sending FUSE_DESTROY, but what is the > purpose of FUSE_DESTROY if the user program can't respond to it? In most cases, umount() is not called by the filesystem but by the user. In that case, the FUSE_DESTROY request gives the filesystem a chance to clean-up and exit the main loop. That said, the filesystem could also detect the unmount by the kernel closing the fd. So I'm not sure what is gained by the extra request either... Theoretically, at least under Linux the destroy handler could perform some notify_* operations, but I don't see how that would be useful when the filesystem will be unmounted anyway. 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