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

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

On 3/21/25 10:36 AM, 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.

To be clear, I mean that a file system should be unlocked only when it
is specifically unexported. IMO, unexport is usually an administrator
action that means "I want to stop remote access to this file system now"
and that's what unlock_filesystem does.

IMO administrators would be surprised to learn that NFS clients may
continue to access a file system (via existing open files) after it
has been explicitly unexported.

The alternative is to document unlock_filesystem in man exportfs(8).

And perhaps we need a more surgical mechanism that can handle the case
where the file system is still exported but the security policy has
changed. Because this does feel like a real information leak.


-- 
Chuck Lever