From owner-freebsd-fs@FreeBSD.ORG Tue Feb 5 12:08:44 2008 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 3753E16A419; Tue, 5 Feb 2008 12:08:44 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id EAFB413C45A; Tue, 5 Feb 2008 12:08:43 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 864D42084; Tue, 5 Feb 2008 13:08:35 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.3/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 7587F2082; Tue, 5 Feb 2008 13:08:35 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id 5A572844A6; Tue, 5 Feb 2008 13:08:35 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Alexander Leidinger References: <20080204092150.vprsphymqoog8cw4@webmail.leidinger.net> <20080204194936.thzddva9a8s4cwsg@webmail.leidinger.net> Date: Tue, 05 Feb 2008 13:08:35 +0100 In-Reply-To: <20080204194936.thzddva9a8s4cwsg@webmail.leidinger.net> (Alexander Leidinger's message of "Mon\, 04 Feb 2008 19\:49\:36 +0100") Message-ID: <86lk5zy5a4.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, pjd@freebsd.org Subject: Re: ZFS: invalid label -- what is expected? (solved) 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: Tue, 05 Feb 2008 12:08:44 -0000 Alexander Leidinger writes: > After digging around in the ZFS sources and investigating some on-disk > structures (with some confusing results, as the data didn't seem > corrupt to me), I exported the pool. After that all disk where again > in the online state. All are connected via firewire and came back in a > different order (daX) after a reboot (panic). It seems our > implementation wasn't able to handle this without the reimport help. IIRC, it works fine for ATA devices but not for CAM devices (which include SCSI, SAS, USB, Firewire). I'm not sure whether pjd@ is working on that, but when creating a new pool, you can save yourself some trouble down the road by labeling the disks. You can also fix an existing pool by replacing each disk one by one with larger labeled disks - they must be larger, since the label will consume some space and ZFS will refuse to replace a disk in a raidz pool with one that is smaller than the smallest pre-existing disk. As a bonus, you will end up with a larger pool than you started out with :) I've been toying with the idea of writing a gnop-like geom that allows a disk to be referenced by its serial number if the underlying driver is able to supply it. That would bypass glabel's disk-shrinking issue when working on whole disks. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no