From owner-freebsd-stable@FreeBSD.ORG Sun Jul 25 20:37:49 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 7AD971065676 for ; Sun, 25 Jul 2010 20:37:49 +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 43C228FC08 for ; Sun, 25 Jul 2010 20:37:49 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Od7xD-0006vO-Qa for freebsd-stable@freebsd.org; Sun, 25 Jul 2010 22:37:47 +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:37:47 +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:37:47 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Volodymyr Kostyrko Date: Sun, 25 Jul 2010 23:37:37 +0300 Lines: 18 Message-ID: <4C4CA091.1090406@gmail.com> References: <4C4C7B4A.7010003@langille.org> <20100725201811.GA33611@icarus.home.lan> 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: <20100725201811.GA33611@icarus.home.lan> Cc: stable@freebsd.org, Dan Langille 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:37:49 -0000 25.07.2010 23:18, Jeremy Chadwick wrote: > 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? Just hacking it. Each ZFS device which is part of the pool tracks all other devices which are part of the pool with their sizes, device ids, last known points. It doesn't know that /tmp/sparsefile[12].img is part of the pool, yet it does know that pool have had some /tmp/sparsefile[12].img before and now they can't be found or current contents doesn't look like ZFS device. Can you try moving current files to /tmp/sparsefile[34].img and then readd them to the pool with zpool replace? One by one please. -- Sphinx of black quartz judge my vow.