Subject: RE: [nfsv4] re: NFS4ERR_EXPIRED or NFS4ERR_STALECLIENTID?

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 5 Apr 2004 10:36:12 -0700

You can distinguish STALECLIENTID without saving clientid's forever.
 
If you put the server instance (or reboot time) in one half of the
client id then you can determine if the server has rebooted, simply by
comparing that field.
 
The spec text does not talk about EXPIRED with regard to client id's. It
does with respect to stateid's.  However, the ops that list
STALECLIENTID as an error also list EXPIRED so I don't see what else you
could return if you get a clientid you don't recognize and it doesn't
show that you have rebooted.
 
One exception is DELEGPURGE.  It shows STALECLIENTID but not EXPIRED so
it isn't clear what you would do if you get a clientid you don't
recognize and it doesn't look stale.  INVAL would be the obvious answer
but that isn't on the error list either :-(
 
So I think you have to be able to distinguish clientid's you gave out
from those your predecessor instance(s) would have given out essentially
forever.  However, for anything that looks like it cam from the current
server instance, if you don't recognize it, you return EXPIRED and there
is no issue of having to save them or distinguish those that expired
from others.  There is no BAD_CLIENTID error .  This conclusion does
seem to be at variance with the definition of EXPIRED, "A lease has
expired that is being used in the current operation", but there doesn't
seem to be any other error to use.

Which brings us to stateid's since there is a BAD_STATEID error.  I
believe you can do the same thing for stateid's that you do for
clientid's to distinguish when to return STALE_STATEID.  This leaves the
question of distinguishing EXPIRED from BAD_STATEID.
I don't see where the spec gives any useful guidance on how one is to
distinguish these two cases without storing expired stateid's forever
(have I missed it?).  My answer is to do the best you can but
practically speaking I think clients have to be prepared to get
BAD_STATEID and do what they would have done if they got EXPIRED.
Either one says the server is still up, you lost your lock, and if you
try to re-establish it, you may not succeed and even if you do, you
should be aware that someone may have had a conflicting lock in the
interim, i.e. you cannot assume continuity of your lock possession.

-----Original Message-----
From: Stevan Steve Allen [mailto:[email-masked]] 
Sent: Monday, April 05, 2004 12:21 PM
To: [email-masked]
Subject: Re: [nfsv4] re: NFS4ERR_EXPIRED or NFS4ERR_STALECLIENTID?

Spencer,  I fell off the wagon here. 

> NFS4ERR_STALE_CLIENTID is only returned when the server
> has restarted. 

Seems the server may not find a server generated clientid for 2
conditions. 
  o Server restarted 
  o Clientid was released (freed) 

Your statement indicates the server has to determine which condition
occurred.  Rick asked how long the clientid has to be kept around (so
separate errors can be returned). 

Thanks,
Stevan C. Allen

---

From: Spencer Shepler <[email-masked]>
Date: Mon, 5 Apr 2004 14:33:17 -0500

On Apr 5, 2004, at 12:36 PM, Noveck, Dave wrote:

> The spec text does not talk about EXPIRED with regard to client id's. 
> It does with respect to stateid's.  However, the ops that list 
> STALECLIENTID as an error also list EXPIRED so I don't see what else 
> you could return if you get a clientid you don't recognize and it 
> doesn't show that you have rebooted.
>  
> One exception is DELEGPURGE.  It shows STALECLIENTID but not EXPIRED 
> so it isn't clear what you would do if you get a clientid you don't 
> recognize and it doesn't look stale.  INVAL would be the obvious 
> answer but that isn't on the error list either :-(
>  
> from those your predecessor instance(s) would have given out 
> essentially forever.  However, for anything that looks like it cam 
> from the current server instance, if you don't recognize it, you 
> return EXPIRED and there is no issue of having to save them or 
> distinguish those that expired from others.  There is no BAD_CLIENTID 
> error .  This conclusion does seem to be at variance with the 
> definition of EXPIRED, "A lease has expired that is being used in the 
> current operation", but there doesn't seem to be any other error to 
> use.
> clientid's to distinguish when to return STALE_STATEID.  This leaves 
> the question of distinguishing EXPIRED from BAD_STATEID.

I would like to reiterate Dave's comment above that the server "do the 
best it can".
A client will likely treat EXPIRED differently than BAD_STATEID in that 
EXPIRED
applies to the entire clientid and BAD_STATEID is just for that 
particular file (or
likely to be that particular file).  The recovery paths could apply 
different
approaches and if a simple timestamp in the stateid provides a directive
then EXPIRED would have greater precedence than BAD_STATEID in
my opinion and experience.