From owner-freebsd-hardware@FreeBSD.ORG Fri Nov 16 12:54:39 2007 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 480D516A41A for ; Fri, 16 Nov 2007 12:54:39 +0000 (UTC) (envelope-from bseklecki@collaborativefusion.com) Received: from mx00.pub.collaborativefusion.com (mx00.pub.collaborativefusion.com [206.210.89.199]) by mx1.freebsd.org (Postfix) with ESMTP id EDD1A13C46A for ; Fri, 16 Nov 2007 12:54:38 +0000 (UTC) (envelope-from bseklecki@collaborativefusion.com) Received: from [192.168.2.62] (pr40.pitbpa0.pub.collaborativefusion.com [206.210.89.202]) (AUTH: LOGIN seklecki, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wingspan with esmtp; Fri, 16 Nov 2007 07:54:37 -0500 id 0005641B.473D930D.00015434 From: "Brian A Seklecki (Mobile)" To: Simon In-Reply-To: <20071115212026.5C3E613C45A@mx1.freebsd.org> References: <20071115212026.5C3E613C45A@mx1.freebsd.org> Organization: Collaborative Fusion, Inc. Date: Fri, 16 Nov 2007 07:53:24 -0500 Message-Id: <1195217644.4042.199.camel@new-host> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Evolution 2.12.1 (2.12.1-3.fc8) Cc: Sean McAfee , Jason Thomson , Benjie Chen , "freebsd-hardware@freebsd.org" Subject: Re: PERC5 (LSI MegaSAS) Patrol Read crashes X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2007 12:54:39 -0000 > If Patrol Reads are marketing bullshit, what do you use? consistency If a block is bad, a block is bad. The disk has a certain number of spares. Those are automatically allocated by the disk underneath the controller. When that compliment is exhausted, then _THE DISK IS BAD_. A single bad sector on a RAID volume component disk means that you need to _REPLACE THE DISK_. When a controller finds a bad sector, that disk should be moved to degraded state. Period. As for the idea of randomly finding and fixing parity errors while the OS is running... hardware or otherwise related, that just sounds like a bad idea to me. I prefer the CMU RAIDFrame / GMirror approach: You check the volume at start-up. You search for records of a graceful shutdown on both components. If you _don't_ find them, you run a full parity check. The volume is then parity-clean until it is shutdown ungracefully. How could the parity be found to be bad while the OS is running if there are no bad components or other hardware events?? ( And why does the PERC5 (and for that matter, the PERC4) never scan parity at startup? ) I asked Dell two year ago and never got an answer. Until then, FreeBSD Gmirror is still a perfectly valid option. > The way I see it, until manufacturers such as Dell and HP start fully > supporting FreeBSD, the mentioned problems will never go away They don't have to "Support FreeBSD". Thats our job. What they need to do is work with OEM component vendors who don't consider kernel-hardware interface I.P. See OpenBSD.