From owner-freebsd-stable Tue Sep 4 5:54:17 2001 Delivered-To: freebsd-stable@freebsd.org Received: from sabre.velocet.net (sabre.velocet.net [198.96.118.66]) by hub.freebsd.org (Postfix) with ESMTP id 32ADA37B403; Tue, 4 Sep 2001 05:54:14 -0700 (PDT) Received: from office.tor.velocet.net (trooper.velocet.net [204.138.45.2]) by sabre.velocet.net (Postfix) with ESMTP id 4D075137FE4; Tue, 4 Sep 2001 08:54:13 -0400 (EDT) Received: (from dgilbert@localhost) by office.tor.velocet.net (8.11.4/8.9.3) id f84Cs2i48585; Tue, 4 Sep 2001 08:54:02 -0400 (EDT) (envelope-from dgilbert) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15252.52970.460898.188811@trooper.velocet.net> Date: Tue, 4 Sep 2001 08:54:02 -0400 To: Pete French Cc: behanna@zbzoom.net, grog@FreeBSD.org, stable@FreeBSD.org Subject: [stable] Re: RAID5 In-Reply-To: References: <20010904105035.C10292@wantadilla.lemis.com> X-Mailer: VM 6.92 under 20.4 "Emerald" XEmacs Lucid Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG >>>>> "Pete" == Pete French writes: >> Interestingly, CPU isn't the performance issue most people (myself >> once included) assume it is. Even on my original Vinum testbed, a >> 468/66, CPU usage was barely measurable. That's probably why most >> hardware RAID controllers use relatively slow CPUs. Pete> Interesting comment. I have acciddentally acquired apair of Pete> SMART 2SL controllers. One of which I am using as the boot Pete> device for the FreeBSD box (because iits theonly disc controller Pete> I've got - RAID 0). The other I was going to use to build an Pete> array, but I am having trouble finding any comoparative Pete> benchmarks as to how slow certain combinations of drives are Pete> under RAID-5. Are their certain numbers that make the processing Pete> "easier" for the onboard chip ? (*i.e. does 5 discs make life Pete> for it faster as it can split a byte onto 4 platters and Pete> allocate one for parity rather than dooing shifts all over the Pete> place ?) or is it best to just give it as many dricves as Pete> possible (8 in this case). AFAIK, no sane RAID implementation split data at the bit level. Most split the data in "chunks" ... I say chunks because the split granularity can be larger or smaller than blocks, although it is most commonly multiple blocks. Some of the performance constraints that I observe in hardware raid controllers are aparently (others have told me this) due to the fact that they can only do IO operations in whole chunks. They typically want small chunks (1K ... 4K ... 8K ... something along those lines). There is a good discussion of chunk size in the vinum manual. Vinum recomends chunks of even 512K or more. Anyways... back to the striping... whatever raid your doing is striped at the "chunk" level. RAID does not break up your 8K request by delivering every 8th byte to one of your 8 drives... the 8K request goes directly to one or more chunks in a linear fashion. (Keep in mind that high performance on a RAID system often requires many busy tasks, not just one). Dave. -- ============================================================================ |David Gilbert, Velocet Communications. | Two things can only be | |Mail: dgilbert@velocet.net | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =========================================================GLO================ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message