All of lore.kernel.org
 help / color / mirror / Atom feed
From: Diego Moreno <Diego.Moreno-Lazaro@bull.net>
To: linux-nfs@vger.kernel.org
Subject: NFSv3 caching vs NFSv4
Date: Wed, 05 Sep 2012 14:40:56 +0200	[thread overview]
Message-ID: <50474858.1020801@bull.net> (raw)

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.

Regards,

Diego Moreno

             reply	other threads:[~2012-09-05 13:03 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-05 12:40 Diego Moreno [this message]
2012-09-05 14:49 ` NFSv3 caching vs NFSv4 Myklebust, Trond
2012-09-05 17:21   ` J. Bruce Fields
2012-09-06  8:17     ` Diego Moreno

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50474858.1020801@bull.net \
    --to=diego.moreno-lazaro@bull.net \
    --cc=linux-nfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.