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>