From owner-freebsd-bugs Thu Feb 15 15:50:11 2001 Delivered-To: freebsd-bugs@hub.freebsd.org Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 3F8F737B69B for ; Thu, 15 Feb 2001 15:50:01 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.1/8.11.1) id f1FNo1C97038; Thu, 15 Feb 2001 15:50:01 -0800 (PST) (envelope-from gnats) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id BD5BB37B69B for ; Thu, 15 Feb 2001 15:43:21 -0800 (PST) Received: (from nobody@localhost) by freefall.freebsd.org (8.11.1/8.11.1) id f1FNhLe96213; Thu, 15 Feb 2001 15:43:21 -0800 (PST) (envelope-from nobody) Message-Id: <200102152343.f1FNhLe96213@freefall.freebsd.org> Date: Thu, 15 Feb 2001 15:43:21 -0800 (PST) From: amesbury@eventloop.com To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-1.0 Subject: i386/25123: Heavy NFS traffic over virtual interface causes instability, lockup under 4.2-STABLE Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >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 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 ) status: active supported media: autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP 100baseTX 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