Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 25 Jul 2010 13:18:11 -0700
From:      Jeremy Chadwick <freebsd@jdc.parodius.com>
To:        Dan Langille <dan@langille.org>
Cc:        stable@freebsd.org
Subject:   Re: zpool destroy causes panic
Message-ID:  <20100725201811.GA33611@icarus.home.lan>
In-Reply-To: <4C4C7B4A.7010003@langille.org>
References:  <4C4C7B4A.7010003@langille.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jul 25, 2010 at 01:58:34PM -0400, Dan Langille wrote:
> [...]
>         NAME                      STATE     READ WRITE CKSUM
>         storage                   ONLINE       0     0     0
>           raidz2                  ONLINE       0     0     0
>             gpt/disk01            ONLINE       0     0     0
>             gpt/disk02            ONLINE       0     0     0
>             gpt/disk03            ONLINE       0     0     0
>             gpt/disk04            ONLINE       0     0     0
>             gpt/disk05            ONLINE       0     0     0
>             /tmp/sparsefile1.img  UNAVAIL      0     0     0 corrupted data
>             /tmp/sparsefile2.img  UNAVAIL      0     0     0 corrupted data
> 
> [...]
>
> Another attempt to destroy the array created a panic.
> Suggestions as to how to remove this array and get started again?
>
> [...]
>
> FreeBSD kraken.unixathome.org 8.0-STABLE FreeBSD 8.0-STABLE #0: Fri Mar  5 00:46:11 EST 2010 dan@kraken.example.org:/usr/obj/usr/src/sys/KRAKEN  amd64

1) Try upgrading the system (to 8.1-STABLE).  There have been numerous
changes to ZFS on RELENG_8 since March 5th.  I don't know if any of them
would address your problem.

http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c#rev1.8.2.4
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c#rev1.8.2.3
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c#rev1.8.2.2
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c#rev1.8.2.1

2) Try bringing the system down into single-user mode and zeroing out
the first and last 64kbytes of each gpt/diskXX (you'll have to figure
this out on your own, I'm not familiar with GPT) so that the ZFS
metadata goes away.

Footnote: can someone explain to me how ZFS would, upon reboot, know
that /tmp/sparsefile[12].img are part of the pool?  How would ZFS taste
metadata in this situation?

-- 
| Jeremy Chadwick                                   jdc@parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                  Mountain View, CA, USA |
| Making life hard for others since 1977.              PGP: 4BD6C0CB |




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