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

[Dai Ngo <dai.ngo@oracle.com>]

On 3/19/25 12:24 PM, Chuck Lever wrote:
> 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.

It's not just clearing the export cache. Since we do not know which export is
going away we have to release the states of all files that using the exports.
Meaning all NFS clients have to recover their states. Perhaps this still has
less impact than a full server restart.

-Dai

>
>