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>
>> 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...
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.)
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
zfs-discuss mailing list