From owner-freebsd-stable@FreeBSD.ORG Tue Nov 23 14:59:26 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D5BD1065674 for ; Tue, 23 Nov 2010 14:59:26 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by mx1.freebsd.org (Postfix) with ESMTP id 3576D8FC19 for ; Tue, 23 Nov 2010 14:59:25 +0000 (UTC) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta12.westchester.pa.mail.comcast.net with comcast id ad0b1f0051ZXKqc5CezS0u; Tue, 23 Nov 2010 14:59:26 +0000 Received: from koitsu.dyndns.org ([98.248.41.155]) by omta21.westchester.pa.mail.comcast.net with comcast id aezQ1f00L3LrwQ23hezR8y; Tue, 23 Nov 2010 14:59:26 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 6D1F49B427; Tue, 23 Nov 2010 06:59:23 -0800 (PST) Date: Tue, 23 Nov 2010 06:59:23 -0800 From: Jeremy Chadwick To: Josh Paetzel Message-ID: <20101123145923.GA61357@icarus.home.lan> References: <201011230833.59085.josh@tcbug.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201011230833.59085.josh@tcbug.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: re@freebsd.org, stable@freebsd.org, rmacklem@uoguelph.ca, imp@freebsd.org Subject: Re: NFS regression on recent STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 14:59:26 -0000 On Tue, Nov 23, 2010 at 08:33:52AM -0600, Josh Paetzel wrote: > I've been involved with a project at work doing some fun things with NFS. > Recently due to changes in a available hardware we did a complete refresh of > the system. New HBAs, new storage boxes, and due to some internal software > confusion we updated the OS on the head from 8.1-R with zpool 15 backported to > STABLE. > > Our primary client that we were using against this setup was a ESXi 4.1 > machine. In a nutshell, it didn't work. Long description is, ZFS would > deadlock and any operation on the pool would hang. The ESXi instance would > mark the NFS mount as unavailable. I initially thought this could be due to > any number of factors, we have new HBAs in the mix, new storage boxes, a new > version of zpool, and one test case. > > Meanwhile, back at the ranch, I have a somewhat similar setup at home. > FreeBSD 8.1 NFS server, ESXi 4.1 box mounting an NFS exported ZFS filesystem > from the FreeBSD box as a datastore. > > Last night I pulled that box up to STABLE, rebooted it, and a minute after it > rebooted the ESXi box marked the NFS datastore as unavailable. I checked the > FreeBSD machine and sure enough it hung doing an ls on the zpool. > > I ran a few tests, and as soon as the ESXi box mounts the NFS export it hangs > the ZFS filesystem. If I don't mount it up, the NFS server does fine. > Thinking it might be a ZFS problem I moved the mount to a UFS filesystem. > While this doesn't cause the box to hang on filesystem operations, the mount > goes unavailable. > > The only other client I have on my network is a FreeBSD 8.1 box, and that has > no issues > > All of this is with the standard NFS server, I haven't yet tested with the > experimental server. Sounds relevant, try the patch provided: http://lists.freebsd.org/pipermail/freebsd-stable/2010-November/059853.html Relevant follow-up: http://lists.freebsd.org/pipermail/freebsd-stable/2010-November/059869.html -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |