hello list.
I have some question how to work of linux nfs client cache.
I was proceeding two test.
One is solaris 9 client with linux server.
The other is linux client with linux server.
Linux server and client kernel version is 2.4.27.
nfs-util version is 1.0.4.
[ mount option list ]
Linux server export option is rw,async.
Linux client mount optione is just actimeo=0.
Another linux client mount option is actimeo=100.
Solaris9 mount option is soft,xattr,rw.
[ linux client setting ]
192.168.1.212:/vol1 /mnt1 nfs rw,v3,rsize=8192,wsize=8192,acregmin=0,acregmax=0,acdirmin=0,acdirmax=0,hard,udp,lock,addr=192.168.1.212 0 0
192.168.1.212:/vol1 /mnt nfs rw,v3,rsize=8192,wsize=8192,acregmin=100,acregmax=100,acdirmin=100,acdirmax=100,hard,udp,lock,addr=192.168.1.212 0 0
[ Solaris 9 test ]
2 solaris 9 clients ----> linux server.
After i touch a file on one solaris client, I type ls -al the file on the other solaris client.
And i found that the file attribute(mtime) was updated randomly.(0 sec ~ 30sec)
The solais9 client is my customer machine.
My client want that the file attribute update interval is to 0 sec.
So I recommand to check nfs mount option in solaris 9 ( actimeo, acregXXX...).
[ linux client test ]
Test procedure is same with solaris9.
But, resut is not same.
Linux client shows up-to-dated file attribute.
As I know, linux nfs client default mount option is acregmin is 3.
So i change the mount option to actimeo=100.
But result is not different.
So I wonder that actimeo option is a available.
i tried tcpdump.
when mount option is actimeo=0 ( in linux client)
linux-client> ls -al /mnt/test.test
linux-client>-rwxrwxrwx 1 root root 12 Apr 29 16:59 /mnt/test.test
linux-server tcpdump output
-----------------------------------------------------------
18:51:52.561558 GRVC-C.4105878944 > 192.168.1.212.nfs: 120 access [|nfs] (DF)
18:51:52.561588 192.168.1.212.nfs > GRVC-C.4105878944: reply ok 120 access c 0000 (DF)
18:51:52.561683 GRVC-C.4122656160 > 192.168.1.212.nfs: 132 getattr [|nfs] (DF)
18:51:52.561759 192.168.1.212.nfs > GRVC-C.4122656160: reply ok 112 getattr REG 100777 ids 0/0 [|nfs] (DF)
-------------------------------------------------------------
when mount option is actimeo=100 ( in linux client)
linux-client> ls -al /mnt1/test.test
linux-client>-rwxrwxrwx 1 root root 12 Apr 29 16:59 /mnt/test.test
linux-server tcpdump output
-------------------------------------------------------------
18:55:37.860627 GRVC-C.4189765024 > 192.168.1.212.nfs: 120 access [|nfs] (DF)
18:55:37.860694 192.168.1.212.nfs > GRVC-C.4189765024: reply ok 120 access c 0000 (DF)
18:55:37.860874 GRVC-C.4206542240 > 192.168.1.212.nfs: 116 getattr [|nfs] (DF)
18:55:37.860932 192.168.1.212.nfs > GRVC-C.4206542240: reply ok 112 getattr DIR 40777 ids 99/99 [|nfs] (DF)
18:55:37.861123 GRVC-C.4223319456 > 192.168.1.212.nfs: 132 getattr [|nfs] (DF)
18:55:37.861147 192.168.1.212.nfs > GRVC-C.4223319456: reply ok 112 getattr REG 100777 ids 0/0 [|nfs] (DF)
18:55:37.861373 GRVC-C.4240096672 > 192.168.1.212.nfs: 132 getattr [|nfs] (DF)
18:55:37.861387 192.168.1.212.nfs > GRVC-C.4240096672: reply ok 112 getattr REG 100777 ids 0/0 [|nfs] (DF)
-------------------------------------------------------------
As you see, two more getattr appeared in actimeo=100.
linux nfs client code seems different by actimeo option.
but I can't verify the affect of nfs client cache . ( aspect of file attribute cacheing)
anybody help me?
How can i verify the affect of nfs client cache.
sorry poor my english.
On Mon, May 02, 2005 at 07:49:43PM +0900, =EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=
=BD=C7=A5 wrote:
> hello list.
> I have some question how to work of linux nfs client cache.
>=20
> I was proceeding two test.
> One is solaris 9 client with linux server.
> The other is linux client with linux server.
>=20
> Linux server and client kernel version is 2.4.27.
> nfs-util version is 1.0.4.
>=20
> [ mount option list ]
> Linux server export option is rw,async.
> Linux client mount optione is just actimeo=3D0.
> Another linux client mount option is actimeo=3D100.
> Solaris9 mount option is soft,xattr,rw.
>=20
> [ linux client setting ]
> 192.168.1.212:/vol1 /mnt1 nfs rw,v3,rsize=3D8192,wsize=3D8192,acregmin=3D=
0,acregmax=3D0,acdirmin=3D0,acdirmax=3D0,hard,udp,lock,addr=3D192.168.1.2=
12 0 0
> 192.168.1.212:/vol1 /mnt nfs rw,v3,rsize=3D8192,wsize=3D8192,acregmin=3D=
100,acregmax=3D100,acdirmin=3D100,acdirmax=3D100,hard,udp,lock,addr=3D192=
.168.1.212 0 0
>=20
> [ Solaris 9 test ]
> 2 solaris 9 clients ----> linux server.=20
>=20
> After i touch a file on one solaris client, I type ls -al the file on t=
he other solaris client.
> And i found that the file attribute(mtime) was updated randomly.(0 sec =
~ 30sec)
> The solais9 client is my customer machine.
> My client want that the file attribute update interval is to 0 sec.
> So I recommand to check nfs mount option in solaris 9 ( actimeo, acregX=
XX...).
>=20
> [ linux client test ]
>=20
> Test procedure is same with solaris9.
> But, resut is not same.
> Linux client shows up-to-dated file attribute.
> As I know, linux nfs client default mount option is acregmin is 3.
> So i change the mount option to actimeo=3D100.
> But result is not different.
> So I wonder that actimeo option is a available.
> i tried tcpdump.
>=20
You're probably seeing the close-to-open cache consistency mechanism work=
ing.
Every time a file is closed on a linux system (with no outstanding open f=
d's,
IIRC), a setattr transaction is sent to the server to update file metadat=
a. On
every file open (if there are no already open fd's, IIRC), a getattr tran=
saction
is sent to the server to get the latest file metadata on the server. Thi=
s is
probably why it seems that the attribute cache timeouts aren't working li=
ke you
would expect. To get a clearer view of how they operate, moun the linux =
clients
using the nocto nfs mount option. Of course, I wouldn't recommend doing =
this,
as it provides better consistency between nfs nodes, but it will make the=
ac*
options work a little more like you might expect.
Regards
Neil
> when mount option is actimeo=3D0 ( in linux client)
> linux-client> ls -al /mnt/test.test=20
> linux-client>-rwxrwxrwx 1 root root 12 Apr 29 16:59 /m=
nt/test.test
>=20
> linux-server tcpdump output
> -----------------------------------------------------------
> 18:51:52.561558 GRVC-C.4105878944 > 192.168.1.212.nfs: 120 access [|nfs=
] (DF)
> 18:51:52.561588 192.168.1.212.nfs > GRVC-C.4105878944: reply ok 120 acc=
ess c 0000 (DF)
> 18:51:52.561683 GRVC-C.4122656160 > 192.168.1.212.nfs: 132 getattr [|nf=
s] (DF)
> 18:51:52.561759 192.168.1.212.nfs > GRVC-C.4122656160: reply ok 112 get=
attr REG 100777 ids 0/0 [|nfs] (DF)
> -------------------------------------------------------------
>=20
> when mount option is actimeo=3D100 ( in linux client)
> linux-client> ls -al /mnt1/test.test=20
> linux-client>-rwxrwxrwx 1 root root 12 Apr 29 16:59 /m=
nt/test.test
>=20
> linux-server tcpdump output
> -------------------------------------------------------------
> 18:55:37.860627 GRVC-C.4189765024 > 192.168.1.212.nfs: 120 access [|nfs=
] (DF)
> 18:55:37.860694 192.168.1.212.nfs > GRVC-C.4189765024: reply ok 120 acc=
ess c 0000 (DF)
> 18:55:37.860874 GRVC-C.4206542240 > 192.168.1.212.nfs: 116 getattr [|nf=
s] (DF)
> 18:55:37.860932 192.168.1.212.nfs > GRVC-C.4206542240: reply ok 112 get=
attr DIR 40777 ids 99/99 [|nfs] (DF)
> 18:55:37.861123 GRVC-C.4223319456 > 192.168.1.212.nfs: 132 getattr [|nf=
s] (DF)
> 18:55:37.861147 192.168.1.212.nfs > GRVC-C.4223319456: reply ok 112 get=
attr REG 100777 ids 0/0 [|nfs] (DF)
> 18:55:37.861373 GRVC-C.4240096672 > 192.168.1.212.nfs: 132 getattr [|nf=
s] (DF)
> 18:55:37.861387 192.168.1.212.nfs > GRVC-C.4240096672: reply ok 112 get=
attr REG 100777 ids 0/0 [|nfs] (DF)
> -------------------------------------------------------------
>=20
> As you see, two more getattr appeared in actimeo=3D100.
>=20
> linux nfs client code seems different by actimeo option.
> but I can't verify the affect of nfs client cache . ( aspect of file at=
tribute cacheing)
>=20
> anybody help me?
> How can i verify the affect of nfs client cache.
> sorry poor my english.
--=20
/***************************************************
*Neil Horman
*Software Engineer
*Red Hat, Inc.
*[email protected]
*gpg keyid: 1024D / 0x92A74FA1
*http://pgp.mit.edu
***************************************************/
-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
m=C3=A5 den 02.05.2005 Klokka 19:49 (+0900) skreiv =EA=B9=80=EA=B2=BD=ED=91=
=9C:
> =20
> when mount option is actimeo=3D0 ( in linux client)
> linux-client> ls -al /mnt/test.test=20
> linux-client>-rwxrwxrwx 1 root root 12 Apr 29
> 16:59 /mnt/test.test
> =20
> linux-server tcpdump output
> -----------------------------------------------------------
> 18:51:52.561558 GRVC-C.4105878944 > 192.168.1.212.nfs: 120 access [|
> nfs] (DF)
> 18:51:52.561588 192.168.1.212.nfs > GRVC-C.4105878944: reply ok 120
> access c 0000 (DF)
> 18:51:52.561683 GRVC-C.4122656160 > 192.168.1.212.nfs: 132 getattr [|
> nfs] (DF)
> 18:51:52.561759 192.168.1.212.nfs > GRVC-C.4122656160: reply ok 112
> getattr REG 100777 ids 0/0 [|nfs] (DF)
> -------------------------------------------------------------
ACCESS caching in the 2.4. kernels was very experimental (in fact the
ACCESS patch was never applied to the mainline kernel) and could explain
why this is happening.
Cheers,
Trond
-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs