From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 11 23:34:47 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 1069116A420 for ; Sat, 11 Feb 2006 23:34:47 +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 8A2A943D5A for ; Sat, 11 Feb 2006 23:34:46 +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 k1BNYf83084494; Sat, 11 Feb 2006 15:34:41 -0800 (PST) (envelope-from bakul@bitblocks.com) Message-Id: <200602112334.k1BNYf83084494@gate.bitblocks.com> To: soralx@cydem.org In-reply-to: Your message of "Sat, 11 Feb 2006 15:21:29 PST." <200602111521.29263.soralx@cydem.org> Date: Sat, 11 Feb 2006 15:34:41 -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: Sat, 11 Feb 2006 23:34:47 -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. > 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.