From owner-freebsd-fs@FreeBSD.ORG Tue Jan 8 15:21:06 2008 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 241C416A420; Tue, 8 Jan 2008 15:21:06 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id F279513C46E; Tue, 8 Jan 2008 15:21:05 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id m08FFJtH014016; Tue, 8 Jan 2008 08:15:20 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <47839386.8020203@samsco.org> Date: Tue, 08 Jan 2008 08:15:18 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.11) Gecko/20071128 SeaMonkey/1.1.7 MIME-Version: 1.0 To: ticso@cicely.de References: <477B16BB.8070104@freebsd.org> <20080102070146.GH49874@cicely12.cicely.de> <477B8440.1020501@freebsd.org> <200801031750.31035.peter.schuller@infidyne.com> <477D16EE.6070804@freebsd.org> <20080103171825.GA28361@lor.one-eyed-alien.net> <6a7033710801061844m59f8c62dvdd3eea80f6c239c1@mail.gmail.com> <20080107135925.GF65134@cicely12.cicely.de> <47830BC0.5060100@samsco.org> <20080108083822.GL76422@cicely12.cicely.de> In-Reply-To: <20080108083822.GL76422@cicely12.cicely.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Tue, 08 Jan 2008 08:15:21 -0700 (MST) X-Spam-Status: No, score=-1.4 required=5.4 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: freebsd-fs@freebsd.org, Brooks Davis , Tz-Huan Huang Subject: Re: ZFS i/o errors - which disk is the problem? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2008 15:21:06 -0000 Bernd Walter wrote: > On Mon, Jan 07, 2008 at 10:36:00PM -0700, Scott Long wrote: >> Bernd Walter wrote: >>> On Mon, Jan 07, 2008 at 10:44:13AM +0800, Tz-Huan Huang wrote: >>>> 2008/1/4, Brooks Davis : >>> The data is corrupted by controller and/or disk subsystem. >>> You have no other data sources for the broken data, so it is lost. >>> The only garantied way is to get it back from backup. >>> Maybe older snapshots/clones are still readable - I don't know. >>> Nevertheless data is corrupted and that's the purpose for alternative >>> data sources such as raidz/mirror and at last backup. >>> You shouldn't have ignored those errors at first, because you are >>> running with faulty hardware. >>> Without ZFS checksumming the system would just process the broken >>> data with unpredictable results. >>> If all those errors are fresh then you likely used a broken RAID >>> controller below ZFS, which silently corrupted syncronity and then >>> blow when disk state changed. >>> Unfortunately many RAID controllers are broken and therefor useless. >>> >> Huh? Could you be any more vague? Which controllers are broken? Have >> you contacted anyone about the breakage? Can you describe the breakage? >> I call bullshit, pure and simple. > > Just go back a few mails in the same thread were someone fixed CRC > errors by updating the RAID controller firmware. > I'm amazed how often I read something like this lately. > And if you read the whole thread then you will notice that we are > currently talking about another person which has corrupted data on > a RAID disk - not sure if this is the controller, a drive or the > drivers, but something is faulty here and I wouldn't be surprised > if it is the controller. > And then there are so many RAID controllers without backed memory or > other mechanism to garantie syncronity for the disks, which I call > broken by design. > You know yourself how important syncronity is for RAID, especially > when it comes to parity based RAID and you know how fragile it is > when it comes to power failure. > Your argument is complete hearsay and poorly formed opinion. That's fine, just be honest about it and don't mislead others into thinking that you know what you're talking about when it comes to RAID. Scott