[Spam-fortigate] Re: NFSv4 client's BUG?

[Wei Yongjun]

J. Bruce Fields wrote:
> On Wed, Jul 16, 2008 at 03:05:41PM -0400, Trond Myklebust wrote:
>   
>> On Wed, 2008-07-16 at 14:48 -0400, J. Bruce Fields wrote:
>>     
>>> On Wed, Jul 16, 2008 at 04:02:32PM +0800, Wei Yongjun wrote:
>>>       
>>>> J. Bruce Fields wrote:
>>>>         
>>>>> On Mon, Jul 14, 2008 at 10:03:01AM +0800, Wei Yongjun wrote:
>>>>>   
>>>>>           
>>>>>> J. Bruce Fields wrote:
>>>>>>             
>>>>>>> So, is the problem occuring because the client is doing a setattr to
>>>>>>> modify the size using a sequence id returned from a read delegation?
>>>>>>>
>>>>>>>         
>>>>>>>               
>>>>>> This happend in special case:
>>>>>>
>>>>>> OPEN (OPEN4_SHARE_ACCESS_BOTH)    --->                                
>>>>>>      <---      OPEN Reply OK
>>>>>> SETATTR (size=0)                  --->
>>>>>> OPEN (OPEN4_SHARE_ACCESS_READ)    --->
>>>>>>                                     <---      SETATTR Reply NFSERR_OPENMODE
>>>>>>                                     <---      OPEN Reply OK
>>>>>>     
>>>>>>             
>>>>> Can you see which stateid the SETATTR was done with (in particular,
>>>>> where did it come from)?  (You could just send me a link to the raw
>>>>> capture if you'd like).
>>>>>
>>>>>   
>>>>>           
>>>> The file in this mail is a small tcpdump file of this error, the  
>>>> NFSERR_OPENMODE is the NO.298 packet.
>>>>         
>>> Yes, so the stateid used on the setattr represents a read delegation,
>>> and was returned in packet 291.  I think that's a client bug.
>>>       
>> You're saying that the client is holding a read delegation while it is
>> holding the file open for OPEN4_SHARE_ACCESS_BOTH???
>>     
>
> I'm having a hard time with the ietf mail archives, but my memory was
> that people agreed that:
> 	- 3530 wasn't completely clear as to whether a read delegation
> 	  necessarily conflicted with writes from the client holding the
> 	  read delegation, and
> 	- nobody could see a reason why they needed to, so
> 	- 4.1 explicitly says they don't conflict in this case.
>
> So I think it is a case the client should handle.
>
>   
>> The client may indeed be handling that situation strangely,
>> but afaics there would
>> definitely appear to be a bug here on the server side.
>>     
>
> That said, the Linux server definitely does recall delegations in this
> situation.  What version of the server was this seen with?
>   

The Server version is kernel-2.6.18-92.el5.  client is 2.6.26-rc6. The 
error happend in the following case.
Server kernel-2.6.18-92.el5, client 2.6.26-rc6        <-- fopen() error 
NFSERR_OPENMODE
Server 2.6.26-rc6, client kernel-2.6.18-92.el5        <--  fopen() error 
NFSERR_OPENMODE
Server 2.6.26-rc6, client 2.6.26-rc6                       <--  cat 
return ""