From owner-freebsd-stable@FreeBSD.ORG Mon Mar 22 09:53:08 2004 Return-Path: Delivered-To: freebsd-stable@www.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 91D8E16A4CE for ; Mon, 22 Mar 2004 09:53:08 -0800 (PST) Received: from mx2.freebsd.org (mx2.freebsd.org [216.136.204.119]) by mx1.FreeBSD.org (Postfix) with ESMTP id 899CE43D2D for ; Mon, 22 Mar 2004 09:53:08 -0800 (PST) (envelope-from mandrews@bit0.com) Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id 7764A5542C for ; Mon, 22 Mar 2004 09:53:08 -0800 (PST) (envelope-from mandrews@bit0.com) Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7394616A4CE for ; Mon, 22 Mar 2004 09:53:08 -0800 (PST) Received: from bit0.com (bit0.com [216.24.42.194]) by mx1.FreeBSD.org (Postfix) with SMTP id 7086143D2D for ; Mon, 22 Mar 2004 09:53:07 -0800 (PST) (envelope-from mandrews@bit0.com) Received: from localhost (localhost.bit0.com [127.0.0.1]) by bit0.com (Postfix) with ESMTP id 19E3A34DA6 for ; Mon, 22 Mar 2004 12:53:07 -0500 (EST) Date: Mon, 22 Mar 2004 12:53:07 -0500 (EST) From: Mike Andrews To: freebsd-stable@lists.freebsd.org In-Reply-To: <20040318144807.E95350@mindcrime.bit0.com> Message-ID: <20040322124916.M59896@mindcrime.bit0.com> References: <20040318144807.E95350@mindcrime.bit0.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: Weird NFSvs rdirplus issues X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2004 17:53:08 -0000 On Thu, 18 Mar 2004, Mike Andrews wrote: > The motivating factor in using readdirplus at all is that it drastically > reduces CPU load, ethernet load, and NFS ops/sec on the Netapps, which are > not exactly cheap to upgrade CPU in. When I turned readdirplus off to > stop the file corruption, the Netapp's CPU load pegged at 100% around the > clock. But interestingly, it doesn't seem to raise the actual disk spindle > ops/sec; probably the extra stat() calls are being handled from its disk > cache. Still, the overhead of quadruping the number of NFS calls is too > much for it... Actually, it turns out the load was caused by a client process that got stuck right about the same time I was experimenting with different mount options. Oops. I'm running without rdirplus with normal performance now. Still wish I understood the ac options a bit better though. There's still the issue of mount_nfs dumping core in 4.9 though, if it wasn't already backported from -current to -stable for 4.10... > Bizarre situation #1 is the easy one: when you try to put the acdirmin/max > and acregmin/max options on an NFS filesystem in /etc/fstab, mount > (actually mount_nfs) will dump core on 4.9-RELEASE-p4 but not on > 5.2.1-RELEASE-p3: > > # grep acreg /etc/fstab > server:/fs /mnt nfs,ro,-lis,acdirmin=0,acdirmax=1,acregmin=0,acregmax=1 0 0 > # mount /mnt > mount: server:/fs: Segmentation fault > > (the core file left behind is for mount_nfs, not mount, though) > However running mount_nfs at the command line will work, even on 4.9: > > # mount_nfs -lis -o acdirmin=0,acdirmax=1,acregmin=0,acregmax=1 server:/fs /mnt > > Looks like some kind of parsing error that the fix hasn't been MFC'ed for? > (I haven't been able to check 4.9-STABLE yet to see if the fix made it there.) Mike Andrews * mandrews@bit0.com * http://www.bit0.com "The truth is, you never find the truth." Carpe cavy! It's not news, it's Fark.com.