Date: Tue, 30 Jun 2009 16:03:34 -0400 (EDT) From: Rick Macklem <rmacklem@uoguelph.ca> To: Kostik Belousov <kostikbel@gmail.com> Cc: Attilio Rao <attilio@freebsd.org>, freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: umount -f implementation Message-ID: <Pine.GSO.4.63.0906301551020.14147@muncher.cs.uoguelph.ca> In-Reply-To: <20090630193248.GY2884@deviant.kiev.zoral.com.ua> References: <Pine.GSO.4.63.0906281955160.5084@muncher.cs.uoguelph.ca> <3bbf2fe10906290256x4bfbe263jccef017a557f9410@mail.gmail.com> <Pine.GSO.4.63.0906301150370.10386@muncher.cs.uoguelph.ca> <20090630193248.GY2884@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 30 Jun 2009, Kostik Belousov wrote: >> >> I think I can fix this in the experimental nfsv4 client, since it has >> a kernel thread that can check for MNTK_UNMOUNTF being set and then >> kill off the RPCs in progress, but that won't help the regular client. > This solution sounds good, but see below. > > It may be argued by some people, me included, that umount -f shall not > override any ownership of kernel resources. In particular, you must > not ignore the lockref. Instead, the threads that own misc filesystem > resources, like mount reference counter, locked vnodes etc shall be > weed out of the syscalls. E.g., finishing stalled rpc calls with some > error code that is propagated to return code from vops is good solution. > I think that the thread "fix" above would work this way. Right now, nfs_umount() terminates RPCs in progress for the "-f" case and they return RPC_CANTRECV, which just becomes EACCES at the moment. The problem is that, often, the "umount -f" thread never gets as far as nfs_umount(). All I was thinking of doing, above, is having the kernel thread check for MNTK_UNMOUNTF and then do the same thing. (ie. The NFS VOPs would end up returning EACCES, or whatever Exxx might be preferred.) > Another problem with forced unmounts is that VFS does not block new > threads from arriving into VOPs. When finishing the inflight rpcs, > you may either leave some new rpcs behind or loop infinitely chasing > rpcs that arrive while you finishing old rpcs. > The NFS clients already handle this by returning ESTALE at the beginning of nfs_request() without attempting the RPC, if MNTK_UNMOUNTF is set. (Why ESTALE?? Who knows, although I suspect that just about any Exxx will get the job done?) > Umount -f is needed in two different situations, one is normally worked > filesystem that shall be unmounted by administrative request, detaching > any resources opened by application. Second is the last-resort action > when backing storage (server in NFS case, disk for UFS) is misbehaving. > I think we must not break first case for the second. > I think this is what Bruce Evans was referring to. He suggested that there be two flags, like -f and -F, if I understood his post. rick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.63.0906301551020.14147>