From owner-freebsd-fs@FreeBSD.ORG Wed May 27 21:46:23 2009 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 0A86D106564A for ; Wed, 27 May 2009 21:46:23 +0000 (UTC) (envelope-from andrew@modulus.org) Received: from email.octopus.com.au (email.octopus.com.au [122.100.2.232]) by mx1.freebsd.org (Postfix) with ESMTP id BFABE8FC0C for ; Wed, 27 May 2009 21:46:22 +0000 (UTC) (envelope-from andrew@modulus.org) Received: by email.octopus.com.au (Postfix, from userid 1002) id DFCC81737C; Thu, 28 May 2009 07:46:41 +1000 (EST) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on email.octopus.com.au X-Spam-Level: X-Spam-Status: No, score=-1.4 required=10.0 tests=ALL_TRUSTED autolearn=failed version=3.2.3 Received: from [115.128.0.102] (unknown [115.128.0.102]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: admin@email.octopus.com.au) by email.octopus.com.au (Postfix) with ESMTP id A982E17288; Thu, 28 May 2009 07:46:33 +1000 (EST) Message-ID: <4A1DB3D1.6080003@modulus.org> Date: Thu, 28 May 2009 07:42:41 +1000 From: Andrew Snow User-Agent: Thunderbird 2.0.0.6 (X11/20070926) MIME-Version: 1.0 To: Dmitry Marakasov , freebsd-fs@freebsd.org References: <20090527155342.GA45258@hades.panopticon> In-Reply-To: <20090527155342.GA45258@hades.panopticon> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: ZFS scrub/selfheal not really working 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: Wed, 27 May 2009 21:46:23 -0000 Dmitry Marakasov wrote: > I've recently moved my ZFS pool to 6x1TB hitachi HDDs. However, > those turned out to be quite crappy, and tend to grow unreadable > sectors. Those sectors are really nasty, cause though they are not > readable, they won't be marked as bad and relocated until there's > write failure. And write failure actually never happens - if the sector > is rewritten it's pervectly readable again. It seems like its a good idea to chuck out the whole lot, after first double-checking or replacing your controller, cabling, and power supply. ZFS can't help you :-) > So, my question is why doesn't ZFS rewrite those sectors with READ > errors during scrub? Because of the transactional nature of ZFS it writes the fresh data in a different part of the disk and then marks the old bad sectors as free. An a situation where > there's no parity available, will it narrow down read block size to read > the data and not the unused sectors with curruption? Correct. If no parity is available it will try its best to read as much data as possible and return read errors up to the application layer on sector failure. - Andrew