From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 12 09:27:08 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 260AC16A422 for ; Sun, 12 Feb 2006 09:27:08 +0000 (GMT) (envelope-from soralx@cydem.org) Received: from pd4mo1so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2278543D45 for ; Sun, 12 Feb 2006 09:27:05 +0000 (GMT) (envelope-from soralx@cydem.org) Received: from pd2mr8so.prod.shaw.ca (pd2mr8so-qfe3.prod.shaw.ca [10.0.141.11]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IUK00DLLI947F00@l-daemon> for freebsd-hackers@freebsd.org; Sun, 12 Feb 2006 02:27:04 -0700 (MST) Received: from pn2ml2so.prod.shaw.ca ([10.0.121.146]) by pd2mr8so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IUK00BKDI94YU80@pd2mr8so.prod.shaw.ca> for freebsd-hackers@freebsd.org; Sun, 12 Feb 2006 02:27:04 -0700 (MST) Received: from soralx.cydem.org ([24.85.63.128]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IUK00B49I946G80@l-daemon> for freebsd-hackers@freebsd.org; Sun, 12 Feb 2006 02:27:04 -0700 (MST) Date: Sun, 12 Feb 2006 01:27:03 -0800 From: soralx@cydem.org In-reply-to: <200602112334.k1BNYf83084494@gate.bitblocks.com> To: bakul@BitBlocks.com Message-id: <200602120127.03988.soralx@cydem.org> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Content-disposition: inline References: <200602112334.k1BNYf83084494@gate.bitblocks.com> User-Agent: KMail/1.5.4 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 09:27:08 -0000 > > > Theoretically the sequential write rate should be same or > > > higher than the sequential read rate. Given an N+1 disk > > > > Seq write rate for the whole RAID5 array will always be lower > > than the write rate for it's single disk. > > 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? > > The parity blocks are not read on data reads, since this would be > > unnecessary overhead and would diminish performance. The parity > > blocks are read, however, when a read of a data sector results > > in a cyclic redundancy check (CRC) error." > > You can only do so if you know the array is consistent. If > the system crashed there is no such guarantee. So you either > have to rebuild the whole array to get to a consistent state > or do a parity check. If you don't check parity and you have > an inconsistent array, you can have a silent error (the data > may be trashed but you don't know that). But if you use RAM > without parity or ECC, you probably already don't care about > such errors. 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. p.S.: this is not hackers@ discussion. Timestamp: 0x43EEF1C0 [SorAlx] http://cydem.org.ua/ ridin' VN1500-B2