[nfsv4] Asking for details about OPEN_DOWNGRADE

[Spencer Shepler]

On Jun 13, 2008, at 3:43 PM, J. Bruce Fields wrote:

> On Fri, Jun 13, 2008 at 03:18:41PM -0500, Spencer Shepler wrote:
>>
>> On Jun 13, 2008, at 3:10 PM, Noveck, Dave wrote:
>>
>>>> Go ahead and have the server enforce the correct behavior and
>>>> maybe the Solaris client will eventually be fixed.
>>>
>>> But the server vendor's customers may be rather annoyed in the
>>> interim.
>>
>> Sure but without a little pressure it won't get fixed.  We can fix
>> it in the development release but the changes will likely not be  
>> pushed
>> to previous releases without the pressure....
>
> The linux server has been enforcing this for a long time, for what  
> it's
> worth.  I vaguely recall this catching bugs in a few clients at  
> testing
> events before (don't remember which clients), but assumed they were
> fixed....
>
> Should the linux server turn this checking *off* for 4.0?  There's

No. It should remain as is.

Spencer

> really no other reason for it than "maybe we'll need this restriction
> some day, so let's try to make sure we complain to clients violating
> it."
>
> --b.
>
>>
>>>
>>>> The scenario that produces the behavior is a little off the beaten
>>>> path so I doubt it will arise that much but putting pressure
>>>> on the implementations to correct themselves is a good thing.
>>>
>>> With v4.1, the pressure can be put on the client implementations  
>>> from
>>> the beginning.  If the servers all check this, then v4.1 clients  
>>> will
>>> have to correct themselves as part of implementing v4.1, which  
>>> would be
>>> a good thing.
>>
>> I agree -- good intentions and hope for the best...
>>
>> Spencer
>>
>>>
>>> -----Original Message-----
>>> From: Spencer Shepler [mailto:Spencer.Shepler at Sun.COM]
>>> Sent: Friday, June 13, 2008 3:38 PM
>>> To: J. Bruce Fields
>>> Cc: nfsv4 at linux-nfs.org; nfsv4 at ietf.org; philippe.deniel at cea.fr
>>> Subject: Re: [nfsv4] Asking for details about OPEN_DOWNGRADE
>>>
>>>
>>>
>>> On Jun 13, 2008, at 2:20 PM, J. Bruce Fields wrote:
>>>
>>>> On Fri, Jun 13, 2008 at 10:33:15AM -0700, Mike Mackovitch wrote:
>>>>> On Fri, Jun 13, 2008 at 10:03:29AM -0700, eric kustarz wrote:
>>>>>>
>>>>>> On Jun 13, 2008, at 9:49 AM, Mike Mackovitch wrote:
>>>>>>
>>>>>>> On Fri, Jun 13, 2008 at 08:01:03AM -0400, Trond Myklebust wrote:
>>>>>>>> On Fri, 2008-06-13 at 11:23 +0200, philippe.deniel at cea.fr  
>>>>>>>> wrote:
>>>>>>>>>     The
>>>>>>>>>    share_access and share_deny bits specified must be exactly
>>>>>>>>> equal to
>>>>>>>>>    the union of the share_access and share_deny bits specified
>>>>>>>>> for some
>>>>>>>>>    subset of the OPENs in effect for current openowner on the
>>>>>>>>> current
>>>>>>>>>    file.
>>>>>>>>
>>>>>>>> It basically means that in order to be allowed to downgrade to
>>>>>>>> OPEN4_SHARE_ACCESS_READ|OPEN4_SHARE_DENY_NONE, then at least
>>>>>>>> one of
>>>>>>>> the
>>>>>>>> OPENs that made up the previous stateid must have been of that
>>>>>>>> type.
>>>>>>>
>>>>>>> What's strange is that it appears that only Linux seems to think
>>>>>>> this is the case.  I can't figure out (1) why they think it must
>>>>>>> work this restrictively (my best guess is that the phrase
>>>>>>> "OPENs in
>>>>>>> effect" is being misinterpreted as "OPENs sent to the server"),
>>>>>>> and
>>>>>>> (2) why they haven't bothered/managed to convince the rest of  
>>>>>>> the
>>>>>>> NFSv4 community of this (and get the spec updated).
>>>>>>>
>>>>>>>> IOW: you cannot just do
>>>>>>>>
>>>>>>>>        OPEN(OPEN4_SHARE_ACCESS_BOTH|OPEN4_SHARE_DENY_NONE)
>>>>>>>>        OPEN_DOWNGRADE(OPEN4_SHARE_ACCESS_READ|
>>>>>>>> OPEN4_SHARE_DENY_NONE) = NFS4ERR_INVAL
>>>>>>>
>>>>>>> This works fine on Solaris server - and the Solaris client
>>>>>>> even behaves exactly this way.
>>>>>>
>>>>>> Yeah, we've got some bugs to fix in this area:
>>>>>> NFSv4 client can send a bogus OPEN_DOWNGRADE
>>>>>> http://bugs.opensolaris.org/view_bug.do?bug_id=4877567
>>>>
>>>> Where are the comments, by the way?  (How hard is it to make the
>>>> client
>>>> do this?)
>>>>
>>>>>>
>>>>>> NFSv4 server should deny bogus OPEN_DOWNGRADE
>>>>>> http://bugs.opensolaris.org/view_bug.do?bug_id=4877573
>>>>>
>>>>> Hmmm...if that's really the agreed upon behavior, I must say it's
>>>>> quite
>>>>> a shame that nobody bothered to fix the spec - not even in  
>>>>> NFSv4.1.
>>>>
>>>> NFSv4.1 actually expands on this a bit:
>>>>
>>>>    After checking for valid values of share_access and share_deny,
>>>> the
>>>>    server replaces the current access and deny modes on the file  
>>>> with
>>>>    share_access and share_deny subject to the following  
>>>> constraints:
>>>>
>>>> 	o  The bits in share_access SHOULD equal the union of the
>>>> 	share_access bits (not including OPEN4_SHARE_WANT_* bits)
>>>> 	specified for some subset of the OPENs in effect for the current
>>>> 	open-owner on the current file.
>>>>
>>>> 	o  The bits in share_deny SHOULD equal the union of the
>>>> 	share_deny bits specified for some subset of the OPENs in effect
>>>> 	for the current open-owner on the current file.
>>>>
>>>>    If the above constraints are not respected, the server SHOULD
>>>> return
>>>>    the error NFS4ERR_INVAL.
>>>>
>>>>> Also, the fact that the Solaris bugs have been around for five  
>>>>> years
>>>>> makes it seem like they'll never be fixed.
>>>>
>>>> But, yeah, it's unfortunate if a server has to ignore the final
>>>> SHOULD
>>>> above in order to interoperating with any existing Solaris client.
>>>
>>> Go ahead and have the server enforce the correct behavior and
>>> maybe the Solaris client will eventually be fixed.
>>>
>>> The scenario that produces the behavior is a little off the beaten
>>> path so I doubt it will arise that much but putting pressure
>>> on the implementations to correct themselves is a good thing.
>>>
>>> Spencer
>>> _______________________________________________
>>> nfsv4 mailing list
>>> nfsv4 at ietf.org
>>> https://www.ietf.org/mailman/listinfo/nfsv4
>>
> _______________________________________________
> nfsv4 mailing list
> nfsv4 at ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4