From owner-freebsd-current Mon Oct 25 7:37: 5 1999 Delivered-To: freebsd-current@freebsd.org Received: from pau-amma.whistle.com (pau-amma.whistle.com [207.76.205.64]) by hub.freebsd.org (Postfix) with ESMTP id 71C4514BFD for ; Mon, 25 Oct 1999 07:37:02 -0700 (PDT) (envelope-from dhw@whistle.com) Received: (from dhw@localhost) by pau-amma.whistle.com (8.9.2/8.9.2) id HAA20848; Mon, 25 Oct 1999 07:36:26 -0700 (PDT) Date: Mon, 25 Oct 1999 07:36:26 -0700 (PDT) From: David Wolfskill Message-Id: <199910251436.HAA20848@pau-amma.whistle.com> To: dillon@apollo.backplane.com, freebsd-current@FreeBSD.ORG Subject: Re: freefall hangs w/ nfs In-Reply-To: <199910240742.AAA17268@apollo.backplane.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >Date: Sun, 24 Oct 1999 00:42:12 -0700 (PDT) >From: Matthew Dillon > It looks on the face of it that AMD is hanging. Perhaps this is > preventing the system from clearing out buffers and causing lockups > on other mounts. AMD could also be causing a deadlock to occur in the > buffer cache (for the same reason loopback mounts can cause deadlocks). > The next time this happens, if the person rebooting freefall can get > a kernel dump (and have a corresponding debug kernel) I may be able to > track it down for sure. Fixing it is another problem, though. Loopback > deadlocks are a big problem under 3.x. In an environment where there is use of amd and NFS, there is no need for loopback NFS mounts. The reason is that in addition to its "classical" role of simulating an NFS mount, amd is also quite capable of simulating a symlink. I ended up doing some of that as part of my first exposure to FreeBSD (when I started here at Whistle) because otherwise, my desktop would crash just about any time I tried to use "make". A (slightly re-formatted for legibility) example of an amd map that accomplishes the distinction is: /defaults sublink:=${key} * host!=shrimp;os==freebsd4;rhost:=shrimp;type:=nfs;\ rfs:=/shrimp/tribe;fs:=${autodir}/shrimp/tribe;\ opts:=vers=2,proto=udp,rw,intr,nosuid,grpid \ host!=shrimp;os==freebsd3;rhost:=shrimp;type:=nfs;\ rfs:=/shrimp/tribe;fs:=${autodir}/shrimp/tribe;\ opts:=vers=2,proto=udp,rw,intr,nosuid,grpid \ host!=shrimp;os!=freebsd3;rhost:=shrimp;type:=nfs;\ rfs:=/shrimp/tribe;fs:=${autodir}/shrimp/tribe;\ opts:=nfsv2,noconn,rw,intr,nosuid,grpid \ host==shrimp;type:=link;fs:=/shrimp/tribe The key notion is embodied in that last line -- if the client is "shrimp" (which happens to be the name of the server), don't use NFS; rather, fabricate a symlink. Yes, I realize that this doesn't fix the problem that plagues loopback NFS mounts; it avoids the issue instead. But sometimes it's appropriate to make things work, even if it's not the ideal solution. Making that judgement call is not something I'm prepared to do in this case; I'm presenting an alternative that has worked for me, in cases where I have made that call. Cheers, david -- David Wolfskill dhw@whistle.com UNIX System Administrator voice: (650) 577-7158 pager: (888) 347-0197 FAX: (650) 372-5915 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message