Subject: RE: LOOKUP vs OPEN in NFSV4

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 20 Jul 2001 11:54:48 -0700

So far we've explained,

     zero-stateid on read -- this is for a browser-type use
     but it is subject to normal locking constraints.

     all-one-stateid on read -- This is for people who want
     to avoid "Those ^%&%#% Windows locks".
   
This leaves,

     zero stateid on write -- which is defined as subject to
     locking constraints.

     all-ones-stateid on write -- about which the spec is unclear
     (or I'm confused, or both).

As not accounted for.

Reading 8.1.4 closely, the first paragraph says that zero-stateids
are subject to conflicting locks and I assume that includes both 
share reservations and byte-range locks (I assume the latter only 
if they are mandatory but the spec doesn't say).  Also, in the 
penultimate sentence of the first paragraph, it says an error is
returned if there is a conflict with an "explicit lock".  What's
an implicit lock?  To top it off the last sentence of the paragraph
reads "This allows 'mandatory locking' to be implemented."
Any guess on what the referrent for "this" is in that sentence?

The next paragraph talks about stateid of all ones.  It says that
READ operations bypass *record* locking checks on the server (my
emphasis).  So do they bypass share reservations locks?  The 
implication is that they don't.  But why?  Generally, the poeple
who complain about Windows locks stopping them from accessing a
file are complaining about share reservations rather than record
(i.e. byte-range) locks.

The next sentence says writes with stateid of all-ones do not
bypass record locking checks.  So what do they do?  Are they
equal to writes with state-id's of zero?

Finally (for those who haven't hit delete yet), there is the 
issue of special stateid's and the grace period.

     "During the grace period, the server must reject READ and
      WRITE operations".

It doesn't seem to make an exception for special stateid's.

The next paragraph does make an exception if the server can relaibly
determine that there will be no confict.  This seeems like it is
an out for special stateids (at least for reads with state of all-ones),
but the text would have to be tweaked, since the server cannot be
sure there will be no conflict, but instead is normally asked to
grant the read requiest, despite any conflict.

Special stateids are a very big very special headache :-(

-----Original Message-----
From: Brent [mailto:[email-masked]]
Sent: Friday, July 20, 2001 3:26 AM
To: [email-masked]
Subject: Re: LOOKUP vs OPEN in NFSV4

Martin Pool wrote:
> If all the clients were using NFSv4 then there would be no back door
> for the Unix clients to avoid the locks, which would cause problems
> with (say) tarring up a directory while Windows clients are using it.
> In short, since the two systems use locking so differently, you need
> the protocol to at least have the possibility of a back door.
> 
> I'd be interested to hear if this is the scenario Brent & co had in
> mind when they added the special stateids.

David Robinson came up with the special stateids.  
Yes, I believe their intent was to preserve file
access behavior that UNIX users are accustomed to.

   $ cat foo
   Resource temporarily unavailable
   $ %&@*$!

	Brent

---

From: Mike Kupfer <[email-masked]>
Date: Sat, 28 Jul 2001 16:00:32 -0700

> This leaves,
...
>      (or I'm confused, or both).

Section 8.1.4 says this case does not bypass record locking checks.

> an implicit lock?  

I believe "implicit lock" refers to the server's wrapping a READ or
WRITE in a lock to insure atomicity.  See the very last sentence of
Section 8.1.4.

> To top it off the last sentence of the paragraph

I assumed it refers to the lock checking that happens when an all-0
stateid is used.

> file are complaining about share reservations rather than record

I dug through my archives, including some 1998 Sun-internal mail that
led up to David Robinson's locking proposal, which is the basis for
the current scheme.

It looks like the idea was that Windows clients would use an all-0
stateid, which would mean "I don't have any locks, I want to do I/O,
please honor record locks and share reservations", since Windows apps
expect mandatory locking semantics.  Unix clients would use an all-1
stateid, which would mean "I don't have any locks, I want to do I/O,
please don't honor any locks or share reservations", since Unix apps
expect advisory locking semantics.  We then modified the all-1 stateid
so that reads could bypass locks, but writes couldn't.

And at some point during the life of the spec we tried to tighten up
the locking-related language, to clearly distinguish share
reservations from record locking.  In a few places I suspect we
(accidentally) changed the meaning from "shares and record locks" to
"record locks only".

So, to answer Dave's question, I think that the current text in
Section 8.1.4 should be changed.  A READ with an all-1 stateid should
bypass both record locks and share reservations, and a WRITE with an
all-1 stateid is equivalent to a WRITE with an all-0 stateid.

> It doesn't seem to make an exception for special stateid's.

I suspect the logic here is that the server has to recover
delegations.  So rejecting all I/Os, independent of the stateid, is
the safest course.

mike