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

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

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? How do we specify an export when doing 'systemctl restart nfs-server'.

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

>
>
>> Unmount is not a frequent operation. Is it justifiable to add a bunch of
>> complex
>> code for something is not frequently needed?
> I agree that I/O is significantly more frequent than unexport/unmount.
> It suggests we want a solution that does not make a heavy impact on the
> I/O code paths.

Thanks,
-Dai

>
>