Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!goanna!escargot!otto!davidb From: davidb@otto.bf.rmit.oz.au (David Burren [Athos]) Newsgroups: comp.os.386bsd.bugs Subject: Re: BUG IN NFS CLIENT ON NETBSD Message-ID: <davidb.737781550@otto> Date: 19 May 93 03:19:10 GMT References: <1svfk1INNekr@darkstar.ucsc.edu> <1t2q60$rvg@lucy.ee.und.ac.za> Organization: Royal Melbourne Institute of Technology Lines: 80 NNTP-Posting-Host: otto.bf.rmit.oz.au In <1t2q60$rvg@lucy.ee.und.ac.za> barrett@lucy.ee.und.ac.za (Alan Barrett) writes: >In article <1svfk1INNekr@darkstar.ucsc.edu>, >buhrow@cats.ucsc.edu (Brian Buhrow) writes: >> Problem: When I try to nfs mount a filesystem from a remote fileserver, it >> mounts fine, but any sizable reads from that filesystem subsequent to the >> mount hang forever. >I had the same problem, also with an ne2000 ethernet card. I haven't >investigated closely, because my third attempt at fixing the problem >seems to have worked -- I have only one NFS mount, of a read-only >file system, and use the following flags: > ro,soft,intr,rsize=1024,wsize=1024,retry=5,retrans=5,timeo=5 >The "intr" and the >overrides for retry, retrans and timeo are left over from my first >failed attempt at fixing the problem, and are probably not relevant. Correct. >The "rsize=1024,wsize=1024" are there to make the system do smaller >reads and writes, because I think that the default size is too big for >the ne2000 to handle properly (but, as I said before, I have not >investigated closely). This seems to be the key. The default block size for NFS is 8k. Whether it will work or not is dependent on a number of factors in the client and the server. But it's worth noting that many PC Ethernet cards have a _total_ of 8k of RAM (used for transmit, receive, and some management overhead) and most current Ethernet drivers under 386bsd or NetBSD will only use 8k of RAM even if the board has 16. In cases where one i386 NetBSD machine mounts from another, I haven't had any problems so far using the default mount parameters. However, with various PCs using 3c503/WD8013/ne2000 cards, mounting from an Auspex NFS server will hang under load. In some cases the PC will just stop working, in others it will panic. Note that mounting from a DECstation can have similar results, but the Auspex seems to be the extreme in server performance. When sending an 8k (for example) NFS packet, a server will have to fragment the UDP packet to fit within N Ethernet packets, and will then send out the packets in a stream. If any one of the packets is corrupted, the receiver will not be able to defragment the UDP packet, and the NFS transaction will be repeated after a timeout. With well-tuned DECsystem NFS servers I have managed to get certain IP routers to lose the plot because incoming NFS fragment packets were too close together. An Auspex NFS server will send out the packets so quickly that I have found some Ethernet _repeaters_ that lose the plot. The symptoms of this kind of problem are "NFS server not responding" messages, but if the packet loss is because the client's device-driver/kernel is losing track, the behaviour is hard to predict... Reducing the block size will help the PC avoid buffer overruns. Reducing it to 1024 bytes will mean that each NFS data block will fit within one Ethernet packet, without a requirement for defragmenting packets. In case I'm being too depressing about 386bsd/NetBSD Ethernet performance, I'll remind you David Greenman posted to comp.os.386bsd.bugs recently promising a new high-performance WD/3com driver in several weeks time. Work on a better driver for the NE2000 is also ongoing. Until the new drivers are available, my advice is to stick to using small block sizes (eg. 1024 bytes) for NFS. Of course, with varying machine configurations your mileage may vary. >If you try "rsize=512,wsize=512", as I did on >my second attempt, then weird things happen. Hmm... Not sure about this. __ David Burren davidb@otto.bf.rmit.oz.au (guest acct) +61-3-634-3635