Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 29 Nov 2012 11:47:26 +0200
From:      Andriy Gapon <avg@FreeBSD.org>
To:        Raymond Jimenez <raymondj@caltech.edu>
Cc:        freebsd-fs@FreeBSD.org
Subject:   Re: ZFS kernel panics due to corrupt DVAs (despite RAIDZ)
Message-ID:  <50B72F2E.6080808@FreeBSD.org>
In-Reply-To: <50B72AFD.3040902@caltech.edu>
References:  <50B3E680.8060606@caltech.edu> <50B49F6A.2020509@FreeBSD.org> <50B72AFD.3040902@caltech.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
on 29/11/2012 11:29 Raymond Jimenez said the following:
> Hi Andriy,
> 
> On 11/27/2012 3:09 AM, Andriy Gapon wrote:
>>
>> Perhaps this thread could be of some interest to you:
>> http://thread.gmane.org/gmane.os.freebsd.devel.file-systems/15611/focus=15616
>>
> 
> Thank you for the pointer. Unfortunately, a scrub segfaults in the same
> place with the same output.

My intention was to show the debugging techniques for examining that troublesome
data.

>> For one reason or the other wrong data (but correct looking - proper checksums,
>> etc) got written to the disk.  I'd say use the patch, lift the data and
>> re-create the pool.
> 
> Since it's corrupt data coming from higher levels, is there any
> possibility of getting this data back? Is it worth debugging more to
> add checks to catch this, or are these scenarios be vanishingly
> small?

I do not have very many scenarios in mind which could lead to problems like
that.  And that those that I have look very improbable and "uncatchable".
E.g. buggy kernel code over-writing some portion of a data buffer.  Or some
"rogue" DMA transaction doing the same.


-- 
Andriy Gapon



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50B72F2E.6080808>