From owner-freebsd-stable@FreeBSD.ORG Mon Jul 26 10:04:51 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 3433B1065676 for ; Mon, 26 Jul 2010 10:04:51 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id EB3B28FC26 for ; Mon, 26 Jul 2010 10:04:50 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1OdKY8-00052B-Qt for freebsd-stable@freebsd.org; Mon, 26 Jul 2010 12:04:44 +0200 Received: from 89-164-123-137.dsl.iskon.hr ([89.164.123.137]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 26 Jul 2010 12:04:44 +0200 Received: from ivoras by 89-164-123-137.dsl.iskon.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 26 Jul 2010 12:04:44 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Mon, 26 Jul 2010 12:04:34 +0200 Lines: 28 Message-ID: References: <4C4BA50B.6050507@langille.org> <4C4BB672.3090109@langille.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 89-164-123-137.dsl.iskon.hr User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 In-Reply-To: <4C4BB672.3090109@langille.org> Subject: Re: gpart -b 34 versus gpart -b 1024 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: Mon, 26 Jul 2010 10:04:51 -0000 On 25.7.2010 5:58, Dan Langille wrote: >> -------Sequential Output-------- ---Sequential Input-- --Random-- >> -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- >> GB M/sec %CPU M/sec %CPU M/sec %CPU M/sec %CPU M/sec %CPU /sec %CPU >> 5 110.6 80.5 115.3 15.1 60.9 8.5 68.8 46.2 326.7 15.3 469 1.4 >> 5 130.9 94.2 118.3 15.6 61.1 8.5 70.1 46.8 241.2 12.7 473 1.4 > 50 113.1 82.4 114.6 15.2 63.4 8.9 72.7 48.2 142.2 9.5 126 0.7 > 50 110.5 81.0 112.8 15.0 62.8 9.0 72.9 48.5 139.7 9.5 144 0.9 > Here, the results aren't much better either... am I not aligning this > partition correctly? Missing something else? Or... are they both 4K > block aligned? As others have said - your drives probably don't have the alignment requiremnt, but your posts show in an excellent example why benchmarking file systems is complicated and how easy it is to measure noise instead of the real thing. To measure real performance in your case, you would either need to benchmark at a layer beneath the file system or with a simple file system which does alwasy predictable io patterns. It's hard to do with zfs with raidz - afaik even accessing the "raw" zvols translates into complex IOs (they are COW).