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?.
Thanks again,
James
--
James Sinnamon
sinnamon at westnet com auStralia
ph +61 412 319669, +61 2 95692123, +61 2 95726357
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
