nfs and getattr

nfs and getattr

[J.A. Magallon]

A NFS client through 100Mb Ether takes a loooooooong time to read a database
from the server, which the server itself reads in less than 10 seconds.
The database is a scene description for render that basically 'includes'
the same small set of files (around 10) many times, instanced all over the
place...

Mount in client:
10.0.0.1:/home on /home type nfs (rw,nfsvers=2,noac,addr=10.0.0.1)

Looking at nfsstats in the server:
Server rpc stats:
calls      badcalls   badauth    badclnt    xdrcall
491811     0          0          0          0       
Server nfs v2:
null       getattr    setattr    root       lookup     readlink   
1       0% 429338 87% 0       0% 0       0% 61474  12% 26      0% 
read       wrcache    write      create     remove     rename     
963     0% 0       0% 1       0% 1       0% 0       0% 1       0% 
link       symlink    mkdir      rmdir      readdir    fsstat     
0       0% 0       0% 3       0% 0       0% 2       0% 0       0% 

Server nfs v3:
null       getattr    setattr    lookup     access     readlink   
1      100% 0       0% 0       0% 0       0% 0       0% 0       0% 
read       write      create     mkdir      symlink    mknod      
0       0% 0       0% 0       0% 0       0% 0       0% 0       0% 
remove     rmdir      rename     link       readdir    readdirplus
0       0% 0       0% 0       0% 0       0% 0       0% 0       0% 
fsstat     fsinfo     pathconf   commit     
0       0% 0       0% 0       0% 0       0% 

What is that ton of getattr ? Do they come from nfs itself or must be
done by the reader via stat()s (perhaps it checks for file presence before
opening) ?

Is there any way to speedup that ?
Will nfs-v3 perform better ?

TIA

(Kernel is a patched (only bugfixes and bproc) 2.4.21-pre5. No -aa included.)

-- 
J.A. Magallon <jamagallon@able.es>      \                 Software is like sex:
werewolf.able.es                         \           It's better when it's free
Mandrake Linux release 9.1 (Cooker) for i586
Linux 2.4.21-pre5-jam0 (gcc 3.2.2 (Mandrake Linux 9.1 3.2.2-3mdk))

Re: nfs and getattr

[J.A. Magallon]

On 03.18, J.A. Magallon wrote:
> A NFS client through 100Mb Ether takes a loooooooong time to read a database
> from the server, which the server itself reads in less than 10 seconds.
> The database is a scene description for render that basically 'includes'
> the same small set of files (around 10) many times, instanced all over the
> place...
> 
> Mount in client:
> 10.0.0.1:/home on /home type nfs (rw,nfsvers=2,noac,addr=10.0.0.1)
> 

More with a silly test:

#!/bin/bash

for i in $(seq 1000)
do
        cat $0 > /dev/null
done

annwn:~> time nfst
0.69user 1.49system 0:02.04elapsed 106%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (126416major+42508minor)pagefaults 0swaps
annwn:~> time bpsh 0 nfst
1.02user 1.86system 0:33.64elapsed 8%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (280major+30minor)pagefaults 0swaps

-- 
J.A. Magallon <jamagallon@able.es>      \                 Software is like sex:
werewolf.able.es                         \           It's better when it's free
Mandrake Linux release 9.1 (Cooker) for i586
Linux 2.4.21-pre5-jam0 (gcc 3.2.2 (Mandrake Linux 9.1 3.2.2-3mdk))

Re: nfs and getattr

[Trond Myklebust]

>>>>> " " == J A Magallon <J.A.> writes:

     > What is that ton of getattr ? Do they come from nfs itself or
     > must be done by the reader via stat()s (perhaps it checks for
     > file presence before opening) ?

See the fine Linux Kernel archives.

They come mainly from open(). Use the "nocto" option if you think you
can do without them, but *do not* do so if you think there might be
any chance whatsoever of 1 machine having to access a file that
another machine has written.

Cheers,
  Trond