[nfsv4] Asking for details about OPEN_DOWNGRADE

[J. Bruce Fields]

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