Re: NFSv3 caching vs NFSv4

[Diego Moreno <Diego.Moreno-Lazaro@bull.net>]

Ok, so this is a delegation bug. I think you're rigth Bruce, I cannot 
see the bug if I just modify the file with vi.

I'll try your delegation patch ASAP.

Thanks,

Diego

On Wed 05 Sep 2012 07:21:58 PM CEST, J. Bruce Fields wrote:
> On Wed, Sep 05, 2012 at 02:49:18PM +0000, Myklebust, Trond wrote:
>> On Wed, 2012-09-05 at 14:40 +0200, Diego Moreno wrote:
>>> Hello everyone,
>>>
>>> Performing some attribute caching tests I think I found some
>>> inconsistencies between nfsv3 and nfsv4. Running a kernel based on
>>> rhel6.3 (2.6.32-279.el6.x86_64) I found nfsv4 doesn't manage a file
>>> modified on the server side (even with the noac mount option) while
>>> nfsv3 does.
>>>
>>> My test will be modifying a file every second on the server mount point:
>>>
>>> [root@nfs ~]#  FILE=/tmp/nfs_server/myfile ;  while true ; do sleep 1 ;
>>> sed -i 's/text1/text2/g' $FILE ; cat $FILE ; sleep 1; sed -i
>>> 's/text2/text1/g' $FILE ; cat $FILE ; done
>>> text2
>>> text1
>>> text2
>>> text1
>>> text2
>>> (and so on...)
>>>
>>> Meanwhile, the client (which BTW is the same machine) will read the file
>>> every second :
>>>
>>> With NFSv4:
>>>
>>> [root@nfs ~]# mount -o noac,vers=4 nfs:/tmp/nfs_server/ /tmp/nfs_client/
>>> [root@nfs ~]# for i in 1 2 3 4 5 ; do cat /tmp/nfs_client/myfile; sleep
>>> 1 ; done
>>> text2
>>> text1
>>> text1
>>> text1
>>> text1
>>>
>>> With NFSv3:
>>> [root@nfs ~]# mount -o noac,vers=3 nfs:/tmp/nfs_server/ /tmp/nfs_client/
>>> [root@nfs ~]# for i in 1 2 3 4 5 ; do cat /tmp/nfs_client/myfile; sleep
>>> 1 ; done
>>> text1
>>> text2
>>> text1
>>> text2
>>> text1
>>>
>>> I can see in the tcpdump traces how the new change attribute and the
>>> FATTR4_TIME_MODIFY attributes are well received but it's as if the nfs
>>> client were ignoring these changes. I've been searching in the NFS list
>>> but I didn't find anything similar. Is this a bug or just a normal
>>> behavior? Sorry if it has been already pointed out.
>>
>> ]If you can reproduce the same issues on the upstream kernel, then it is
>> on topic for this list, otherwise it is a question for Red Hat.
>
> I believe sed -i is actually doing a rename not a file modification.  So
> the problem is likely another symptom of the bug that delegations aren't
> revoked on rename/link/unlink.  Hoping to post the latest draft of
> patches to fix that later today.
>
> --b.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html