From owner-freebsd-performance@FreeBSD.ORG Mon Oct 30 05:11:33 2006 Return-Path: X-Original-To: performance@freebsd.org Delivered-To: freebsd-performance@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9FCF016A416; Mon, 30 Oct 2006 05:11:33 +0000 (UTC) (envelope-from pete@he.iki.fi) Received: from silver.he.iki.fi (helenius.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2744143D58; Mon, 30 Oct 2006 05:11:32 +0000 (GMT) (envelope-from pete@he.iki.fi) Received: from localhost (localhost [127.0.0.1]) by silver.he.iki.fi (Postfix) with ESMTP id 88062BBFF; Mon, 30 Oct 2006 07:11:30 +0200 (EET) Received: from silver.he.iki.fi ([127.0.0.1]) by localhost (silver.he.iki.fi [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Flw+ekcJxhyE; Mon, 30 Oct 2006 07:11:28 +0200 (EET) Received: from [IPv6:2001:670:84:0:dca1:af59:3d40:6dbd] (unknown [IPv6:2001:670:84:0:dca1:af59:3d40:6dbd]) by silver.he.iki.fi (Postfix) with ESMTP; Mon, 30 Oct 2006 07:11:27 +0200 (EET) Message-ID: <45458981.8010302@he.iki.fi> Date: Mon, 30 Oct 2006 07:11:29 +0200 From: Petri Helenius User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Greg 'groggy' Lehey References: <6.2.3.4.0.20061027180329.020bed68@localhost> <4542D941.2070204@centtech.com> <6.2.3.4.0.20061028124559.02105930@localhost> <4543AD35.30205@he.iki.fi> <20061030013211.GC1052@wantadilla.lemis.com> In-Reply-To: <20061030013211.GC1052@wantadilla.lemis.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Steve Peterson , performance@freebsd.org Subject: Re: gvinum raid5 performance seems slow X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2006 05:11:33 -0000 Greg 'groggy' Lehey wrote: > > Single stream tests aren't very good examples for RAID-5, because it > performs writes in two steps: first it reads the old data, then it > writes the new data. > If it really does it this way, instead doing write-only when writing sufficiently large blocks, that would explain the performance due to double rotational latency wait for each stripe size. Most implementations also use read/write caches to optimize this even further. Pete