> On Nov 1, 2023, at 12:43 AM, NeilBrown <neilb@xxxxxxx> wrote: > > 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. Dai can correct me if I've misremembered, but NFSD's courteous server does not currently implement partial loss of state. If any of a client's state is lost while it is disconnected, the server discards its entire lease. Thus if an admin unlocks a filesystem that a disconnected client has some open files on, that client's entire lease should be purged. >>> 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 -- Chuck Lever
