From owner-freebsd-fs@FreeBSD.ORG Sun May 6 11:59:56 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A422106566B; Sun, 6 May 2012 11:59:56 +0000 (UTC) (envelope-from hackish@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3236F8FC08; Sun, 6 May 2012 11:59:56 +0000 (UTC) Received: by obcni5 with SMTP id ni5so8963270obc.13 for ; Sun, 06 May 2012 04:59:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=33bIbskxxD4Bsjv70Y9Cxc7M30hrvJKprD5mq6XmxeM=; b=bdN8V046l8p87uz+9nE/vcyfzQy/EO2Ogjmo8sp3umbHTLps9ZlNNHZlJSxFu0xQET rfeVnZx1dVHceSovColQIWfZIZzSG6g94YzY03sRCBSko4Ek11LqwjYiw8pPpGIrrsjl kLkHyyY+Rz7ao2dcleZmGRAirnuqZBAFq5Q95kaUFMduiUOws2n4iW5Fd9I0t3mPdbRS ruw/eyCqa+Ec/hartuWlDZ9AkEIgCR046LM3NKXX6MeMgR042Bddj/1FvP7Pgh+pd9Ny SwbUhju/2RTR/ZEVU6oqR7sAEVcpNtIfu1mN3EZBNif81HvpdwViyotMOA5M+2GdkJvT XEIQ== MIME-Version: 1.0 Received: by 10.182.152.72 with SMTP id uw8mr16610179obb.73.1336305595858; Sun, 06 May 2012 04:59:55 -0700 (PDT) Received: by 10.182.27.130 with HTTP; Sun, 6 May 2012 04:59:55 -0700 (PDT) In-Reply-To: References: Date: Sun, 6 May 2012 07:59:55 -0400 Message-ID: From: Michael Richards To: Artem Belevich Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-fs@freebsd.org Subject: Re: ZFS Kernel Panics with 32 and 64 bit versions of 8.3 and 9.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2012 11:59:56 -0000 >> Suspecting a hardware issue all the hardware was replaced. > > Bad memory could indeed do that. Indeed the memory was the bad hardware. > >> I had some difficulty trying to figure out how to mount my old ZFS >> partition but eventually did so. > ... >> zpool import -f -R /altroot 10433152746165646153 olddata >> panics the kernel. Similar panic as seen in all the other kernel versions. > > >> Gives a bit more info about things I've tried. Whatever it is seems to >> affect a wide variety of kernels. > > Kernel is just a messenger here. The root cause is that while ZFS does > go an extra mile or two in order to ensure data consistency, there's > only so much it can do if RAM is bad. Once that kind of problem > happened, it may leave the pool in a state that ZFS will not be able > to deal with out of the box. I believe that the kernel should be able to handle every type of non-hardware corruption without a panic. At present I'm in the process of running dd if=/dev/ad16s1g > zfsimage.dat with hopes I can send that file home and play with it locally. I'm not a kernel hacker but I'll see what I can do. Based on the backtrace I suspect it is happening during scrub: ... trap_fatal trap_pfault calltrap zio_vdev_io_start zio_execute dsl_scan_scrub_cb > First of all -- make a copy of your pool, if it's feasible. > Probability of screwing it up even more is rather high. I assume running the dd on that slice will do this. I think I read somewhere that you can specify a file instead of a block device when loading a zfs filesystem. I'll see what I can do so the problem itself can be fixed. -Michael