Subject: RE: Changes for CLOSE_ALL operation

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 7 Jan 2000 06:28:18 -0800

> > If you can give up on a stateful request (LOCK, LOCKU, OPEN, CLOSE)
> > and continue operation of the lockowner (i.e. process), then 
> > you have problem.
> > 
> > One answer, which you might not like, is "Don't do that".
> 
> Perhaps I'm missing something, but it seems to me that if  
> the client is
> capable of maintaining an nfs_lockowner, it is capable of 
> maintaining a record
> of the last stateful request on that nfs_lockowner that it 
> gave up on. Once
> the client is ready to continue operation, it's free to 
> re-issue the last
> request, and if the request is a LOCK or OPEN, issue a LOCKU 
> or CLOSE to
> nullify it. One could use this strategy to obviate the need 
> to issue or a
> RELEASE_ALL, though I willing to concede that RELEASE_ALL 
> might be simpler for
> the common case.

OK.  This works.

I had been worried about seqid management and not knowing the
proper stateid for requests that require them.  Your solution
is very nice because because it takes advantage of the 
existing sequence logic to resolve all that.  If you re-issue
a LOCK or OPEN with the original seqid you'll either have it 
done if it wasn't or get back the response from the original
request, otherwise.  The you have the data to do the CLOSE
or LOCKU properly.  In the case of an interrupted LOCKU or
CLOSE, the same reissue trick works.  Neat.

Maybe the spec should say something about this, for people
(like me) to whom this solution is not as obvious as it 
was to you.

---

From: Mike Eisler <[email-masked]>
Date: Fri, 7 Jan 2000 06:46:44 -0800 (PST)

> > Perhaps I'm missing something, but it seems to me that if  

I missing something but it wasn't fatal. See below.

> done if it wasn't or get back the response from the original
				^^^^^^^^^^^^^^^^^^^^^

This is the part that was missing. See below.

> (like me) to whom this solution is not as obvious as it 

Yes the spec should, but mainly because, on further thought, I also realize
that the server MUST similarly keep track of the last request it received and
responded to, including the requests's seqid (which should be obvious from the
spec), and the request's stateid, and the responses new stateid. Otherwise, we
are relying on the the duplicate request cache to furnish the correct
information, and since dup req caches typically have an LRU algorithm, it is
possible my proposed scheme will fall apart.

Since the server is maintaining state for nfs_lockowner as long as there
are open files, this is not an onerous requirement. Of course, once the
client has issued the last CLOSE, RELEASE_ALL, or LOCKU on its last file,
the server will want to keep the nfs_lockowner around for a while to ensure
that a retried CLOSE, RELEASE_ALL, LOCKU gets the right results. This is
sort of analagous to the TCP state machine that has end-points stay in 
CLOSEWAIT or TIMEWAIT for a while before finally disposing of them.

How strongly do we feel we need RELEASE_ALL then?

	-mre