Date: Mon, 25 Oct 1999 07:36:26 -0700 (PDT) From: David Wolfskill <dhw@whistle.com> To: dillon@apollo.backplane.com, freebsd-current@FreeBSD.ORG Subject: Re: freefall hangs w/ nfs Message-ID: <199910251436.HAA20848@pau-amma.whistle.com> In-Reply-To: <199910240742.AAA17268@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>Date: Sun, 24 Oct 1999 00:42:12 -0700 (PDT)
>From: Matthew Dillon <dillon@apollo.backplane.com>
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199910251436.HAA20848>