From owner-freebsd-fs@FreeBSD.ORG Tue Jan 8 15:21:33 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 C304916A46B; Tue, 8 Jan 2008 15:21:33 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 95C3413C50D; Tue, 8 Jan 2008 15:21:33 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id m08FLPTZ085260; Tue, 8 Jan 2008 16:21:25 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [10.1.1.14]) by cicely5.cicely.de (8.13.4/8.13.4) with ESMTP id m08FLFRC087412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Jan 2008 16:21:15 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.13.4/8.13.3) with ESMTP id m08FLEiU079883; Tue, 8 Jan 2008 16:21:14 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.13.4/8.13.3/Submit) id m08FLEdq079882; Tue, 8 Jan 2008 16:21:14 +0100 (CET) (envelope-from ticso) Date: Tue, 8 Jan 2008 16:21:14 +0100 From: Bernd Walter To: Scott Long Message-ID: <20080108152114.GF79270@cicely12.cicely.de> References: <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> <47839386.8020203@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47839386.8020203@samsco.org> X-Operating-System: FreeBSD cicely12.cicely.de 5.4-STABLE alpha User-Agent: Mutt/1.5.9i X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, BAYES_00=-2.599 autolearn=ham version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on cicely12.cicely.de Cc: freebsd-fs@freebsd.org, Brooks Davis , ticso@cicely.de, 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 Reply-To: ticso@cicely.de List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2008 15:21:33 -0000 On Tue, Jan 08, 2008 at 08:15:18AM -0700, Scott Long wrote: > 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. Go back into the thread and tell the people their facts are not true and they are just dreaming that they have data corruptions and if they wake up their data is back alive. -- B.Walter http://www.bwct.de http://www.fizon.de bernd@bwct.de info@bwct.de support@fizon.de