From owner-freebsd-stable@FreeBSD.ORG Sat Aug 25 07:39:19 2007 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C096416A417 for ; Sat, 25 Aug 2007 07:39:19 +0000 (UTC) (envelope-from tom@samplonius.org) Received: from ly.sdf.com (ly.sdf.com [216.113.193.83]) by mx1.freebsd.org (Postfix) with ESMTP id 894EB13C494 for ; Sat, 25 Aug 2007 07:39:19 +0000 (UTC) (envelope-from tom@samplonius.org) Received: from localhost (localhost [127.0.0.1]) by ly.sdf.com (Postfix) with ESMTP id 0F1622283AA; Sat, 25 Aug 2007 00:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at X-Spam-Score: -3.971 X-Spam-Level: X-Spam-Status: No, score=-3.971 tagged_above=-10 required=6.6 tests=[ALL_TRUSTED=-1.8, AWL=0.428, BAYES_00=-2.599] Received: from ly.sdf.com ([127.0.0.1]) by localhost (ly.sdf.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZbAGW0yHcQ0F; Sat, 25 Aug 2007 00:38:23 -0700 (PDT) Received: from ly.sdf.com (ly.sdf.com [216.113.193.83]) by ly.sdf.com (Postfix) with ESMTP id 31C42228391; Sat, 25 Aug 2007 00:38:23 -0700 (PDT) Date: Sat, 25 Aug 2007 00:38:23 -0700 (PDT) From: Tom Samplonius To: Martin Nilsson Message-ID: <27560580.441188027503141.JavaMail.root@ly.sdf.com> In-Reply-To: <46CA7681.3070909@gneto.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [216.113.193.90] Cc: Artem Kuchin , freebsd-stable@freebsd.org Subject: Re: A little story of failed raid5 (3ware 8000 series) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2007 07:39:19 -0000 ----- "Martin Nilsson" wrote: > That is what patrol read is intended to detect before it is a problem. > > In a RAID5 array the checksums are only used when reconstructing data, > > if you have a bad block in a checksum sector it will not be detected > until a drive have failed and you try to rebuild the array, > unfortunately at that time it is too late... > > Beware that OS software solutions like diskcheckd will not find this > as > it only reads the data, not the checksums, it must be done on the > controller. This isn't really accurate. First of all, if the RAID controller isn't confirming checksums before giving the data to the OS, what is the checksum for exactly? It is supposed to be for detecting data corruption, so if the card isn't using the checksum, its kinda of useless. I know some RAID systems do fake their checksums, as they don't actually validate data against the checksums during normal reads because they don't have the processing power. I'd stay away from these type of systems (cough ... Blue Arc ... cough). Second, most RAID systems don't use their own checksums anymore. Netapp is quite famous for their ZCS (zone checksum) drives, and still uses a variation of this technology on their newer systems (which are using 512 sectors). But most RAID vendors just rely on the drives own error detection and correction systems (hamming code based usually, which is actually pretty solid). I'm pretty sure that that 3ware doesn't use any checksums. However, in this particular case, validating checksums would have been unhelpful, since the disk was unreadable. diskcheckd would have detected this issue. It would probably have prevented the problem, if it had been running previously. ZFS is also a good option. It has file level checksumming. ZFS never trusts the disks, and is super paranoid. And ZFS can do background scrubbing too. I can't wait for ZFS in FreeBSD 7, because ZFS in software is going to 10 x better than anything 3ware has. > Regards, > Martin Tom