On 21 Mar 2025, at 10:43, Jeff Layton wrote: > 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? I'm worried about changing existing behavior and the fallout, today I can un-export and re-export all day long, and as long as I re-export the filesystem the applications on those clients are unaffected. I'm an old sysadmin that knows that I can un-export and re-export stuff and not have to worry about state loss. There have to be existing systems and people that also have that knowledge built in by now. If we change this, we break things. Ben
