From owner-freebsd-current@FreeBSD.ORG Tue Nov 2 02:15:45 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD76A16A4CF for ; Tue, 2 Nov 2004 02:15:45 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id B1FE743D2D for ; Tue, 2 Nov 2004 02:15:45 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 992EE7A443; Mon, 1 Nov 2004 18:15:45 -0800 (PST) Message-ID: <4186EDD1.8090805@elischer.org> Date: Mon, 01 Nov 2004 18:15:45 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Brad Knowles References: <002401c4bf9c$c4fee8e0$0201000a@riker> <1099286568.4185c82881654@picard.newmillennium.net.au> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Alastair D'Silva cc: current@freebsd.org Subject: Re: Gvinum RAID5 performance X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2004 02:15:45 -0000 Brad Knowles wrote: > At 4:22 PM +1100 2004-11-01, Alastair D'Silva wrote: > > > The offshoot of this is that to ensure data integrity, a background > > process is run periodically to verify the parity. > > > That's not the way that RAID-5 is supposed to work, at least not the > way I understand it. I would be very unhappy if I was using a disk > storage subsystem that was configured for RAID-5 and then found out > it was working in this manner. At the very least, I don't believe > that we could/should do this by default, and adding code to perform > in this manner seems to me to be unnecessary complexity. You need the background task to read the blocks on the parity stripe because if you only ever get good reads from teh data stripes and never read the parity stripe you may grow bad sectors there which you will not detect until you need then and by then its too late. It need sto be run at a very low priority however so as to not interfere with production. > > > Keep in mind that if you've got a five disk RAID-5 array, then for > any given block, four of those disks are data and would have to be > accessed on every read operation anyway, and only one disk would be > parity. The more disks you have in your RAID array, the lower the > parity to data ratio, and the less benefit you would get from > checking parity in background. it's not tha tyou need to verify the parity (though you should do that too OCCASIONALLY) but that you need to rewrite any bad secors while you can regenerate the data and not fail and THEN discover you can not read all the data. > > > I did notice that the read from a single drive resulted in that > > drive's access light being locked on solid, while reading from the > > plex caused all drives to flicker rather than being solid). > > > > > A "lazy read parity" RAID-5 implementation might have slightly > increased performance over normal RAID-5 on the same > controller/subsystem configuration, but the added complexity seems to > be counter-productive. If there is a hardware vendor that does this, > I'd be willing to bet that it's a lame marketing gimmick and little > more. you certainly don't need to read the parity if you read good data from the disk but you do need to read it on a regular basis. >