Help wanted : when does the NFSv4 client uses "all-0" stateid for OP_WRITE ?

[J. Bruce Fields]

On Fri, Jun 19, 2009 at 09:18:44AM +0200, DENIEL Philippe wrote:
> Trond, Bruce,
>
> Thanks you so much for your help, I think you get the faulty thing. :-)
> When OP_OPEN4 is used to open and create a file that already exists, no  
> error is returned if UNCHECKED4 mode is used. In this particular case, I  
> did not set the compound request's current FH, leaving the one from the  
> parent directory in place. That why the parent's attributes were used  
> later. I fixed this and ran the test again and now it works.

Ah-hah.

> This also helped me fixing another bug I had with lock management (in a  
> few cases, I could crash the client's kernel).

Have those crashes been reported?

--b.

> This disappeared as well  
> as I fix the previous issue. In nfs-ganesha's distribution, I have a  
> 'THANKS' file : you now have a dedicated place in it.
>
>    Philippe
>
> Trond Myklebust a écrit :
>> On Thu, 2009-06-18 at 15:07 +0200, DENIEL Philippe wrote:
>>   
>>> Hi,
>>>     
>>>> I can't think of any obvious reason--
>>>>       
>>> So do you... The OPEN4 is successful and no error is returned so I do 
>>> not understand why the stateid is not used.
>>>
>>>     
>>>> if you sent a network trace of the
>>>> whole exchange (from initial setclientid thruogh the open), I could try
>>>> taking a look.
>>>>       
>>> Here are 2 capture from wireshark
>>>      - capture4bruce.nfs-ganesha.mount.write : this is the capture 
>>> with nfs-ganesha (my NFSv4 server) with the wrong use of all-0 
>>> stateid
>>>     
>>
>> Err... According to that trace, you are returning the attributes of the
>> directory in the GETATTR immediately after the OPEN call. No wonder the
>> client is confused...
>>
>> Trond
>>
>>   
>