Dear John et al, (Firstly, sorry about the previous double posting. At first I posted using a different e-mail address to that under which I had been subscribed, so I resent it using the correct address.)
On Sun, 27 Jun 2004 01:53 pm, John Summerfield wrote: > 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. Thanks. I installed the kernel-server package, but it seems to still be just as slow. greenhouse:/var/log# lsmod | grep nfsd nfsd 61200 8 (autoclean) lockd 42544 1 (autoclean) [nfsd] sunrpc 58688 1 (autoclean) [nfsd lockd] (curiously, I don't see 'exportfs' in my modules, although /usr/sbin/exportfs exists. Is that an issue?) Maybe nfs-kernel-server has to be configured diffently? (I haven't thoroughly read up on it yet.) I am using a 2.4 kernel: 2.4.25-1-386. I am quite happy to upgrade if I were to feel confident that it would work correctly on my testing/sarge system, however I would have thought that nfs, whether run as a user process or somehow as part of the kernel, should still work whether it is with a 2.4 kernel or a 2.6 kernel. So essentially, I have not moved much further towards being able to find the cause to the problem or the solution. Any possible further suggestions? thanks again. regards, James -- James Sinnamon jps 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]