On Jan 16, 2014, at 6:31 AM, ranjith ruban <ranjithruban@xxxxxxxxx> wrote:
> Hello
>
> I had set nfs mount actiomeo option for 300 seconds for a share. The
> client is an openvz server with container filesystems in nfs . Server
> is netapp.
>
> While going through the tcpdump i see below
>
> 125 2014-01-15 16:06:01.770522 10.X.0.X 10.X.0.X NFS
> 190 V3 GETATTR Call (Reply In 126), FH: 0x496fe5c5
> 126 2014-01-15 16:06:01.770637 10.X.0.X 10.X.0.X NFS
> 182 V3 GETATTR Reply (Call In 125) Regular File mode: 0644 uid:
> 0 gid: 0
>
> this call returns file id 2691421
>
> find /vz/private/X/ -inum 2691421 -exec ls -l {} \;
> -rw-r--r-- 1 root root 1128 Jul 14 2011 /vz/private/X/fs/root/etc/passwd
>
> Now after a minute i do see the same call again to same file handle.
>
> 294 2014-01-15 16:07:01.771152 10.X.0.X 10.X.0.X NFS
> 190 V3 GETATTR Call (Reply In 295), FH: 0x496fe5c5
> 295 2014-01-15 16:07:01.771261 10.X.0.X 10.X.0.X NFS
> 182 V3 GETATTR Reply (Call In 294) Regular File mode: 0644 uid: 0
> gid: 0
>
> mount options
> # 10.X.0.X:/vol/vz2/private on /vz/private type nfs
> (rw,noatime,nodiratime,soft,timeo=60,nfsvers=3,retrans=2,rsize=8192,wsize=8192,actimeo=300,addr=10.X.0.X)
>
> why does this happens with actimeo=300 . The second call in 1 minute
> should be answered from cache is it ?. Can some tuning be done to
> reduce this?.
With NFSv3, open(2) on the client results in an on-the-wire GETATTR, independent of the freshness of the file’s attribute cache. See “DATA AND METADATA COHERENCE” in the nfs(5) man page.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
