On 21 Mar 2025, at 11:18, Chuck Lever wrote: > On 3/21/25 11:07 AM, Benjamin Coddington wrote: >> 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. > > Is it documented that you can rely on that? If not, then I'd say old > sysadmins should expect that behavior can be changed. 2-cents. No, I don't know any place it's documented. It's the consequences of this change I'm worried about, not our ability to say "you should have expected this!" > Also, as a sysadmin, I would never unexport and expect there to be no > consequences. Running apps that try to open a file on a recently > unexported share /will/ get ESTALE -- NFSv3 holds no open state at > all, so the next NFS READ on that share will fail with EIO. > > So unexport is already not without some consequences. IMO it's not > sensible to expect an unexport / re-export cycle will be safe under all > circumstances. This is true. >> There have to be existing systems and >> people that also have that knowledge built in by now. If we change this, we >> break things. > > No lies detected. ;-) > > Another reality test is to audit other server implementations. I can ask > around. Thanks for taking my worries seriously. Since I'm working on a distro, I'm sensitive to how many folks might get upset when an upgrade breaks things. Ben
