[nfsv4] Asking for details about OPEN_DOWNGRADE

[Noveck, Dave]

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

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

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