From owner-freebsd-fs@FreeBSD.ORG Thu Nov 29 09:30:06 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C163FF00; Thu, 29 Nov 2012 09:30:06 +0000 (UTC) (envelope-from raymondj@caltech.edu) Received: from outgoing-mail.its.caltech.edu (outgoing-mail.its.caltech.edu [131.215.239.19]) by mx1.freebsd.org (Postfix) with ESMTP id A29EB8FC12; Thu, 29 Nov 2012 09:30:06 +0000 (UTC) Received: from fire-doxen.imss.caltech.edu (localhost [127.0.0.1]) by fire-doxen-postvirus (Postfix) with ESMTP id B9E8E328021; Thu, 29 Nov 2012 01:29:59 -0800 (PST) X-Spam-Scanned: at Caltech-IMSS on fire-doxen by amavisd-new Received: from [127.0.0.1] (mitsuki.caltech.edu [131.215.167.33]) (Authenticated sender: raymondj) by fire-doxen-submit (Postfix) with ESMTP id C58572E50D2F; Thu, 29 Nov 2012 01:29:56 -0800 (PST) Message-ID: <50B72AFD.3040902@caltech.edu> Date: Thu, 29 Nov 2012 01:29:33 -0800 From: Raymond Jimenez User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Andriy Gapon Subject: Re: ZFS kernel panics due to corrupt DVAs (despite RAIDZ) References: <50B3E680.8060606@caltech.edu> <50B49F6A.2020509@FreeBSD.org> In-Reply-To: <50B49F6A.2020509@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 09:30:06 -0000 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. > 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? Thank you, Raymond Jimenez