Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 27 Jun 2009 18:20:49 -0700
From:      Marcel Moolenaar <xcllnt@mac.com>
To:        Ivan Voras <ivoras@freebsd.org>
Cc:        freebsd-current@freebsd.org, freebsd-questions@freebsd.org, freebsd-geom@freebsd.org
Subject:   Re: gmirror gm0 destroyed on shutdown; GPT corrupt
Message-ID:  <2FFFB36F-EFA3-4D92-98A3-692BA2D6F63E@mac.com>
In-Reply-To: <h24v15$70v$1@ger.gmane.org>
References:  <20090625110253.GA31443@mech-cluster238.men.bris.ac.uk> <10FCC74D-6D46-4112-AD89-BBB4C5933957@mac.com> <h24v15$70v$1@ger.gmane.org>

next in thread | previous in thread | raw e-mail | index | archive | help

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






Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2FFFB36F-EFA3-4D92-98A3-692BA2D6F63E>