On 11/1/23 8:41 AM, Chuck Lever III wrote:
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.
Ben is correct, courtesy state is managed at the client level. The
server does not deal with individual state of the courtesy client.
The courtesy clients and their states are allowed to be around until
the memory shrinker kicks in and the worker starts reaping clients in
NFSD4_COURTESY state.
-Dai
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
