From owner-freebsd-fs@FreeBSD.ORG Thu May 28 19:27:22 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 25B9D1065678 for ; Thu, 28 May 2009 19:27:22 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by mx1.freebsd.org (Postfix) with ESMTP id CF15C8FC1D for ; Thu, 28 May 2009 19:27:21 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so3017392ywe.13 for ; Thu, 28 May 2009 12:27:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=SPFWzG9zw3X6ShxyZu8UDBvBrrjcvfk/mG+5i7TOXfk=; b=K6ahAe3UWvvVwuYVwyZnEW3Mh7CoX7k/FvBj6bzkBFWth6ouV1qRh8LG88t7T6jMp3 gD8LrCQGvWteugEs+G72aMGeWHO+4QG9VHlaZfLq66p1Loi08flc4j51wYtX3LJjFX8z iRTrgebOG8D82O58Mt3izaCV7OWxsLfSHHeSI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=blw1+MnTXWxS4FaVIgki8yJ0x4EnPWQTrw0VLyRxEztK7RftFUshIVmDIPzxhPBs1n sw/w9Wh5ABCEZs/DfnQsGuSgDrqrXcMOzVRKNfUKIW12vs3PJQMtJLjfXMZsw8tuMgeb +RoQYSyQWzJSpCAgIxWDV5M7f92V8WrGK7WQo= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.100.166.13 with SMTP id o13mr2679020ane.103.1243538840983; Thu, 28 May 2009 12:27:20 -0700 (PDT) In-Reply-To: <20090528132634.GG45258@hades.panopticon> References: <20090527155342.GA45258@hades.panopticon> <4A1DB3D1.6080003@modulus.org> <20090528132634.GG45258@hades.panopticon> Date: Thu, 28 May 2009 12:27:20 -0700 X-Google-Sender-Auth: 93bdcb0fa477642c Message-ID: <3c1674c90905281227l71ffb208i1cf8251199aef20b@mail.gmail.com> From: Kip Macy To: Dmitry Marakasov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org 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: Thu, 28 May 2009 19:27:22 -0000 As I commented earlier, fletcher2 is not that much better than the TCP checksum. If you want to use ZFS as a means of salvaging problematic hardware, crc32 would be more appropriate. Cheers, Kip On Thu, May 28, 2009 at 6:26 AM, Dmitry Marakasov wrote: > * Andrew Snow (andrew@modulus.org) 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. =A0Those 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 secto= r >> > 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. > > Yes, that's in plans. The box also reboots sometimes, loosing one of > HDDs from raid (until next power cycyle). I suspect power supply. > > Anyway, it's a nice test for ZFS :) > >> =A0 ZFS can't help you :-) > > No, actually in the current age of buggy hardware, ZFS is the only thing > that can help :) > >> > 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. > > Ok, then why does read errors pop up again after scrub, while they > should have been recovered? > > Actually, I've forgotten to look into logs, and they say that ZFS > shrinks read block size (down to a sector size sometimes), so > corrupted sectors likely _are_ used for data, and they don't seem > to be recovered, while they should. > >> > there's no parity available, will it narrow down read block size to re= ad >> > the data and not the unused sectors with curruption? >> >> Correct. =A0If no parity is available it will try its best to read as mu= ch >> data as possible and return read errors up to the application layer on >> sector failure. > > Uh huh. That would be less worries if not the thing above. > > -- > Dmitry Marakasov =A0 . =A0 55B5 0596 FF1E 8D84 5F56 =A09510 D35A 80DD F9D= 2 F77D > amdmi3@amdmi3.ru =A0..: =A0jabber: amdmi3@jabber.ru =A0 =A0http://www.amd= mi3.ru > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > --=20 When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke