Date: Thu, 01 Apr 1999 15:09:17 -0500 From: "David E. Cross" <crossd@cs.rpi.edu> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: "David E. Cross" <crossd@cs.rpi.edu>, freebsd-hackers@FreeBSD.ORG, schimken@cs.rpi.edu, crossd@cs.rpi.edu Subject: Re: More death to nfsiod (workarround) Message-ID: <199904012009.PAA05275@cs.rpi.edu> In-Reply-To: Message from Matthew Dillon <dillon@apollo.backplane.com> of "Tue, 30 Mar 1999 22:24:45 PST." <199903310624.WAA45232@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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) -- David Cross To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199904012009.PAA05275>