From owner-freebsd-hackers Thu Apr 1 14:18:12 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 4453A14D5C for ; Thu, 1 Apr 1999 14:18:09 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id PAA04791; Thu, 1 Apr 1999 15:17:41 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199904012217.PAA04791@panzer.plutotech.com> Subject: Re: More death to nfsiod (workarround) In-Reply-To: <199904012009.PAA05275@cs.rpi.edu> from "David E. Cross" at "Apr 1, 1999 3: 9:17 pm" To: crossd@cs.rpi.edu (David E. Cross) Date: Thu, 1 Apr 1999 15:17:41 -0700 (MST) Cc: dillon@apollo.backplane.com, crossd@cs.rpi.edu, freebsd-hackers@FreeBSD.ORG, schimken@cs.rpi.edu X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG David E. Cross wrote... > > AMD is a rather complex piece of software. It's creating a situation > > that the kernel isn't happy with but I really don't have time to delve > > into it ( anyone else care to take a shot at it? ) on top of everything > > else I'm doing. If there is any way you can avoid using AMD, I would > > avoid using AMD. > Late yesterday I was able to determine how amd was mounting the partitions, > and I was able to replicate it with a hand-mounted filesystem. I was in the > process of digging through NFS packets between 2 hosts when I made the > observation "Hey, this isn't UDP". I then hand mounted a filesytstem with > "mount_nfs -2T -r 8192 -w 8192 server:/path /mnt" ran my test, and it failed :) > > Since then I have updated AMD to use vers3/UDP for mounts, and guess what, so > far the problem has not come back. I have run the test 4 times now, not a > single failure, and it is *FAST*. To tickle this you need to have a relatively > fast connect between the NFS client and server (switched half duplex 10M > segment was enough to do it, although the primary machine that was having the > problem was dedicated 100M full-duplex). I am able to reproduce this with > relative ease here. > > (mount_nfs -3T -r 8192 -w 8192 ... also seemed to work) Yeah, I upgraded a number of machines (30+) to -stable about 10 days ago, and was irritated to discover that AMD defaulted to TCP mounts. I put proto=udp in the amd configuration files, and things got back to normal. I had some hang problems with TCP mounts under amd, but that may have also been because of a routing problem I fixed at the same time that I changed from TCP mounts to UDP. And, I'll have to say that NFS is much better than it has been in the past. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message