Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!news.ecn.uoknor.edu!feed1.news.erols.com!insync!www.nntp.primenet.com!nntp.primenet.com!news.mathworks.com!EU.net!news2.EUnet.fr!newsbr.eunet.fr!usenet From: Frederic.Marand@osinet.fr (Frederic MARAND) Newsgroups: comp.unix.bsd.freebsd.misc Subject: Re: nfs over SLIP Date: Thu, 24 Oct 1996 07:10:02 GMT Organization: Groupe SEDI / Agorus SA / OSI SARL Lines: 73 Message-ID: <54n803$468@newsbr.eunet.fr> References: <54l4mg$7r4@ccioffe.ioffe.rssi.ru> NNTP-Posting-Host: 193.107.196.155 X-Newsreader: Forte Free Agent 1.0.82 hill@fl.ioffe.rssi.ru (Andrey Y. Khilko) wrote: >Gentlemen, sharing your experience shall be appreciated greatly. >FBSD 2.1.0 <- SLIP over dedicated phone line -> FBSD 2.1.0 >After mounting a remote filesystem its root directory seems to be OK >while the subdirectories look empty. It looks like the problem is at >the nfs server site. >Andrey Khilko To get more precise information, without starting debugging the NFS code, you could try using nfsstat. 1. on client, umount all NFS FSes. 2. on server, nfsstat -z. This will reset all RPC counters 3. on client, mount root. Let's assume you mount it on /server. 4. on client, ls -l /server 5. on server nfsstat -s. What you should see is the readdir call count increment to a small integer number, depending on the number of entries in your / directory. If it does not, the problem is at this early stage. 6. the getattr call count should be equal to the number of entries in the servers / directory: ls -l needs to perform nfs_getattr on each entry it reeceives from nfs_readdir. If it is higher, then the client implementation behaves strangely. If it is lower, it is even stranger, since it needs this information. 7. At any rate, nfsstat -c on the client will give you the number and nature of calls performed. If they differ, the problem is a communication one, not an NFS one. 8. Supposing /etc is not a different FS on the server, but belongs to the / fileserver, perform a ls -l /server/etc/inittab from the client. 9. nfsstat -s on server should get your lookup count table to 1, since the client needs to get a nfshandle for /etc. The getattr count should also increment by one, and no other NFS level counters should be modified. To sum things up, if the call count on both server and client is consistent and you get logic errors, the problem is probably with the NSF part. If the call count is too low on NFS primitives, and shows discrepancies between client and server, the problem probably comes from the underlying communication layer. If you get the counters consistent on client and server at the RPC layer and the NFS counters disagree, you probably get erroneous datagrams at this layer, which may mean a bug in the RPC/XDR code. Regarding SLIP, NFS works on it, as well on RPC/XDR (standard NFS) than on DPF/RSC (our own RPC layer, a bit faster) or HP/Apollo NCS (another RPC), but there are at least two issues: 1. SLIP does not resynchronize well on missing of erroneous bytes, so retransmission delays, coupled with the slow serial line speed may cause problems in the RPC and NFS timing constraints. 2. The MTU on SLIP is normally 576 bytes, but some NFS implementations try to get larger datagrams to minimize RPC overhead. 1500 bytes is common on Ethernet and spares two RPC calls out of three, but UDP datagrams are not usually subject to IP fragmentation, so such requests would fail, and your bad format RPC counters in nfsstat should increment accordingly. This is all I can say, but as a final note keep in miind these are considerations based on our experience with implementing NFS on other Unixes, not on the FreeBSD code I've never seen yet. ------------------------- Frederic G. MARAND Agorus SA / OSI SARL Frederic.Marand@osinet.fr -------------------------