From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 12 17:20:36 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CB4FD16A420 for ; Sun, 12 Feb 2006 17:20:36 +0000 (GMT) (envelope-from bakul@bitblocks.com) Received: from gate.bitblocks.com (bitblocks.com [209.204.185.216]) by mx1.FreeBSD.org (Postfix) with ESMTP id 85A6543D45 for ; Sun, 12 Feb 2006 17:20:36 +0000 (GMT) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (localhost [127.0.0.1]) by gate.bitblocks.com (8.13.4/8.13.1) with ESMTP id k1CHKWFY089596; Sun, 12 Feb 2006 09:20:32 -0800 (PST) (envelope-from bakul@bitblocks.com) Message-Id: <200602121720.k1CHKWFY089596@gate.bitblocks.com> To: soralx@cydem.org In-reply-to: Your message of "Sun, 12 Feb 2006 01:27:03 PST." <200602120127.03988.soralx@cydem.org> Date: Sun, 12 Feb 2006 09:20:32 -0800 From: Bakul Shah Cc: freebsd-hackers@freebsd.org Subject: Re: RAID5 on athlon64 machines X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2006 17:20:36 -0000 > > You compute max data rates by considering the most optimistic > > scenario, which is large sequetial writes. For *this* > > situation write rate will be higher than a single disk's. > > How can the RAID5 write rate be higher for the whole array if not > only it needs to write the data to all if its drives, but also > compute and write a parity block? You write to all the disks at the same time. While the disks are busy writing you compute parity for the next stripe. In my case disk bw is 60MB/s. Memory bw is I thin 3GB/s. There ought to be plenty of bw and cpu for xor computing. > IMO, RAID does not protect against system crashes - all it does > is provide performance increase and/or some protection against > hardware failure (which will be detected with extremely high > probability) enabling the admin to restore some data. No it can't if you don't do the parity check on reads and a previous write to the stripe was incomplete due to system crash. You will happily deliver incorrect data to the user and he only knows *something* is wrong when his system crashes or program misbehaves or some binary data doesn't quite feel right or some text is garbled or some secondary bad effect. May be you need to use the same principle in your learning? Check your understanding by applying it and trying to extend it. Don't just believe what you read, cross-check it. Question the (so called) authority! The revolution will not be televised. Oops I think I have a scrambled brain block.