Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp758539pxb; Fri, 28 Jan 2022 09:19:53 -0800 (PST) X-Google-Smtp-Source: ABdhPJxmQIvEQSxuzYlwgv4718gkwkKLoZqqnkD6GeuTxR46hbpSo0NNi7gI2eKj7i3Gj4nDOtKq X-Received: by 2002:a17:902:e0c9:: with SMTP id e9mr9775218pla.56.1643390393626; Fri, 28 Jan 2022 09:19:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643390393; cv=none; d=google.com; s=arc-20160816; b=PoFg096Q/qT266FNsEAdAmlKulbLWpxCs4VXmqWipz+NZKQvqKmfi1j0PoEGvw9Hwl bemHxIlkGw0if97SkAk6e1fH0Q2fQxXpIleYpno7q6aOAy68Z5a4e+nQLBF6J4BIBOBU ualioLr+r9jL0Do7hgVuj7Vda2TaFbZrcuWEyg/W6Lm8O5uMUtOgnrojIKidwSHDEySp mxM4opIgmOpS0f9rgFqz48W7ApDJ5thSO1fxiHA+xO9CwZjm63k8orqAIZIRThTERhUx kDA2kaBaWncY9XqaZiJQZkl9cd9EVuVf0c5hsHhVgfLolYC61NM9iUw8LZCLabXlSeFq Fb9w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:from:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:date :dkim-signature:dkim-filter; bh=9959/BUjXBc0N1kAx1oAXJkrpAQZJaAofqwFZinX6B8=; b=TCkJuybM7fmw1kaeb8JPxQhLiVadi+1/4ba8ewcdwp/0Ej1IVJcoKh1vS2ew6M9Lm8 94drIiWvI52Q5j7ZgUe5rQRUtz9VohB4Vpnn5mtVT+KM+zWo7Rcy9WUrMsTCsJX189mb LKPQ3tXSrvJFrxljXgVR4GrL4kvMOItKSAMxwpuWcHc1sM5H3aaKohx/IAHz76SbVDfh rO0jzZPQVlZzBiJ1UzL245JxAet2+VxWXCzYEr34QcUA1A1OihI7Cd6SjqGVJs+7KwyE pGaIkdkpNLtfuCG2z/gntmbHfPeRovuEhUHqKIYlHnaEVbaPA9aPShlS50gro9tYlbv8 nTLQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@fieldses.org header.s=default header.b=CQD8GoTU; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h20si1419528pju.188.2022.01.28.09.19.40; Fri, 28 Jan 2022 09:19:53 -0800 (PST) Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@fieldses.org header.s=default header.b=CQD8GoTU; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230056AbiA0UGj (ORCPT + 99 others); Thu, 27 Jan 2022 15:06:39 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44492 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231156AbiA0UGj (ORCPT ); Thu, 27 Jan 2022 15:06:39 -0500 Received: from fieldses.org (fieldses.org [IPv6:2600:3c00:e000:2f7::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 72D0DC061714 for ; Thu, 27 Jan 2022 12:06:39 -0800 (PST) Received: by fieldses.org (Postfix, from userid 2815) id D9C69608A; Thu, 27 Jan 2022 15:06:38 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 fieldses.org D9C69608A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fieldses.org; s=default; t=1643313998; bh=9959/BUjXBc0N1kAx1oAXJkrpAQZJaAofqwFZinX6B8=; h=Date:To:Cc:Subject:References:In-Reply-To:From:From; b=CQD8GoTUZ3wmFGqrwCjvfq0Brjy4gCSjMqo8phoz6J852H5MxoYMrtQrlIqqOhMb9 X9x8Hb0hzUU4+GrEbVq5dfv0lZIZ4/FiQzTGP0iSTWxzAOK8UXOlFbT0g+kf1LbtrG o2ZndjiKrRMg72rJLO30ZQVTGR4PdzOTTNTgjXGY= Date: Thu, 27 Jan 2022 15:06:38 -0500 To: NeilBrown Cc: Chuck Lever , linux-nfs@vger.kernel.org Subject: Re: [RFC PATCH 0/4] nfsd: allow NFSv4 state to be revoked. Message-ID: <20220127200638.GB3459@fieldses.org> References: <164325908579.23133.4781039121536248752.stgit@noble.brown> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <164325908579.23133.4781039121536248752.stgit@noble.brown> User-Agent: Mutt/1.5.21 (2010-09-15) From: bfields@fieldses.org (J. Bruce Fields) Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On Thu, Jan 27, 2022 at 03:58:10PM +1100, NeilBrown wrote: > If a filesystem is exported to a client with NFSv4 and that client holds > a file open, the filesystem cannot be unmounted without either stopping the > NFS server completely, or blocking all access from that client > (unexporting all filesystems) and waiting for the lease timeout. > > For NFSv3 - and particularly NLM - it is possible to revoke all state by > writing the path to the filesystem into /proc/fs/nfsd/unlock_filesystem. > > This series extends this functionality to NFSv4. With this, to unmount > an exported filesystem is it sufficient to disable export of that > filesystem, and then write the path to unlock_filesystem. It's always been weird that /proc/fs/nfsd/unlock_filesystem was v3-only, so thanks for looking into extending it to v4. You can accomplish the same by stopping the server, unexporting, then restarting, but then applications may see grace-period-length delays. So in a way this is just an optimization for what's probably a rare operation. Probably worth it, but I'd still be curious if there's any specific motivating cases you can share. I guess the procedure would be to unexport and then write to /proc/fs/nfsd/unlock_filesystem? An option to exportfs to do both might be handy. > I've cursed mainly on NFSv4.1 It does inspire strong feelings sometimes. --b. > and later for this. I haven't tested > yet with NFSv4.0 which has different mechanisms for state management. > > If this series is seen as a general acceptable approach, I'll look into > the NFSv4.0 aspects properly and make sure it works there. > > Thanks, > NeilBrown > > > --- > > NeilBrown (4): > nfsd: prepare for supporting admin-revocation of state > nfsd: allow open state ids to be revoked and then freed > nfsd: allow lock state ids to be revoked and then freed > nfsd: allow delegation state ids to be revoked and then freed > > > fs/nfsd/nfs4state.c | 105 ++++++++++++++++++++++++++++++++++++++++---- > 1 file changed, 96 insertions(+), 9 deletions(-) > > -- > Signature