From owner-freebsd-current@FreeBSD.ORG Mon Jun 6 13:08:24 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7C8010656AB for ; Mon, 6 Jun 2011 13:08:24 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 99C5C8FC13 for ; Mon, 6 Jun 2011 13:08:24 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0EAGDQ7E2DaFvO/2dsb2JhbABThEqiaLlZkDaBK4NsgQoEkHmPVg X-IronPort-AV: E=Sophos;i="4.65,326,1304308800"; d="scan'208";a="123049028" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 06 Jun 2011 09:08:23 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id DBCD7B3F0F; Mon, 6 Jun 2011 09:08:23 -0400 (EDT) Date: Mon, 6 Jun 2011 09:08:23 -0400 (EDT) From: Rick Macklem To: Chris Forgeron Message-ID: <940963031.150645.1307365703884.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE7 (Win)/6.0.10_GA_2692) Cc: freebsd-current@freebsd.org Subject: Re: Heads Up: default NFS server changing to the new one X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 13:08:24 -0000 Chris Forgeron wrote: [stuff snipped] > > I hope to do a speed test comparison between new and old NFS servers > this weekend - At this stage, my feeling is that the new NFS server is > at least as fast. I suspect tests will show it to be faster (at least > the code looks faster. :-) ). > Well, I doubt you'll find much difference performance wise. An NFS server can be looked as a protocol translator, converting the NFS RPCs into VFS/VOP calls. Performance is largely defined by how well the network stack and/or file system perform. When you set up a server, there are a few things that may help: - If you are using FFS, create the file systems with the largest block size allowed. - If you are using ZFS, I know diddly about it, but others have suggested moving the ZIL log to a dedicated device which can do fast writes, such as an SSD optimized for fast write performance (not all SSDs do fast writing, although I think choosing the size of it significantly larger that the size of the log, so it has a lot of free blocks may help?). - Use lottsa nfsd threads (the default of 4 is for very minimal nfs serving only). Others may have additional suggestions? As for things the nfsd server code can do, I plan on looking at a couple of things, but I don't think those will be in 9.0: - Making MAXBSIZE larger. Even if it is larger than the largest block size supported for the underlying fs, this may help, because it can reduce the # of I/O RPCs. - A small patch (I'll probably make it available to anyone who wants to test it once I've done so) that will allow some NFS RPCs to use shared vnode locks. This should allow for more parallelism of read operations on a file, such as read-aheads done by a client. (I recently added a lock flags argument to VFS_FHTOVP() for 9.0, to facilitate this.) --> This one might improve the VFS/VOP call side. Thanks for letting me know how it's going, rick