Date: Thu, 28 May 2009 12:27:20 -0700 From: Kip Macy <kmacy@freebsd.org> To: Dmitry Marakasov <amdmi3@amdmi3.ru> Cc: freebsd-fs@freebsd.org Subject: Re: ZFS scrub/selfheal not really working Message-ID: <3c1674c90905281227l71ffb208i1cf8251199aef20b@mail.gmail.com> In-Reply-To: <20090528132634.GG45258@hades.panopticon> References: <20090527155342.GA45258@hades.panopticon> <4A1DB3D1.6080003@modulus.org> <20090528132634.GG45258@hades.panopticon>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <amdmi3@amdmi3.ru> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3c1674c90905281227l71ffb208i1cf8251199aef20b>