From owner-freebsd-fs@FreeBSD.ORG Fri Nov 16 16:13:19 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 3C93459A; Fri, 16 Nov 2012 16:13:19 +0000 (UTC) (envelope-from zeising@daemonic.se) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) by mx1.freebsd.org (Postfix) with ESMTP id 683588FC08; Fri, 16 Nov 2012 16:13:16 +0000 (UTC) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 7377340014; Fri, 16 Nov 2012 17:13:14 +0100 (CET) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 686744000C; Fri, 16 Nov 2012 17:13:14 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.3.1 X-Spam-Score: 0.0 Received: from mx.daemonic.se (mx.daemonic.se [IPv6:2001:470:dca9:0:1::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id E265F40005; Fri, 16 Nov 2012 17:13:13 +0100 (CET) Received: from mailscanner.daemonic.se (mailscanner.daemonic.se [IPv6:2001:470:dca9:0:1::6]) by mx.daemonic.se (Postfix) with ESMTPS id 3Y34HD4fsdz8hVn; Fri, 16 Nov 2012 17:13:12 +0100 (CET) X-Virus-Scanned: amavisd-new at daemonic.se Received: from mx.daemonic.se ([10.1.0.3]) (using TLS with cipher CAMELLIA256-SHA) by mailscanner.daemonic.se (mailscanner.daemonic.se [10.1.0.6]) (amavisd-new, port 10025) with ESMTPS id LWgNZDAa99L3; Fri, 16 Nov 2012 17:13:10 +0100 (CET) Received: from mail.daemonic.se (mail.daemonic.se [IPv6:2001:470:dca9:0:1::4]) by mx.daemonic.se (Postfix) with ESMTPS id 3Y34HB1ThRz8hVm; Fri, 16 Nov 2012 17:13:10 +0100 (CET) Received: from tifa.daemonic.se (tifa.daemonic.se [IPv6:2001:470:dca9:1::6]) by mail.daemonic.se (Postfix) with ESMTPSA id 3Y34H954Pnz9Ctj; Fri, 16 Nov 2012 17:13:09 +0100 (CET) Received: from tifa.daemonic.se (localhost [IPv6:::1]) by tifa.daemonic.se (Postfix) with ESMTP id 448F5228F2; Fri, 16 Nov 2012 17:13:09 +0100 (CET) Message-ID: <50A66615.9060906@daemonic.se> Date: Fri, 16 Nov 2012 17:13:09 +0100 From: Niclas Zeising User-Agent: Mutt/1.5.21 MIME-Version: 1.0 To: Andriy Gapon Subject: Re: problem booting to multi-vdev root pool [Was: kern/150503: [zfs] ZFS disks are UNAVAIL and corrupted after reboot] References: <509D1DEC.6040505@FreeBSD.org> <50A27243.408@madpilot.net> <50A65F83.5000604@FreeBSD.org> In-Reply-To: <50A65F83.5000604@FreeBSD.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-fs@FreeBSD.org, freebsd-current@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: Fri, 16 Nov 2012 16:13:19 -0000 On 11/16/12 16:45, Andriy Gapon wrote: > on 13/11/2012 18:16 Guido Falsi said the following: >> My idea, but is just a speculation, i could be very wrong, is that the geom >> tasting code has some problem with multiple vdev root pools. > > Guido, > > you are absolutely correct. The code for reconstructing/tasting a root pool > configuration is a modified upstream code, so it inherited a limitation from it: > the support for only a single top-level vdev in a root pool. > I have an idea how to add the missing support, but it turned out not to be > something that I can hack together in couple of hours. > > So, instead I wrote the following patch that should fall back to using a root pool > configuration from zpool.cache (if it's present there) for a multi-vdev root pool: > http://people.freebsd.org/~avg/zfs-spa-multi_vdev_root_fallback.diff > > The patch also fixes a minor (single-time) memory leak. > > Guido, Bartosz, > could you please test the patch? > > Apologies for the breakage. > Just to confirm, since I am holding back an update pending on this. If I have a raidz root pool, with three disks, like this: NAME STATE READ WRITE CKSUM zroot ONLINE 0 0 0 raidz1-0 ONLINE 0 0 0 gpt/disk0 ONLINE 0 0 0 gpt/disk1 ONLINE 0 0 0 gpt/disk2 ONLINE 0 0 0 Then I'm fine to update without issues. the problem is only if, as an example, you have a mirror with striped disks, or a stripe with mirrored disks, which it seems to me the original poster had. Am I correct, and therefore ok to update? Regards! -- Niclas Zeising