From owner-freebsd-current@FreeBSD.ORG Tue Jun 30 20:01:18 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0586C1065674; Tue, 30 Jun 2009 20:01:18 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 7FED88FC1D; Tue, 30 Jun 2009 20:01:17 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANsLSkqDaFvH/2dsb2JhbADRaoJBgU4FgTg X-IronPort-AV: E=Sophos;i="4.42,318,1243828800"; d="scan'208";a="37919896" Received: from danube.cs.uoguelph.ca ([131.104.91.199]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 30 Jun 2009 16:01:16 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by danube.cs.uoguelph.ca (Postfix) with ESMTP id 1A2C5108463B; Tue, 30 Jun 2009 16:01:16 -0400 (EDT) X-Virus-Scanned: amavisd-new at danube.cs.uoguelph.ca Received: from danube.cs.uoguelph.ca ([127.0.0.1]) by localhost (danube.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0qQ09x6AgPl5; Tue, 30 Jun 2009 16:01:15 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by danube.cs.uoguelph.ca (Postfix) with ESMTP id 09DB5108462A; Tue, 30 Jun 2009 16:01:15 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n5UK3Y916395; Tue, 30 Jun 2009 16:03:34 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Tue, 30 Jun 2009 16:03:34 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Kostik Belousov In-Reply-To: <20090630193248.GY2884@deviant.kiev.zoral.com.ua> Message-ID: References: <3bbf2fe10906290256x4bfbe263jccef017a557f9410@mail.gmail.com> <20090630193248.GY2884@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Attilio Rao , freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: umount -f implementation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 20:01:18 -0000 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