Subject: RE: Changes for CLOSE_ALL operation

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 6 Jan 2000 13:46:02 -0800

> RELEASE_ALL (as Spencer has renamed it) addresses what I expect to be
> the common case: the client fails to get the lock and the application
> bails out and exits.  That's good.
> 
> Unfortunately, it's possible for the application to take a signal
> (thereby aborting the current lock request), catch the signal, and
> then resume operation.  It seems to me that any time the client aborts
> a LOCK or LOCKU call before receiving a reply, it needs to
> resynchronize with the server.  After poking through Section 8 a
> couple times, I don't see how the client tells the server "there may
> be a problem, let's resynchronize locking state".  Am I missing
> something, or is this a hole in the protocol?
 
I discussed some issues related to this at my talk at the Washington
IETF meeting.  There is an incompatibility between a lot of 
things that have traditionally been done in NFS implementations
(e.g. giving up on requests) and the fact that nfs v4 is no
longer stateless.  We're not in Kansas anymore (besides believing
in evolution, I mean :-).

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

If this is too onerous for the user, there is an alternative
but it means changing some of the underlying RPC client-side
infrastructure, which people might not want to do.  From the
protocol point of view, there is really is no reason that
the fact that a process does not want to wait for the reply
to a given request, means that the client as whole has to forget
about it completely, and thus lose the ability to find
out the stateid when the server actually replies.  I suspect
that making such a big change in the implementation
infrastructure is not going to appeal to a lot of people
(I think it's kind of neat, but then I don't have to do
it).

Whether this is truly a hole in the protocol or just an
issue of implementation pragmatics doesn't really matter.
We need to have a protocol that people are going to 
implement.

If "Just say 'No'" isn't acceptable and allowing the 
process to disconnect from an ongoing request isn't
going to fly, then the protocol is going to have to 
help address this.  And since we want to have the
protocol be functionally complete, I think it has to
be now.

---

From: Mike Eisler <[email-masked]>
Date: Thu, 6 Jan 2000 14:24:35 -0800 (PST)

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

The advantage NFSv4 has over NLM, is in the area of blocking locks. With NLM,
the server would block on the client's behalf. With NFSv4, the
server  doesn't block indefinitely on the client's behalf, and instead
returns success or failure immediately.

	-mre

---

From: Mike Kupfer <[email-masked]>
Date: Thu, 06 Jan 2000 14:28:36 -0800

> Once

Sounds good to me.

mike