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
