From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 01:20:51 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5DA81065673; Sun, 28 Jun 2009 01:20:51 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout023.mac.com (asmtpout023.mac.com [17.148.16.98]) by mx1.freebsd.org (Postfix) with ESMTP id 7F2CF8FC22; Sun, 28 Jun 2009 01:20:51 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii; format=flowed; delsp=yes Received: from macbook-pro.lan.xcllnt.net (mail.xcllnt.net [75.101.29.67]) by asmtp023.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KLX007KJD2QER50@asmtp023.mac.com>; Sat, 27 Jun 2009 18:20:51 -0700 (PDT) From: Marcel Moolenaar In-reply-to: Date: Sat, 27 Jun 2009 18:20:49 -0700 Message-id: <2FFFB36F-EFA3-4D92-98A3-692BA2D6F63E@mac.com> References: <20090625110253.GA31443@mech-cluster238.men.bris.ac.uk> <10FCC74D-6D46-4112-AD89-BBB4C5933957@mac.com> To: Ivan Voras X-Mailer: Apple Mail (2.1067.4) Cc: freebsd-current@freebsd.org, freebsd-questions@freebsd.org, freebsd-geom@freebsd.org Subject: Re: gmirror gm0 destroyed on shutdown; GPT corrupt X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 01:20:52 -0000 On Jun 27, 2009, at 4:15 AM, Ivan Voras wrote: > Marcel Moolenaar wrote: >> On Jun 25, 2009, at 4:02 AM, Anton Shterenlikht wrote: >>> dev_taste(DEV,mirror/gm0) >>> g_part_taste(PART,mirror/gm0) >>> >>> GEOM: mirror/gm0: the secondary GPT table is corrupt or invalid. >>> GEOM: mirror/gm0: using the primary only -- recovery suggested. >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> You created the mirror after the GPT, which means you destroyed >> the GPT backup header. gmirror uses the last sector on the disk >> for metadata and that by itself is a cause for various problems. >> It's better to use gmirror per partition. > > Or create the GPT partition inside the gmirror device - then the GPT > backup table will be at last_sector-1, but... > >> You could run into a race condition between GPT and gmirror and >> GPT winning (again the result of gmirror using the last sector >> on a disk for metadata). > > unfortunately this could still happen, and will lead to the same > error if GPT is tasted first, since it is embedded in the first > sector and will assume the whole drive is available to GPT, and will > then proceed to not find its backup data in the last sector. > > It looks to me like GEOM classes should have a "priority" field for > tasting. Any objections to that idea? Using the last sector is not only flawed because it creates a race condition, it's flawed in the assumption that you can always make a geom part of a mirror by storing meta-data on the geom without causing corruption. This whole idea of using the last sector was so that a fully partitioned disk with data could be turned into a mirrored disk. A neat idea, but hardly the basis for a generic mirroring implementation when it silently corrupts a disk. I think it's better to change gmirror to use the first sector on the provider. This never creates a race condition and as such, you don't need to invent a priority scheme, that has it's own set of flaws on top of it. The only downside is that it's not easy to make a fully partitioned and populated disk part of a mirror: one would need to move the data forward one sector to free the first sector. This we can actually do by inserting a GEOM that does it while I/O is still ongoing. The good thing is: we need a class that does exactly this for implementing the "move" verb in gpart. In other words: Solving the problem that putting the metadata in the first sector creates, can and will be re-used in implementing the gpart "move partition" feature. I doubt anyone will complain that the creation of a mirror brings with it a few hours of disk activity that does not inhibit normal operation... -- Marcel Moolenaar xcllnt@mac.com