From owner-freebsd-stable@FreeBSD.ORG Sun Sep 12 15:44:41 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1B54106564A for ; Sun, 12 Sep 2010 15:44:41 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 7F6438FC0C for ; Sun, 12 Sep 2010 15:44:41 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqwFAKaRjEyDaFvO/2dsb2JhbACDGZBfjkGsVJBigSKDKnQEiic X-IronPort-AV: E=Sophos;i="4.56,355,1280721600"; d="scan'208";a="93597338" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 12 Sep 2010 11:44:40 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 77F94B3EA8; Sun, 12 Sep 2010 11:44:40 -0400 (EDT) Date: Sun, 12 Sep 2010 11:44:40 -0400 (EDT) From: Rick Macklem To: rick-freebsd2009@kiwi-computer.com Message-ID: <404412916.782668.1284306279949.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20100904023550.GB47730@rix.kiwi-computer.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [24.65.230.102] X-Mailer: Zimbra 6.0.7_GA_2476.RHEL4 (ZimbraWebClient - SAF3 (Mac)/6.0.7_GA_2473.RHEL4_64) Cc: Hannes Hauswedell , freebsd-stable@freebsd.org Subject: Re: Why is NFSv4 so slow? 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: Sun, 12 Sep 2010 15:44:41 -0000 > On Wed, Sep 01, 2010 at 11:46:30AM -0400, Rick Macklem wrote: > > > > > > I am experiencing similar issues with newnfs: > > > > > > 1) I have two clients that each get around 0.5MiB/s to 2.6MiB/s > > > reading > > > from the NFS4-share on Gbit-Lan > > > > > > 2) Mounting with -t newnfs -o nfsv3 results in no performance gain > > > whatsoever. > > > > > > 3) Mounting with -t nfs results in 58MiB/s ! (Netcat has similar > > > performance) ??? not a hardware/driver issue from my pov > > > > Ok, so it does sound like an issue in the experimental client and > > not NFSv4. For the most part, the read code is the same as > > the regular client, but it hasn't been brought up-to-date > > with recent changes. > > Do you (or will you soon) have some patches I/we could test? I'm > willing to try anything to avoid mounting ten or so subdirectories in > each of my mount points. > > > One thing you could try is building a kernel without SMP enabled > > and see if that helps? (I only have single core hardware, so I won't > > see any SMP races.) If that helps, I can compare the regular vs > > experimental client for smp locking in the read stuff. > > I can try disabling SMP too. Should that really matter, if you're not > even pegging one CPU? The locks shouldn't have *that* much overhead... > > -- Rick C. Petty > Just fyi, I asked folks to run read tests on the clients (over on freebsd-fs), Sofar, I've only gotten one response, but they didn't see the problem you are (they did see a factor of 2 slower, but it is still 50Mbytes/sec). Maybe you can take a look at their email and compare his client with yours? His message is: http://docs.FreeBSD.org/cgi/mid.cgi?01NRSE7GZJEC0022AD Btw, if anyone who didn't see the posting on freebsd-fs and would like to run a quick test, it would be appreciated. Bascially do both kinds of mount using a FreeBSD8.1 or later client and then read a greater than 100Mbyte file with dd. # mount -t nfs -o nfsv3 :/path / - cd anywhere in mount that has > 100Mbyte file # dd if= of=/dev/null bs=1m # umount / Then repeat with # mount -t newnfs -o nfsv3 :/path / and post the results along with the client machine's info (machine arch/# of cores/memory/net interface used for NFS traffic). Thanks in advance to anyone who runs the test, rick