Re: gmirror gm0 destroyed on shutdown; GPT corrupt

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_at_mac.com