Subject: RE: Some issues with stateid's

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 8 Nov 1999 14:28:38 -0800

> On Thursday November 4, [email-masked] wrote:
> >  
> > > 
> > > This shows you have to read the spec carefully.... I was under the
> > > impression that "any successful use of a stateid" would renew all
> > > locks for all lockowners for the same client. But as you say, it
> > > isn't "any successful use" but is "any successful IO" 
> (Section 8.4).
> > > Given that the I/O is seen as "a positive indication that 
> the client
> > > is still alive", and that a lock request is also an 
> indication that
> > > the client is still alive, should we change:
> > >  
> > >    Any I/O request that has been made with a valid stateid is 
> > > a positive
> > >    indication that the client is still alive and locks are being
> > >    maintained.  
> > > 
> > > to something like:
> > > 
> > >    Any I/O request or Locking or unlocking request with a valid
> > >    stateid, or any open request with a valid clientid, is 
> a positive
> > >    indication that the client is still alive and locks are being
> > >    maintained.
> > 
> > I proposed something like this in:
> > 
> > http://playground.sun.com/pub/nfsv4/nfsv4-wg-archive/1670.html
> > 
> > and Robinson responded:
> > 
> > http://playground.sun.com/pub/nfsv4/nfsv4-wg-archive/1671.html
> > 
> > I think that locks and unlocks would be OK, but since that doesn't
> > get us all the way to a uniform expiration point, I don't
> > see that it's worth it.
> 
> Ah yes, I hadn't got up to there in the archive yet (it is heavy
> going).  However....
> 
>   David: you said:
> 
>       On an OPEN, the client does not send a stateid so it cannot tell
>       the server what its view of the world is.

I think I was paraphrasing Dave Robinson's explanation of why this
won't work.
  
> 
>   Yet the spec, when it talks about automatic lease renewal in section
>   8.4  says that what is needed is
>        "a positive indication that the client is still alive and locks
>        are being maintained"
> 
>   So the issue is not "agreed view of world" but is "still alive and
>   active".  Surely an OPEN call, which uses a clientid to gain a share
>   reservation, is "a positive indication that the client is still
>   allive and locks are being maintains".

It certainly proves the client is alive.  I guess the issue
is whether the client is still alive (i.e has not gone down 
in the interim).  With a stateid, that is should be assured
by the server putting some sort of instance id (boot time or
something).  I may be wrong, but I don't see that is assured 
for an nfs_lockowner.

> 
> 
> > 
> > > 
> > > or maybe:
> > > 
> > >    Any successful use of a valid stateid or a clientid is 
> a positive
> > >    ..... 
> > > 
> > > That would neatly sidestep the different expiry times, 
> though we still
> > > need a well defined resolution path from lock expiry.  Maybe bad
> > > (NFS4ERR_EXPIRED) stateids should still be allowed for LOCKU
> > > requests.  Afterall, the problem is that the lock is 
> gone, so asking
> > > "please remove this lock" shouldn't be too onerous..
> > 
> > Maybe but since you have a lock which the server will take away
> > if anyone make a cnflicting request (whether you unlock it or not),
> > what's the point of allowing the unlock?  It doesn't really do 
> > anything.
> 
> What the LOCKU request achieves is that it says to the server "I
> acknowledge that I have lost this lock".  This allows the client-state
> to go through a state-transition, or series of transitions, from being
> an EXPIRED state to being a non-EXPIRED state which can then be used
> or closed like any other state.

OK.  That makes sense to me.

---

From: Neil Brown <[email-masked]>
Date: Mon, 15 Nov 1999 12:16:35 +1100 (EST)

> I think I was paraphrasing Dave Robinson's explanation of why this

The "David: you said" was addressed to David Robinson - I was assuming
that the difference between Dave and David would disambiguate.  Sorry
for the confusion.  The words were David Robinson's.

> something).  I may be wrong, but I don't see that is assured 

I think the clientid returned by SETCLIENTID needs to be unique in
space and time for essentialy the same reasons that I think it needs
to change on CLOSE/EXIT/LOCKU_OWNER (see previous mail) - to guard
against delayed delivery.

Actually, I would really like it if clients could get the same
clientid between server restarts, as then it would be a perfect
candidate for the create verifier!  But I don't think it can work.

NeilBrown