Date: Fri, 8 Sep 2017 18:28:33 +0100 From: Martin Simmons <martin@lispworks.com> To: freebsd-fs@freebsd.org Subject: Re: umount() taking minutes for FUSE filesystems Message-ID: <201709081728.v88HSXP7010329@higson.cam.lispworks.com> In-Reply-To: <87lglp6zj8.fsf@vostro.rath.org> (message from Nikolaus Rath on Fri, 08 Sep 2017 15:22:19 %2B0100) 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> <201709051811.v85IBmbO005440@higson.cam.lispworks.com> <87ingugw2v.fsf@thinkpad.rath.org> <201709081143.v88BhEOn001626@higson.cam.lispworks.com> <87lglp6zj8.fsf@vostro.rath.org>
next in thread | previous in thread | raw e-mail | index | archive | help
>>>>> On Fri, 08 Sep 2017 15:22:19 +0100, Nikolaus Rath said: > > On Sep 08 2017, Martin Simmons <martin@lispworks.com> wrote: > > > 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. OK, that makes sense. > 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. I don't think the kernel itself ever closes the fd (except implicitly in the case where the filesystem program dies unexpected). __Martin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201709081728.v88HSXP7010329>