Subject: spec update?

From: "Kendrick M. Smith" <[email-masked]>
Date: Tue, 1 May 2001 17:33:37 -0400 (EDT)

Toward the end of Connectathon, it was agreed informally that a number of
changes needed to be made to the spec.  As I see it, the main issues are:

  o  A precise specification of the conditions under which a lockowner's
seqid should be incremented on error.  On the one hand, if the seqid is
never incremented on error, which is what we're doing now, we are open to
some inherent race conditions (as pointed out by Neil Brown on the list
shortly before Connectathon).  On the other hand, for some errors, such
as ERR_BAD_STATEID, the server can't identify which lockowner the client
is trying to specify, so the client can't assume that the seqid has been
incremented on the server (although it's not clear that anything would be
lost if the seqids got desynchronized in this case; if the client is
emitting bad stateids, there's probably not much hope of the client
recovering in any case).
   o  A precise specification of what types of byterange locking servers
are required to support without returning ERR_LOCK_RANGE.  Can a write
lock be atomically downgraded to a read lock, for example?  Should there
be a way for a client to ask the server what types of locking operations
it supports, such as a new file attribute in GETATTR?
   o  Replacing 64-bit stateids with 128-bit stateids.  (Everyone seemed
to think that this was a good idea.)

Here are two more issues which I seem to recall most people agreeing on,
although it was less clear whether these were definitely going into the
spec or not:

   o  Modifying the RENEW operation to take a clientid as its argument
instead of a stateid.
   o  Adding a 'type' field, of type nfs_lock_type4, to the LOCK4denied
structure, to support correct implementation of the POSIX system call
fcntl(F_GETLK,...).

I was wondering whether these changes are still going to be made, and if
so, when they will be made available, even in "unofficial" form pending
inclusion into the spec.  Our implementation is becoming increasingly
polluted with conditionals such as #if STATEID_128_BITS (I don't know if
the other developers are doing something similar), and it's getting to be
quite awkward.  It would be nice to put these issues to rest soon,
especially since the next bakeoff is on the horizon..       - k

---

From: Spencer Shepler <[email-masked]>
Date: Tue, 1 May 2001 16:41:39 -0500

On Tue, Kendrick M. Smith wrote:
...
> especially since the next bakeoff is on the horizon..       - k

I have a list of issues and have been working to clean them up before
sending them to the WG.  I will make sure these are included.

From that we can work to resolve the issues and make the necessary
changes to rfc3010.

Spencer

-- 

- Spencer -