[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: NFS mount very very slow



James Sinnamon wrote:

Dear Paulo et al,

On Sun, 27 Jun 2004 07:12 am, Paulo Silva wrote:
A Sex, 2004-06-25 às 12:25, James Sinnamon escreveu:
Dear list subscribers,

At first I thought my command:

 mount -t nfs 192.168.0.6:/etc /mnt/nfs

... had failed.  It seemed to have hanged.  I tried to kill it with
Ctrl^C, then with 'kill -SIGKILL <procid>', killing the Konsole tabbed
terminal ... but with no luck.

The process just would not die.

Eventually, I found, to my surprise, that that the 'mount' command
had not only withstood all my attempts to smother it, but it also
succeeded after all.  I don't know whether it took 15 minutes
or two hours, but whatever  the time lag was, it it had taken far too
long.  can anyone tell me how to work out what the problem could be?

The entry in 192.168.0.6:/etc/exports is:

 /etc  192.168.0.2(ro)

.... where 192.168.0.2 is the nfs client.
Do you have portmap running?

Yes, thank you:

 greenhouse:~# ps auxwww | grep portmap
 daemon     512  0.0  0.0  1604  544 ?    Ss   Jun26  0:00 /sbin/portmap

I am running rpc.mountd and rpc.nfsd with the --debug call flag set:

 greenhouse:~# ps uxwww | grep rpc.nfsd
 root 2428 0.0 0.0 1940  804 ? Ss 12:29  0:00 /usr/sbin/rpc.nfsd \
    --debug call

greenhouse:~# ps uxwww | grep rpc.mountd root 2421 0.0 0.0 1936 816 ? S 12:27 0:00 /usr/sbin/rpc.mountd \
   --debug call

This causes debug output, the meaning of which is not completely clear to me:

 greenhouse:/var/log# tail -25f debug
 Jun 27 12:30:45 greenhouse mountd[2421]: mnt [1 104/6/27 \
   12:29:45 moominvalley 0.0+0,1,2,3,4,6,10]
 Jun 27 12:30:45 greenhouse mountd[2421]: ^I/
 Jun 27 12:30:45 greenhouse mountd[2421]: ^Imount res = 0
 Jun 27 12:30:45 greenhouse nfsd[2428]: getattr [1 70/1/1 \
   12:47:12 moominvalley 0.0+0,1,2,3,4,6,10]
 Jun 27 12:30:45 greenhouse nfsd[2428]: ^I58800002 00
 Jun 27 12:30:45 greenhouse nfsd[2428]: result: 0
 Jun 27 12:30:45 greenhouse nfsd[2428]: statfs [1 70/1/1 \
   12:47:12 moominvalley 0.0+0,1,2,3,4,6,10]
 Jun 27 12:30:45 greenhouse nfsd[2428]: ^I/
 Jun 27 12:30:45 greenhouse nfsd[2428]: result: 0
 Jun 27 12:46:30 greenhouse nfsd[2428]: statfs [1 70/1/1 \
    13:02:57 moominvalley 1525.503+503,505,510]
 Jun 27 12:46:30 greenhouse nfsd[2428]: ^I/
 Jun 27 12:46:30 greenhouse nfsd[2428]: result: 0
 Jun 27 12:46:30 greenhouse nfsd[2428]: getattr [1 \
   70/1/1 13:02:57 moominvalley 1525.503+503,505,510]
 Jun 27 12:46:30 greenhouse nfsd[2428]: ^I/
 Jun 27 12:46:30 greenhouse nfsd[2428]: result: 0


It does show evidence of a 16 minute delay between the issuing of the command:

mount -t nfs 192.168.0.6:/ /mnt/nfs ... on the client host, 192.168.0.2(aka moominvalley), and the root file system of the server host (192.168.0.6 aka greenhouse) finally being mounted. The same happens regardless of what directoryI choose on the server machine.

Sun NFS lock manager(?) in kernel?
-----------------------------------------------------

My bootup script (/etc/init.d/nfs-common) causes /sbin/rpc.lockd to run, but /sbin/rpc.lockd seems to detect there already is an equivalent to lockd (Sun NFS lock manager NLM(?)) in the kernel, and so it ceases execution.

I have set /proc/sun/sunrpc/nlm_debug to "1" with no apparent effect?
So how can I verify that there is NLM in my kernel, and that it is working?
... and if NLM/lockd is working, what else could be slowing down
the NFS mounting of the server file systems?.

I didn't think to look here b4:
ns:~# lsmod
...
nfsd                  179776  1
exportfs                6496  1 nfsd
lockd                  63176  2 nfsd
sunrpc                138600  2 nfsd,lockd
....

Again, in case you forgot:
ns:~# uname -r
2.6.3-1-686
ns:~#
My startup script is nfs-kernel-server.



James
Do  you live in the Perth metro area? I'm in Bellevue.




--

Cheers
John

-- spambait
1aaaaaaa@computerdatasafe.com.au  Z1aaaaaaa@computerdatasafe.com.au



Reply to: