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

[Chuck Lever <chuck.lever@oracle.com>]

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.

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.


> 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.


-- 
Chuck Lever