On Tue, Oct 18, 2011 at 9:12 PM, Tim Cook <t...@cook.ms> wrote: > > > On Tue, Oct 18, 2011 at 3:06 PM, Peter Tribble <peter.trib...@gmail.com> > wrote: >> >> On Tue, Oct 18, 2011 at 8:52 PM, Tim Cook <t...@cook.ms> wrote: >> > >> > Every scrub I've ever done that has found an error required manual >> > fixing. >> > Every pool I've ever created has been raid-z or raid-z2, so the silent >> > healing, while a great story, has never actually happened in practice in >> > any >> > environment I've used ZFS in. >> >> You have, of course, reported each such failure, because if that >> was indeed the case then it's a clear and obvious bug? >> >> For what it's worth, I've had ZFS repair data corruption on >> several occasions - both during normal operation and as a >> result of a scrub, and I've never had to intervene manually. >> >> -- >> -Peter Tribble >> http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ > > > Given that there are guides on how to manually fix the corruption, I don't > see any need to report it. It's considered acceptable and expected behavior > from everyone I've talked to at Sun... > http://dlc.sun.com/osol/docs/content/ZFSADMIN/gbbwl.html
If you have adequate redundancy, ZFS will - and does - repair errors. The document you quote is for the case where you don't actually have adequate redundancy: ZFS will refuse to make up data for you, and report back where the problem was. Exactly as designed. (And yes, I've come across systems without redundant storage, or had multiple simultaneous failures. The original statement was that if you have redundant copies of the data or, in the case of raidz, enough information to reconstruct it, then ZFS will repair it for you. Which has been exactly in accord with my experience.) -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
