Subject: RE: [nfsv4] NFS4ERR_EXPIRED vs NFS4ERR_BAD_STATEID

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 10 Mar 2006 12:33:37 -0500

Bruce wrote:
> On Fri, Mar 10, 2006 at 09:21:16AM -0500, Noveck, Dave wrote:
> > 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,
>
> It looks to me like EXPIRED is clearly required by the spec in this
> case:

If by "this case" you mean the one I'm talking about, then I have to
disagree.

>	"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."

This material appears in a narrative describing the other case, i.e. the
one in which the server responds to the lease expiration by freeing all
locks.  The case I'm talking about hasn't even been mentioned yet, and
there is nothing to suggest that this statement is meant to apply to
that very different situation.

> > 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.

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

I don't know.  I always thought that SETCLIENTID with the same verifier
was a no-op, except for updating callback information, which I don't
think applies here.

Since you are supposing that you will do a SETCLIENTID with the same
verifier, what do you expect it to do and not do?  I guess it will not
throw away locks, but what will it do that justifies someone doing it
when they receive EXPIRED.

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

On Fri, Mar 10, 2006 at 09:21:16AM -0500, Noveck, Dave wrote:
> 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,

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."

> 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.

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

> 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.

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.

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

---

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

> that very different situation.

OK, fair enough.

I still find the interpretation that EXPIRED *only* applies to the case
where all state has diseappeared a little hard to reconcile with the
text of the spec, though.

> I don't know.  I always thought that SETCLIENTID with the same
> verifier was a no-op, except for updating callback information, which
> I don't think applies here.
> 

At the time they received EXPIRED they don't know yet whether the server
has lost all their client state.  The SETCLIENTID will reestablish their
state if necessary, and is harmless if not, so it seems like a sensible
thing to send.

--b.