Re: NFSD automatically releases all states when underlying file system is unmounted

[Benjamin Coddington <bcodding@redhat.com>]

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