On Wed, 01 Nov 2023, Chuck Lever III wrote: > > > On Oct 31, 2023, at 8:01 PM, NeilBrown <neilb@xxxxxxx> wrote: > > > > On Wed, 01 Nov 2023, Chuck Lever III wrote: > >> Howdy Neil- > >> > >>> On Oct 31, 2023, at 5:57 PM, NeilBrown <neilb@xxxxxxx> wrote: > >>> > >>> Revoking state through 'unlock_filesystem' now revokes any delegation > >>> states found. When the stateids are then freed by the client, the > >>> revoked stateids will be cleaned up correctly. > >> > >> Here's my derpy question of the day. > >> > >> "When the stateids are then freed by the client" seems to be > >> a repeating trope, and it concerns me a bit (probably because > >> I haven't yet learned how this mechanism /currently/ works)... > >> > >> In the case when the client has actually vanished (eg, was > >> destroyed by an orchestrator), it's not going to be around > >> to actively free revoked state. Doesn't that situation result > >> in pinned state on the server? I would expect that's a primary > >> use case for "unlock_filesystem." > > > > If a client is de-orchestrated then it will stop renewing its lease, and > > regular cleanup of expired state will kick in after one lease period. > > Thanks for educating me. > > Such state actually stays around for much longer now as > expired but renewable state. Does unlock_filesystem need > to purge courtesy state too, to make the target filesystem > unexportable and unmountable? I don't think there is any special case there that we need to deal with. I haven't explored in detail but I think "courtesy" state is managed at the client level. Some clients still have valid leases, others are being maintained only as a courtesy. At the individual state level there is no difference. The "unlock_filesystem" code examines all states for all client and selects those for the target filesystem and revokes those. NeilBrown > > > > So for NFSv4 we don't need to worry about disappearing clients. > > For NFSv3 (or more specifically for NLM) we did and locks could hang > > around indefinitely if the client died. > > For that reason we have /proc/fs/nfsd/unlock_ip which discards all NFSv3 > > lock state for a given client. Extending that to NFSv4 is not needed > > because of leases, and not meaningful because of trunking - a client > > might have several IP's. > > > > unlock_filesystem is for when the client is still active and we want to > > let it (them) continue accessing some filesystems, but not all. > > > > NeilBrown > > > > > >> > >> Maybe I've misunderstood something fundamental. > >> > >> > >> -- > >> Chuck Lever > > > -- > Chuck Lever > > >
