Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp900344pxb; Fri, 28 Jan 2022 12:41:01 -0800 (PST) X-Google-Smtp-Source: ABdhPJzMhZ2WOxPkoWsdNZdpUiSsgeX0Wg/VbyuI+Ve1qohky132IX7N8pC7fk/4MsJmg9XjxKNu X-Received: by 2002:a05:6402:5188:: with SMTP id q8mr9834379edd.173.1643402461125; Fri, 28 Jan 2022 12:41:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643402461; cv=none; d=google.com; s=arc-20160816; b=ZGdugINEPYl+cTHAZsRpSLISj5BmNh1525rLmrKy95RBVVmvRV1YO66zZnVazJRda1 f5JufvygNsx0pU2yMbeD+SswCBgOan85CIiKmmIGNgEXK06wmqC1WObXkIbCzgNuac7f 6SOHMQ36346/2cjp5Lt7zho8XuUDqa7byUTdrLvmhLz6TAEMbvVCIKJUnrNg4iAPjIYB GAqfMKaarNgKZcQ1Qlv5TjrQy9FZY0Q3T5kmBE+pqDnDJS0wfoAjUlliBKR9rwLIPhJw d5Sy8eEJDBJxa7nT6BtiHuuChBmmrN2YXc1kY43oxz5JYF/qOBzyA4YNbPGwuU10eomP amLQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:message-id:date:references:in-reply-to:subject :cc:to:from:mime-version:content-transfer-encoding:dkim-signature :dkim-signature; bh=7jeK6qAfgdjs0c4Od3y+Dw74C4BYLxtyDSaeA4UomaQ=; b=dEbgLnCfqeSIs36I3ujNLPxvb2Eivz701aJBBBGcPc0lIZ4WpfNzqgocEeGDkjOE+m 3xOp/7Vcf/4xP8gebALKo/mrwM/wlTzb/RKFeZYTBcHpAW8J1KVqoBHIH56CRz3TmGh0 SNfJX5coXQQlsGdDOB4EbQ3Ci2LvdAY/WqZsOscyv2rPcBhC6P/oAs1+eVVafHwMTq+r lkQWMuZzANxofnrVEWmXflTUqlYRwbauEGW7LkDDJEUasI7/vIRN8SkIv2Nt4ZAwBEeA pX0AW0x73Vpii9uxFTiphYuUBxGrbPHxuTljzIYRt6UtI0PDgeEU1mQxSyPu6T0Z3JdW q4Qg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=fP0BRp3F; dkim=neutral (no key) header.i=@suse.de header.b=d67QifSu; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.de Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id 11si3524882eje.845.2022.01.28.12.40.37; Fri, 28 Jan 2022 12:41:01 -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=@suse.de header.s=susede2_rsa header.b=fP0BRp3F; dkim=neutral (no key) header.i=@suse.de header.b=d67QifSu; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237959AbiA0Wlc (ORCPT + 99 others); Thu, 27 Jan 2022 17:41:32 -0500 Received: from smtp-out2.suse.de ([195.135.220.29]:50364 "EHLO smtp-out2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231520AbiA0Wlb (ORCPT ); Thu, 27 Jan 2022 17:41:31 -0500 Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 992D91F391; Thu, 27 Jan 2022 22:41:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1643323289; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=7jeK6qAfgdjs0c4Od3y+Dw74C4BYLxtyDSaeA4UomaQ=; b=fP0BRp3F9o6JkMlBVvlIjhIF3+qvnlMnmj36Wt8ZzhTuonAkPZeRFi4G5rJZ06UbQuhyMr f17VAk92A4A7f7vf63mPaC4ITIxBeVURE12FEyhznpCl71d8ulT7RP6AaUrvWTU5aKpRFZ 5c50hBdkziB9zauxnjf5prYtmzYbnLw= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1643323289; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=7jeK6qAfgdjs0c4Od3y+Dw74C4BYLxtyDSaeA4UomaQ=; b=d67QifSuoGDJWOO8TbtDTy+Gt5gu8yfgXwQ6PaEyBYUZZ+K/DJesollW/6Em3ElUuGBG1P mWE2kFfODUnXq0BA== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id C68E113CFF; Thu, 27 Jan 2022 22:41:28 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id y8YBIZgf82GyGAAAMHmgww (envelope-from ); Thu, 27 Jan 2022 22:41:28 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 From: "NeilBrown" To: "Chuck Lever III" Cc: "Linux NFS Mailing List" Subject: Re: [RFC PATCH 0/4] nfsd: allow NFSv4 state to be revoked. In-reply-to: <7B388FE8-1109-4EDD-B716-661870B446C7@oracle.com> References: <164325908579.23133.4781039121536248752.stgit@noble.brown>, <7B388FE8-1109-4EDD-B716-661870B446C7@oracle.com> Date: Fri, 28 Jan 2022 09:41:24 +1100 Message-id: <164332328424.5493.16812905543405189867@noble.neil.brown.name> Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On Fri, 28 Jan 2022, Chuck Lever III wrote: > Hi Neil- >=20 > > On Jan 26, 2022, at 11:58 PM, NeilBrown wrote: > >=20 > > 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 t= he > > NFS server completely, or blocking all access from that client > > (unexporting all filesystems) and waiting for the lease timeout. > >=20 > > 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. > >=20 > > 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. > >=20 > > I've cursed mainly on NFSv4.1 and later for this. I haven't tested > > yet with NFSv4.0 which has different mechanisms for state management. > >=20 > > 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. >=20 > I've browsed this series and need to think about: > - whether we want to enable administrative state revocation and > - whether NFSv4.0 can support that reasonably >=20 > In particular, are there security consequences for revoking > state? What would applications see, and would that depend on > which minor version is in use? Are there data corruption risks > if this facility were to be misused? The expectation is that this would only be used after unexporting the filesystem. In that case, the client wouldn't notice any difference from the act of writing to unlock_filesystem, as the entire filesystem would already be inaccessible. If we did unlock_filesystem a filesystem that was still exported, the client would see similar behaviour to a network partition that was of longer duration than the lease time. Locks would be lost. >=20 > Also, Dai's courteous server work is something that potentially > conflicts with some of this, and I'd like to see that go in > first. I'm perfectly happy to wait for the courteous server work to land before pursuing this. >=20 > Do you have specific user requests for this feature, and if so, > what are the particular usage scenarios? It's complicated.... The customer has an HA config with multiple filesystem resource which they want to be able to migrate independently. I don't think we really support that, but they seem to want to see if they can make it work (and it should be noted that I talk to an L2 support technician who talks to the customer representative, so I might be getting the full story). Customer reported that even after unexporting a filesystem, they cannot then unmount it. Whether or not we think that independent filesystem resources is supportable, I do think that the customer should have a clear path for unmounting a filesystem without interfering with service provided from other filesystems. Stopping nfsd would interfere with that service by forcing a grace-period on all filesystems. The RFC explicitly supports admin-revocation of state, and that would address this specific need, so it seemed completely appropriate to provide it. As an aside ... I'd like to be able to suggest that the customer use network namespaces for the different filesystem resources. Each could be in its own namespace and managed independently. However I don't think we have good admin infrastructure for that do we? I'd like to be able to say "set up these 2 or 3 config files and run=20 systemctl start nfs-server@foo and the 'foo' network namespace will be created, configured, and have an nfs server running". Do we have anything approaching that? Even a HOWTO ?? Thanks, NeilBrown