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

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

On 3/19/25 3:00 PM, Dai Ngo wrote:
> 
> On 3/19/25 11:28 AM, Chuck Lever wrote:
>> Hi Dai, thanks for starting this conversation.
>>
>> [ adding Mike -- IIRC localio is facing a similar issue ]
>>
>> On 3/19/25 2:22 PM, 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.
>>>
>>> In an environment where there are thousands of clients this manual
>>> process
>>> seems almost impossible or impractical. The only option available now
>>> is to
>>> restart the NFS server which would works since the NFS client can
>>> recover its
>>> state but it seems like this is a big hammer approach.
>> Well we could do this instead by having the server pretend to reboot for
>> only clients that have mounted the export that is going away. That way
>> any clients that don't have an interest in the unexported/unmounted file
>> system don't have to deal with state recovery.
> 
> Is there a way to restart the NFS server for just the export that's going
> away?

There is not a way do that, currently, though it's a feature that has
been discussed for years.


> How do we specify an export when doing 'systemctl restart nfs-
> server'.

I would think that the emulated restart for select exports would be
handled entirely in the kernel, and not via systemd.


>>> Ideally, when the umount command is run there is a callback from the VFS
>>> layer
>>> to notify the upper protocols; NFS and SMB, to release its states on
>>> this file
>>> system for the umount to complete.
>>>
>>> Is there any existing mechanism to allow NFSD to release its states
>>> automatically on unmount?
>> Can you explain why you don't believe unexport is the right place to
>> trigger remote file closure?
> 
> Yes, unexport is another place that can be enhanced to trigger the
> releasing
> of all states of the export that going away. For this to work, the downcall
> mechanism between exportfs and the kernel needs to be enhanced to specify
> the export that is going away. This approach would eliminate the need for
> VFS involvement.
> 
> Currently when 'exportfs -u' is called, exportfs makes a downcall to the
> kernel to clear the cache of ALL exports and not just the one that going
> away.

Clearing the export cache is OK. That just means that new client
requests will trigger an upcall tp repopulate the kernel's export cache.
That is a much smaller bump in the performance road than a full server
restart.


-- 
Chuck Lever