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

[J. Bruce Fields]

On Thu, Jul 17, 2008 at 04:45:42PM +0800, Wei Yongjun wrote:
> 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 ""

Which of those three cases was the trace you showed me from?  (One of
the first two, I guess?)

--b.