From owner-freebsd-fs@FreeBSD.ORG Mon Mar 26 17:33:22 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0A935106564A for ; Mon, 26 Mar 2012 17:33:22 +0000 (UTC) (envelope-from bfriesen@simple.dallas.tx.us) Received: from blade.simplesystems.org (blade.simplesystems.org [65.66.246.74]) by mx1.freebsd.org (Postfix) with ESMTP id AECA18FC08 for ; Mon, 26 Mar 2012 17:33:21 +0000 (UTC) Received: from freddy.simplesystems.org (freddy.simplesystems.org [65.66.246.65]) by blade.simplesystems.org (8.14.4+Sun/8.14.4) with ESMTP id q2QHQotM028173; Mon, 26 Mar 2012 12:26:50 -0500 (CDT) Date: Mon, 26 Mar 2012 12:26:50 -0500 (CDT) From: Bob Friesenhahn X-X-Sender: bfriesen@freddy.simplesystems.org To: Sven Brandenburg In-Reply-To: <4F709A2C.2080806@crashme.org> Message-ID: References: <4F703815.8070809@crashme.org> <4F709A2C.2080806@crashme.org> User-Agent: Alpine 2.01 (GSO 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (blade.simplesystems.org [65.66.246.90]); Mon, 26 Mar 2012 12:26:50 -0500 (CDT) Cc: freebsd-fs@freebsd.org Subject: Re: NFSv3, ZFS, 10GE performance X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 17:33:22 -0000 On Mon, 26 Mar 2012, Sven Brandenburg wrote: > >> Are you only interested in single threaded read performance to a single >> client? > My first item on the list is serving one client as fast as possible, next > step is multiple client machines (maybe these are conflicting goals?). > However, I figure that I should at least be able to press the right buttons > to dial in "fast" for one client :-) It really depends on if the client will actually consume all of the data as requested or if the client application will be competing with NFS because it transfers data it will never need. An issue which is quite familiar to me is the TIFF image file format. This format stores the image data in sequential strips, yet it uses more complex data structures (which require many seek + small read) as well. In my testing, I found that excessive read-ahead hindered performance with this file format. More than 16k of read-ahead often resulted in a performance penalty over NFS. Memory mapped files can also cause a performance problem since the MMU page size is typically 4K and the program is blocked from running until the current page fault completes. Bob -- Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/