From: Jeff Layton <jlayton@kernel.org>
To: Benjamin Coddington <bcodding@redhat.com>,
Chuck Lever <chuck.lever@oracle.com>
Cc: NeilBrown <neilb@suse.de>, Dai Ngo <dai.ngo@oracle.com>,
Olga Kornievskaia <okorniev@redhat.com>,
Tom Talpey <tom@talpey.com>,
Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: NFSD automatically releases all states when underlying file system is unmounted
Date: Fri, 21 Mar 2025 10:43:51 -0400 [thread overview]
Message-ID: <4afafdfd5f7148cf8c9e0c9a65946726f29719e5.camel@kernel.org> (raw)
In-Reply-To: <0895A981-76C0-41A0-B474-62659480B31F@redhat.com>
On Fri, 2025-03-21 at 10:36 -0400, Benjamin Coddington wrote:
> On 20 Mar 2025, at 13:53, Chuck Lever wrote:
>
> > On 3/19/25 5:46 PM, NeilBrown wrote:
> > > On Thu, 20 Mar 2025, Dai Ngo wrote:
> > > > Hi,
> > > >
> > > > Currently when the local file system needs to be unmounted for maintenance
> > > > the admin needs to make sure all the NFS clients have stopped using any files
> > > > on the NFS shares before the umount(8) can succeed.
> > >
> > > This is easily achieved with
> > > echo /path/to/filesystem > /proc/fs/nfsd/unlock_filesystem
> > >
> > > Do this after unexporting and before unmounting.
> >
> > Seems like administrators would expect that a filesystem can be
> > unmounted immediately after unexporting it. Should "exportfs" be changed
> > to handle this extra step under the covers? Doesn't seem like it would
> > be hard to do, and I can't think of a use case where it would be
> > harmful.
>
> No. I think that admins don't expect to lose all their NFS client's state if
> they're managing the exports. That would be a really big and invisible change
> to existing behavior.
>
If we're unexporting the filesystem though, then ISTM like we ought to
cancel any state that was held on it. Are you concerned the admin
inadvertently unexporting something or is there another use-case you're
worried about?
--
Jeff Layton <jlayton@kernel.org>
next prev parent reply other threads:[~2025-03-21 14:43 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-19 18:22 NFSD automatically releases all states when underlying file system is unmounted Dai Ngo
2025-03-19 18:28 ` Chuck Lever
2025-03-19 19:00 ` Dai Ngo
2025-03-19 19:24 ` Chuck Lever
2025-03-19 19:44 ` Dai Ngo
2025-03-19 21:46 ` NeilBrown
2025-03-19 22:12 ` Dai Ngo
2025-03-20 17:53 ` Chuck Lever
2025-03-21 14:36 ` Benjamin Coddington
2025-03-21 14:43 ` Jeff Layton [this message]
2025-03-21 15:07 ` Benjamin Coddington
2025-03-21 15:18 ` Chuck Lever
2025-03-21 15:51 ` Benjamin Coddington
2025-03-21 14:44 ` Chuck Lever
2025-03-26 0:23 ` NeilBrown
2025-03-26 3:20 ` Dai Ngo
2025-03-26 3:41 ` NeilBrown
2025-03-26 13:15 ` Chuck Lever
2025-03-27 22:47 ` NeilBrown
2025-04-09 21:00 ` Dai Ngo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4afafdfd5f7148cf8c9e0c9a65946726f29719e5.camel@kernel.org \
--to=jlayton@kernel.org \
--cc=bcodding@redhat.com \
--cc=chuck.lever@oracle.com \
--cc=dai.ngo@oracle.com \
--cc=linux-nfs@vger.kernel.org \
--cc=neilb@suse.de \
--cc=okorniev@redhat.com \
--cc=tom@talpey.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox