Subject: [nfsv4] more re: NFSERR_EXPIRED vs NFSERR_BADSTATEID

From: [email-masked]
Date: Thu, 15 Apr 2004 10:59:00 -0400 (EDT)

> What I'm thinking of is a stateid that contains a server boot time
> (to detect STALE_STATEID), an index into a table of state objects,
> and a generation number (number of times the state object at that
> index has been alloctated).  Assusming a stateid is not stale, and
> that the index is within range, if the state object is marked free,
> or the generation number in the object doesn't match that in the
> stateid, BAD_STATEID is returned.

If the above mentioned "table" is indeed just that, and not actually
some dynamically allocated data structure that varies in size, I would
agree. On the other hand, if the table is really a dynamically allocated
data structure, the expiry allows all entries related to that clientid
to be released at that time, whereas for the above, they must remain
until a conflicting request invalidates them. If the lease has expired,
that suggests either a client crash or network partitioning and, as such,
recovery might be a long time coming. (And, I suspect that conflicting
requests are infrequent, since that would imply concurrent conflicting
access to the file by multiple clients, for this case.)

Is this the additional overhead Spencer was thinking about?
(However, I think you can counter the above argument
with the statement that a server can simply delay deletion of the state
until a conflicting request occurs OR the server becomes memory constrained
and does some garbage collection.)

> ...is pretty good evidence that the lease had expired (or else how
> was the stateid freed). ...
The case of a conflict with a delegation that couldn't be recalled,
occurred, but without lease expiry?
(I think the client can normally avoid this by returning delegations
ASAP upon NFS4ERR_CB_PATH_DOWN, as mentioned in a previous post.)

Although it seems nitpicky, I think that this is an important little
corner of the protocol to have a clear understanding of, in order to
avoid interoperability problems? rick

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

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 15 Apr 2004 14:15:41 -0500

> Is this the additional overhead Spencer was thinking about?

My question was to ensure I understood the basis for the assertion
and it seems that the assertion about being able to easily return
BAD_STATEID relies on a particular implementation.  You have
phrased my next statement for me well. :-)

> and does some garbage collection.)

But this is based on a timeout and that is not reliable and that may
be an issue but I haven't thought enough about it.

> avoid interoperability problems? rick

Yes, this does need to be described sufficiently.

Spencer

---

From: Paul Mazzurana <[email-masked]>
Date: Tue, 20 Apr 2004 12:26:24 -0500

Team,

With all this discussion on NFS4ERR_EXPIRED vs. NFS4ERR_STALE_CLIENTID 
etc., I was checking our implementation and also re-reading the RFC a bit 
closer.

I noticed that the DELEGPURGE operation does not have NFS4ERR_EXPIRED nor 
NFS4ERR_ADMIN_REVOKED as possible error codes. Since a server may mark a 
clientid as expired, it would seem that the server should let the client 
know this on any operation that takes a clientid. Also, for those servers 
that have a whiz-bang admin tool to revoke a client, the server should 
also let the client know on those operations that take a clientid. 

Is it possible to add these 2 error codes to the errata?  OR should the 
server just translate these errors to NFS4ERR_SERVERFAULT (or 
NFS4ERR_STALE_CLIENTID ...though I think that xlate would be misleading). 

thoughts?
--
Paul D. Mazzurana

---

From: Spencer Shepler <[email-masked]>
Date: Tue, 20 Apr 2004 13:48:52 -0500

On Apr 20, 2004, at 12:26 PM, Paul Mazzurana wrote:

> etc., I was checking our implementation and also re-reading the RFC a 
> bit closer.
>
> I noticed that the DELEGPURGE operation does not have NFS4ERR_EXPIRED 
> nor NFS4ERR_ADMIN_REVOKED as possible error codes. Since a server may 
> mark a clientid as expired, it would seem that the server should let 
> the client know this on any operation that takes a clientid. Also, for 
> those servers that have a whiz-bang admin tool to revoke a client, the 
> server should also let the client know on those operations that take a 
> clientid.
>
> Is it possible to add these 2 error codes to the errata?  OR should 
> the server just translate these errors to NFS4ERR_SERVERFAULT (or 

The client should be notified about administrative action when the
client submits its OPEN request with type CLAIM_DELEGATE_PREV.
The ADMIN_REVOKED error is present for OPEN.

For DELEGPURGE, the clientid should be the current clientid and
therefore, adding NFS4ERR_EXPIRED seems appropriate in case there
is a window between the client's delegation reclaims and the DELEGPURGE.

Spencer