Subject: RE: leases revisited was RE: Some issues with stateid's

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 4 Nov 1999 07:13:06 -0800

> Thus far, every objection made to the locking protocol has 
> been successfully
> rebutted by David Robinson, and its been going on for about a year.
> I think we should leave it alone, until we real flaw is 
> proven by experiment.
 
I think Gedanken experiments should count, if the results
are clear.  There is no point in implementing something that
has problems, if we can anticipate those problems.

I'm not sure if these count as "objections" to the locking
protocol but I have raised the following issues (none 
really major), which I think are still ourstanding and need 
to be resolved, whether by a rebuttal from David Robinson 
proving that I'm all wet, or in some other way:

     Unbounded storage for lockowner data structures on the
     server (for seqid's):
     
          http://playground.sun.com/pub/nfsv4/nfsv4-wg-archive/1842.html

     My proposed clarification of Section 8.6:

          http://playground.sun.com/pub/nfsv4/nfsv4-wg-archive/1847.html

     Issues of changing stateid's interacting with IO requests 
     in-flight and the implications for the set of stateid-related
     errors to be returned:

          http://playground.sun.com/pub/nfsv4/nfsv4-wg-archive/1847.html

     Conflict between sequence mismatches being "ignored silently"
     and COMPOUND:

          http://playground.sun.com/pub/nfsv4/nfsv4-wg-archive/1843.html

There's also a few possible issues that have been discussed recently  
that relate to the locking protocol for which David Robinson's input
might help dispel my uneasy feelings about the details of what is 
currently in the spec:

      The whole open-upgrade-downgrade vs. multiple opens for the
      same lockowner-file pair confusion.

      The issue of lockowners and how they are affected by UNIX
      fork's.

      The semantics of revocation and how the spec should address
      the issue of whether it is meaningful to revoke a one of
      set of locks held on a file by a single lockowner.

There may be a small set of other such issues that I've forgotten.

---

From: Mike Eisler <[email-masked]>
Date: Thu, 4 Nov 1999 07:48:28 -0800 (PST)

> are clear.  There is no point in implementing something that

There's plenty of point in prototyping it, and I find I learn more
about protocols and discover flaws, by implementing. Often the
hard problems turn out to be easier than thought, and the so called
easy problems turn out to be nasty.

> has problems, if we can anticipate those problems.

It's better than NLM.

> [...] which I think are still ourstanding and need 

Yes I'd like to David R. respond to these too.

	-mre