On Thu, Jan 27, 2022 at 03:58:10PM +1100, NeilBrown wrote: > If a filesystem is exported to a client with NFSv4 and that client holds > a file open, the filesystem cannot be unmounted without either stopping the > NFS server completely, or blocking all access from that client > (unexporting all filesystems) and waiting for the lease timeout. > > For NFSv3 - and particularly NLM - it is possible to revoke all state by > writing the path to the filesystem into /proc/fs/nfsd/unlock_filesystem. > > This series extends this functionality to NFSv4. With this, to unmount > an exported filesystem is it sufficient to disable export of that > filesystem, and then write the path to unlock_filesystem. It's always been weird that /proc/fs/nfsd/unlock_filesystem was v3-only, so thanks for looking into extending it to v4. You can accomplish the same by stopping the server, unexporting, then restarting, but then applications may see grace-period-length delays. So in a way this is just an optimization for what's probably a rare operation. Probably worth it, but I'd still be curious if there's any specific motivating cases you can share. I guess the procedure would be to unexport and then write to /proc/fs/nfsd/unlock_filesystem? An option to exportfs to do both might be handy. > I've cursed mainly on NFSv4.1 It does inspire strong feelings sometimes. --b. > and later for this. I haven't tested > yet with NFSv4.0 which has different mechanisms for state management. > > If this series is seen as a general acceptable approach, I'll look into > the NFSv4.0 aspects properly and make sure it works there. > > Thanks, > NeilBrown > > > --- > > NeilBrown (4): > nfsd: prepare for supporting admin-revocation of state > nfsd: allow open state ids to be revoked and then freed > nfsd: allow lock state ids to be revoked and then freed > nfsd: allow delegation state ids to be revoked and then freed > > > fs/nfsd/nfs4state.c | 105 ++++++++++++++++++++++++++++++++++++++++---- > 1 file changed, 96 insertions(+), 9 deletions(-) > > -- > Signature
