Date: Thu, 15 Feb 2001 15:43:21 -0800 (PST) From: amesbury@eventloop.com To: freebsd-gnats-submit@FreeBSD.org Subject: i386/25123: Heavy NFS traffic over virtual interface causes instability, lockup under 4.2-STABLE Message-ID: <200102152343.f1FNhLe96213@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 25123
>Category: i386
>Synopsis: Heavy NFS traffic over virtual interface causes instability, lockup under 4.2-STABLE
>Confidential: no
>Severity: critical
>Priority: medium
>Responsible: freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Thu Feb 15 15:50:00 PST 2001
>Closed-Date:
>Last-Modified:
>Originator: Alan Amesbury
>Release: 4.2-STABLE
>Organization:
EventLoop, Inc.
>Environment:
FreeBSD capstone.eventloop.com 4.2-STABLE FreeBSD 4.2-STABLE #5: Wed Feb 14 19:28:58 CST 2001 root@capstone.eventloop.com:/usr/src/sys/compile/EVENTLOOP-SMP i386
>Description:
The system in question is has a NIC configured to answer to two IP
addresses, named capstone (real if.) and mausoleum (virtual if.).
nfsd is configured to export a number of directories via mausoleum's
address. Capstone is configured to use AMD to mount NFS shares from
mausoleum as if mausoleum were actually a remote host, not just a
virtual interface. Here's what ifconfig looks like:
amesbury@capstone:[~] % ifconfig xl0
xl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 192.168.100.1 netmask 0xffffff00 broadcast 192.168.100.255
inet 192.168.100.221 netmask 0xffffffff broadcast 192.168.100.221
atalk 58305.179 range 0-65534 phase 2 broadcast 0.255
ether 00:01:02:ca:98:91
media: autoselect (100baseTX <full-duplex>) status: active
supported media: autoselect 100baseTX <full-duplex> 100baseTX 10baseT/UTP <full-duplex> 10baseT/UTP 100baseTX <hw-loopback>
AMD is configured on capstone (the host's real name) to automatically
mount directories from mausoleum (capstone's virtual interface) as if
mausoleum were really a different machine. For example:
amesbury@capstone:[~] % mount | grep home
pid167@capstone:/home on /home (nfs)
mausoleum:/export/mausoleum05/home/amesbury on /.amd_mnt/mausoleum/export/mausoleum05/home/amesbury (nfs)
The system becomes unstable when very large files (>100MB) are
transferred from a remote system into a directory mounted by capstone
from mausoleum. This instability exhibits itself regardless of whether
the transfer is initiated from capstone or from a remote system, and
does not seem to be dependent on the transfer method used (both scp and
FTP crashed the system). If the transfer is made to the NFS mount point
(mounted via AMD), the system will crash. If the transfer is made
directly to the real directory location, the transfer will succeed,
regardless of whether the connection was made to capstone or masoleum.
For example, if I 'cd' to '/home/amesbury' and, using FTP, download a
very large file into the current directory, the file gets written over
NFS to mausoleum (capstone's virtual interface). The system will
become unstable (network services will freeze, commands like 'reboot'
and 'ls' will simply hang), and eventually it will lock up completely.
I've seen no syslog output, kernel panics, or anything else that looked
like it might be of use in troubleshooting this further.
>How-To-Repeat:
We have very limited resources, so have been unable to try this on
another machine. If I get an opportunity to, I'll post the results.
Also, since capstone/mausoleum is a production, business-critical host,
I'm reluctant to experiment with it further.
>Fix:
Workaround: don't use NFS locally via a system's virtual interface?
>Release-Note:
>Audit-Trail:
>Unformatted:
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200102152343.f1FNhLe96213>