RE: [nfsv4] more on NFS4ERR_EXPIRED vs NFS4ERR_BADSTATEID

Dave.Noveck@netapp.com

Subject: RE: [nfsv4] more on NFS4ERR_EXPIRED vs NFS4ERR_BADSTATEID
Message-ID: <C8CF60CFC4D8A74E9945E32CF096548A01C8ED5A@silver.nane.netapp.com>
From: "Noveck, Dave" <Dave.Noveck@netapp.com>
Date: Thu, 15 Apr 2004 03:27:37 -0700

> >> The server can be "nice" in that upon lease expiration it keeps some
> >> of the state active and only releases that which has conflicting
> >> requests.
> >> In this case, I agree NFS4ERR_BAD_STATEID is the appropriate error.
> >> However, if the server is not keeping partial, expired state then it
> >> should
> >> go ahead and return EXPIRED since it will be an additional burden
> >> on the server to keep the extra information about just the state for
> >> which
> >> there was a conflict.
> >
> > I agree that the server should return EXPIRED in this case, but I
> > disagree about the reason.
> >
> > There would be no additional burden to return BAD_STATEID as the
> > "nice" server does.  That's because if the server simply deallocated
> > all the state entries along with the locks, when the lease expired,
> > any reference to the deallocated states would naturally result in
> > BAD_STATEID, with no extra server effort.
> 
> Are you thinking of a particular server/stateid implementation here?
> If so, maybe you could walk through some of the logical checks
> that demonstrate the "no additional burden".  In the way the Solaris
> server currently implements this, there is additional burden.

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.

With this arranngement, if you deallocate a state object due to a 
lock conflict where the lock conflicted with is associated with an
expired list, subsequent use of that stateid will get BAD_STATEID,
as a matter of course.

> The client may choose to an implementation as you suggest.  It may
> also choose an alternate path.  It isn't a requirement for the client
> to probe everything upon receive of BAD_STATEID.

Not exactly, but the penultimate paragraph of section 8.8 does say 
that when the lease period may have expired, the client must 
(but not "MUST"!) mark the locks unvalidated and then proceed
to validate (i.e probe) them.  So while getting EXPIRED would seem
to me to discharge the obligation ("Hey!  They're all gone, you can
stop validating now!"), BAD_STATEID does not ("That one's gone.  Now
get going and keep validating the rest of them.").

The only reason getting BAD_STATEID might cause you to probe is 
when you weren't aware that lease period may have expired.  If you
have not messed up and sent a bad stateid, then getting BAD_STATEID
is pretty good evidence that the lease had expired (or else how
was the stateid freed).  And if something has happened then it 
follows that it was possible (i.e. may have happened).  I think
that's an axiom of modal logic but I can't remember what it's
called.  Anybody know? 

-----Original Message-----
From: Spencer Shepler [mailto:spencer.shepler@sun.com]
Sent: Tuesday, April 13, 2004 1:20 PM
To: Noveck, Dave
Cc: rick@snowhite.cis.uoguelph.ca; nfsv4@ietf.org
Subject: Re: [nfsv4] more on NFS4ERR_EXPIRED vs NFS4ERR_BADSTATEID

On Apr 13, 2004, at 9:23 AM, Noveck, Dave wrote:

>> So you are partially describing the scenarios mentioned in
>> section 8.8 Server Revocation of Locks?
>
> Yes.  Those are the possibilities.
>
>> The server can be "nice" in that upon lease expiration it keeps some
>> of the state active and only releases that which has conflicting
>> requests.
>> In this case, I agree NFS4ERR_BAD_STATEID is the appropriate error.
>> However, if the server is not keeping partial, expired state then it
>> should
>> go ahead and return EXPIRED since it will be an additional burden
>> on the server to keep the extra information about just the state for
>> which
>> there was a conflict.
>
> I agree that the server should return EXPIRED in this case, but I
> disagree about the reason.
>
> There would be no additional burden to return BAD_STATEID as the
> "nice" server does.  That's because if the server simply deallocated
> all the state entries along with the locks, when the lease expired,
> any reference to the deallocated states would naturally result in
> BAD_STATEID, with no extra server effort.

Are you thinking of a particular server/stateid implementation here?
If so, maybe you could walk through some of the logical checks
that demonstrate the "no additional burden".  In the way the Solaris
server currently implements this, there is additional burden.

> The reason to return EXPIRED is that it avoids making the client
> probe each of stateids, when you could just tell him (via EXPIRED)
> that they all are gone, and save him the effort.  The client has
> to be prepared to probe all the stateids because servers may keep
> locks and only get rid of them when there is a conflict.  The
> limiting case is that the lease may expire, and there may then be
> individual conflicts with all of the locks within the lease and
> the client has to deal with that possibility.  So if the client
> is coded correctly, for the server to throw away all locks at
> lease expiration and return BAD_STATEID would work correctly.  It
> is just kind of anti-social to make him go to that extra effort
> when there is no possibility that there is the benefit of getting
> some of his locks back.

The client may choose to an implementation as you suggest.  It may
also choose an alternate path.  It isn't a requirement for the client
to probe everything upon receive of BAD_STATEID.

> BTW, there seems to be a third intermediate case between the standard
> one (free all locks at lease expiration) and the "nice" one of just
> freeing the ones that conflict that seems like it might be a valid
> choice.  That is, to keep the locks at lease expiration, but as soon
> as there is some conflict on any lock, to release all of them, rather
> than just the one in conflict.  If the client renewed the lease before
> any conflict occurred, he would be OK (as if no expiration happened),
> but if a conflict happend first, he would get EXPIRED (I believe) since
> the client can use this to know that all of the stateids associated
> with the locks are gone, which they would be in this case.  Comments?

Yes.  I agree that there is this third alternative and it is the 
easiest for
the server to implement; okay, next to just removing the state on lease
expiration.

Spencer

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4