Subject: RE: [nfsv4] NFS4ERR_EXPIRED vs NFS4ERR_BAD_STATEID

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 10 Mar 2006 09:21:16 -0500

> The difference is that if your client gets an NFS4ERR_EXPIRED, then it
> immediately knows that it has to call SETCLIENTID instead of having to
> probe using a RENEW call.

Exactly.  But in the case in which a client has his lease expire, does
not lose (all) his locks, only loses one due to a conflict, and then
renews his lease, you most certainly don't want him to do SETCLIENTID.

Doing SETCLIENTID would mean that he would throw away all of the locks
that he had at the time, rather than just the one in which there was
a conflict.

Also, if, as has been suggested, a client regets locks after this he
is exposed to a conflicting lock between the SETCLIENTID and the reget.
Further, for the lock he actually lost, we know that there was a conflict
and the chances are quite high that he will get the lock back despite the
fact that he shouldn't.  In the case in which the server reboots, the
spec goes to great lengths to assure that reclaims do not give a client
back a lock when there was a conflict, but if a client tries to reget
locks in this situation, he has no such protection.

So in the case in which expiration causes only a single lock to be lost
returning EXPIRED is bad precisely because it will cause a SETCLIENTID.

> NFS4ERR_BAD_STATEID is described in section 8.1.3 as indicating "a logic
> error on the part of the client or server". I can't see that to be the
> case here.

Actually it says "will occur" when there has been such error.  It 
doesn't say "will only occur".  It also says "This should not happen"
but it unclear what exactly "this" refers to.  

But let's look at another part of section 8.1.3, which says:

>   o  The stateid was generated by the current server instance but the
>      stateid does not designate a locking state for any active
>      lockowner-file pair.  The error NFS4ERR_BAD_STATEID should be
>      returned.

But section 8.6.3 says:

>   As a courtesy to the client or as an optimization, the server may
>   continue to hold locks on behalf of a client for which recent
>   communication has extended beyond the lease period.  If the server
>   receives a lock or I/O request that conflicts with one of these
>   courtesy locks, the server must free the courtesy lock and grant the
>   new request.

My interpretation is that the result of freeing that locking state is that
the associated stateid cease to "designate a locking state of any active
lockowner-file pair", making BAD_STATEID a reasonable choice.

But if you don't think this is right, what do you suggest?  EXPIRED is
wrong because trhe spec talks about EXPIRED in the case in which all
lock state is freed on lock expiration, and also because the consequence,
the client doing a SETCLIENTID (although the spec doesn't talk about 
this or about regetting locks, but only about report errors to applications)
would be bad.  So if BAD_STATEID is also wrong, what is right?

Note about the v4.1 spec.  The first paragraph of section 8.6.3 has a 
number of issues/confusion we should address:

    It says that the stateid's become "invalid or stale" and then
    proceeds to talk about returning EXPIRED.  There is a disconnect
    between stateid state and errors.

    EXPIRED is not described with the the *_STATEID errors but logically
    it should be.

    It doesn't discuss what a client should do about EXPIRED except for
    the stuff about returning error.  In light of our discussion, I
    think there needs to be more.

-----Original Message-----
From: Trond Myklebust [mailto:[email-masked]]
Sent: Friday, March 10, 2006 12:23 AM
To: Noveck, Dave
Cc: J. Bruce Fields; [email-masked]; [email-masked];
[email-masked]
Subject: RE: [nfsv4] NFS4ERR_EXPIRED vs NFS4ERR_BAD_STATEID

On Thu, 2006-03-09 at 12:39 -0500, Noveck, Dave wrote:
> Exactly so.  If he holds onto the stateids that have not expired
> he knows which ones to accept.  Other will get an error.  But,
> to distinguish between those that have expiired and those that
> were never valid, one would have to hold onto the expired ones
> as well.  So it comes down to the value of informing the client
> of that distinction, and except for a vague sense that that is
> nicer, fiendlier, etc., I can't see what it is.  If a client has
> a valid stateid and it becomes invalid, he nedds to deal with 
> the consequences and I don't see where the consequences are
> any different depending on the EXPITED/BAD_STATEID distinction.

The difference is that if your client gets an NFS4ERR_EXPIRED, then it
immediately knows that it has to call SETCLIENTID instead of having to
probe using a RENEW call.

NFS4ERR_BAD_STATEID is described in section 8.1.3 as indicating "a logic
error on the part of the client or server". I can't see that to be the
case here.

Cheers,
  Trond

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

---

From: "J. Bruce Fields" <[email-masked]>
Date: Fri, 10 Mar 2006 10:15:03 -0500

On Fri, Mar 10, 2006 at 09:21:16AM -0500, Noveck, Dave wrote:
> renews his lease,

It looks to me like EXPIRED is clearly required by the spec in this
case:

	"Once the client is able to reach the server after such a
	network partition, all I/O submitted by the client with the now
	invalid stateids will fail with the server returning the error
	NFS4ERR_EXPIRED."

> that he had at the time, rather than just the one in which there was

The client's SETCLIENTID will be with the same verifier as before,
won't it?

> fact that he shouldn't.

I'd assume the careful client would attempt to reget locks with the
reclaim bit set.  The server can refuse them with NO_GRACE or
RECLAIM_BAD.

--b.