[nfsv4] Asking for details about OPEN_DOWNGRADE

[Spencer Shepler]

On Jun 13, 2008, at 4:55 PM, Trond Myklebust wrote:

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

Maybe a better way to phrase this is that no implementation should
be assumed correct until there is a consensus of interpretation within
the working group.

Spencer