Re: [nfsv4] NFS4ERR_ADMIN_REVOKE and edge conditions

[Spencer Shepler <[e-mail]>]

Rick,

Sorry for coming in late on this....

The intent of NFS4ERR_ADMIN_REVOKED, as mentioned in section 8.8 that
referenced previously, is for administrative revocation of state.  The
best analogy to NFSv3 is when a client was "turned off" and file
locking state was left over at the server.  Most implementations allow
for revocation of all of the client's file locking state for cases
like this.  The addition of NFS4ERR_ADMIN_REVOKED was added because it
was assumed that similar adminstrative commands would exist for NFSv4
state (even thought it was leased based state).  These commands would
not necessarily remove all client state but may be targeted at
open/lock state for a particular file or filesystem.  

The cases considered were the file lock held but could not associate
with the proper application to kill to release the file lock; the
other was a broken client implementation that did not release the lock
properly and continued to renew its lease.

In these cases, not all client state would be removed ot need to be
removed.  However, the client should be told of the revocation and
hence the NFS4ERR_ADMIN_REVOKED.  The reason for returning this error
on RENEW is similar to the NFS4ERR_CB_PATH_DOWN such that the client
is active on other parts of the server's resources but not the part
where the state has been revoked.  The client could be told earlier of
the ADMIN_REVOKED than later and it could then in turn notify the
client environment as per its policies.  The idea was that the client
could "check" its state to determine what had been revoked; no clear
guidance was obviously given but something like a zero length read on
open files may suffice.

So for the specific questions....

On Fri, [e-mail] wrote:
> I've been trying to figure out when the server can safely assume that the
> client has seen the NFS4ERR_ADMIN_REVOKED, so it can be allowed to reclaim
> state after a server reboot. (Related to the edge conditions discussed in
> Sec. 8.6.3)

If the server has rebooted, it just needs to return things like
NFS4ERR_STALE_CLIENTID/NFS4ERR_STALE_STATEID.  The ADMIN_REVOKED is
not required because all state has been removed for the client.

> When the server revokes all state for a client, it seems pretty straight
> forward:
> - clientid plus all stateids get NFS4ERR_ADMIN_REVOKED when used

See above, appropriate _STALE_ errors should be returned or
NFS4ERR_EXPIRED in the case where the server has not rebooted.

> - unless the client is partitioned, it will see the errors and presumably
>   do a setclientid/setclientid_confirm to get new state:
>   - the server can then note the client has seen the loss of state and
>     can again be allowed to recover state, noted in stable storage used
>     for server reboot
> - if it doesn't do a setclientid/setclientid_confirm, it won't be allowed
>   to recover state, but since there isn't any valid state for it to
>   recover (it was all revoked), that seems fine
> 
> But, when the server only revokes some state for the client (one lockowner
> and associated locks or ...), how can the server know that the client
> recognizes it has lost the state, so it can allow it to do reclaims after
> a server reboot?
> - it is tempting to say it would be ok once NFS4ERR_ADMIN_REVOKED is replied
>   to use of the stateid, but can it be certain the client received the
>   reply? (If another Op in sequence by seqid number was done for the stateid,
>   it could then be certain, but a client isn't likely to continue to use a
>   stateid after it gets NFS4ERR_ADMIN_REVOKED for it.)
> 
> It seems that, after revoking state, the server can only allow reclaims after
> a server reboot if the client does a subsequent setclientid/setclientid_confirm.
> But, if only some state was revoked, will it do that?

In the case of server reboot, all of this is moot.  The server doesn't
need to worry about partial revocation before the reboot because all
of it is gone now.

Spencer

_______________________________________________
nfsv4 mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/nfsv4