[nfsv4] Asking for details about OPEN_DOWNGRADE

[Spencer Shepler]

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