From owner-freebsd-stable@FreeBSD.ORG Sun Jul 25 20:50:12 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F08571065788 for ; Sun, 25 Jul 2010 20:50:12 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id D09328FC17 for ; Sun, 25 Jul 2010 20:50:12 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Od89C-0003qI-9c for freebsd-stable@freebsd.org; Sun, 25 Jul 2010 22:50:10 +0200 Received: from 193.33.173.33 ([193.33.173.33]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 25 Jul 2010 22:50:10 +0200 Received: from c.kworr by 193.33.173.33 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 25 Jul 2010 22:50:10 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Volodymyr Kostyrko Date: Sun, 25 Jul 2010 23:49:57 +0300 Lines: 34 Message-ID: <4C4CA375.2030906@gmail.com> References: <4C4C7B4A.7010003@langille.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 193.33.173.33 User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; uk-UA; rv:1.9.1.11) Gecko/20100722 Thunderbird/3.0.6 In-Reply-To: <4C4C7B4A.7010003@langille.org> Cc: stable@freebsd.org Subject: Re: zpool destroy causes panic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jul 2010 20:50:13 -0000 25.07.2010 20:58, 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 0k, i'll try it from here. UNAVAIL means ZFS can't locate correct vdev for this pool member. Even if this file exists it's not used by ZFS because it lacks ZFS headers/footers. You can (I think so) reinsert empty file to the pool with: # zpool replace storage /tmp/sparsefile1.img /tmp/sparsefile1.img ^- pool ^- ZFS old vdev name ^- current file If you replace both files you can theoretically bring pool to fully consistent state. Also you can use md to convert files to devices: # mdconfig -a -t vnode -f /tmp/sparsefile1.img md0 And you can use md0 with your pool. -- Sphinx of black quartz judge my vow.