From owner-freebsd-stable@FreeBSD.ORG Wed Feb 10 09:29:16 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 5739C106566C for ; Wed, 10 Feb 2010 09:29:16 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id D5F3D8FC19 for ; Wed, 10 Feb 2010 09:29:15 +0000 (UTC) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id o1A9TDxU012229; Wed, 10 Feb 2010 10:29:14 +0100 Received: from pmp.uni-hannover.de (arc.pmp.uni-hannover.de [130.75.117.1]) by www.pmp.uni-hannover.de (Postfix) with SMTP id 2D10724; Wed, 10 Feb 2010 10:29:13 +0100 (CET) Date: Wed, 10 Feb 2010 10:29:13 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: Marius =?ISO-8859-1?Q?N=FCnnerich?= Message-Id: <20100210102913.091f64ef.gerrit@pmp.uni-hannover.de> In-Reply-To: References: <20100209150606.ddba52dc.gerrit@pmp.uni-hannover.de> <54e63c321002091227w15657c54oeb2295efc4c43980@mail.gmail.com> <20100210092412.5a06d98e.gerrit@pmp.uni-hannover.de> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.4; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.2.10.91819 Cc: Elliot Finley , freebsd-stable@freebsd.org Subject: Re: zpool vdev vs. glabel 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: Wed, 10 Feb 2010 09:29:16 -0000 On Wed, 10 Feb 2010 10:18:49 +0100 Marius N=FCnnerich wrote about Re: zpool vdev vs. glabel: MN> It seems there is some kind of race condition with zfs either picking MN> up the disk itself or the label device for the same disk. I guess it's MN> which ever it probes first. This could explain it. However, it seems that zfs sticks to the da device once it changed it's mind. Meanwhile I discovered one more system where is obviously has happened (although I cannot say when: luna# zpool status pool: tank state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 raidz1 ONLINE 0 0 0 label/disk-1 ONLINE 0 0 0 da0 ONLINE 0 0 0 label/disk-2 ONLINE 0 0 0 label/disk-3 ONLINE 0 0 0 errors: No known data errors MN> I wrote the GPT part of glabel for using MN> it in situations like this, I had not a single report of this kind of MN> problem with the gpt labels. Maybe you can try them too? Yeah, I just have to look into how gpt labels work. I did not use them at all up to now. cu Gerrit