[nfsv4] Asking for details about OPEN_DOWNGRADE

[Trond Myklebust]

On Fri, 2008-06-13 at 14:43 -0700, Mike Mackovitch wrote:
> On Fri, Jun 13, 2008 at 04:58:17PM -0400, Trond Myklebust wrote:
> > On Fri, 2008-06-13 at 13:29 -0700, Mike Mackovitch wrote:
> > 
> > > By explicitly specifying that the behavior described above should not
> > > be allowed.  It is clear that the spec is NOT clear about that....
> > > otherwise, the spec wouldn't be getting "misinterpreted" by many people.
> > > 
> > > The text in the OPEN and OPEN_DOWNGRADE descriptions, as well as "Open
> > > Upgrade and Downgrade" sections, leads me (and others) to believe that
> > > the server only keeps one "OR"ed-together status for that owner and
> > > thus sending multiple, redundant OPEN requests (for that owner) was
> > > unnecessary.
> > 
> > I don't see how it can be interpreted that way.
> 
> Perhaps that's because you now have a different perspective?  :-)
> 
> Apparently the Linux NFS client also interpreted it incorrectly up 
> until a couple years ago (2.6.15).
> 
> > The texts in section
> > 8.11 and in 14.2.19 both take care to talk about a _union_ of the OPEN
> > share and deny modes and proper subsets of that union.
> 
> See my other responses regarding "in effect" vs. "particular ops sent
> to the server".

I agree with Bruce's reply: if the text had said open, then there might
be ambiguity, but it says OPEN, clearly referring to the op.

> > The pynfs test suite will even check for this condition, so there is not
> > much excuse for claiming ignorance.
> 
> Uhh, OK then ... I guess I'll just have to claim stupidity?
> After all, everyone knows you should never trust the Solaris NFS
> implementation to do things correctly.

That may have been the case back in the case of v2 and possibly v3, when
the "spec" was basically a description of the Solaris implementation,
but that was never the case for NFSv4. Neither is it the case for
NFSv4.1.

Trond