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. > All state for NFSv4 exports, and all NLM locks for NFSv2/3 exports, will > be invalidated and files closed. NFSv4 clients will get > NFS4ERR_ADMIN_REVOKED when they attempt to use any state that was on > that filesystem. I'm wondering if this mechanism also flushes courtesy client state for the file system that is about to be exported... it should, if it does not already take care of that. > (I don't think this flushes the NFSv3 file cache, so a short delay might > be needed before the unmount when v3 is used. That should be fixed) > > NeilBrown > > >> >> 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. >> >> 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? >> >> Unmount is not a frequent operation. Is it justifiable to add a bunch of complex >> code for something is not frequently needed? >> >> I appreciate any opinions on this issue. >> >> Thanks, >> -Dai >> >> >> >> >> >> >> > -- Chuck Lever
