Date: Mon, 29 Jun 2009 16:00:03 -0500 From: "Rick C. Petty" <rick-freebsd2008@kiwi-computer.com> To: Marcel Moolenaar <xcllnt@mac.com> Cc: Ivan Voras <ivoras@freebsd.org>, freebsd-geom@freebsd.org Subject: Re: gmirror gm0 destroyed on shutdown; GPT corrupt Message-ID: <20090629210003.GA24038@keira.kiwi-computer.com> In-Reply-To: <2FFFB36F-EFA3-4D92-98A3-692BA2D6F63E@mac.com> References: <20090625110253.GA31443@mech-cluster238.men.bris.ac.uk> <10FCC74D-6D46-4112-AD89-BBB4C5933957@mac.com> <h24v15$70v$1@ger.gmane.org> <2FFFB36F-EFA3-4D92-98A3-692BA2D6F63E@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[[ Removing the double cross-post, since this is GEOM-specific ]]
On Sat, Jun 27, 2009 at 06:20:49PM -0700, Marcel Moolenaar wrote:
>
> Using the last sector is not only flawed because it creates a race
> condition,
It shouldn't create a race condition. If you add a gpt to a mirror, the
gpt backup will be the last sector in the mirror, which is the last sector
of the disk minus 1. If you want to create the gpt first in anticipation
of putting a mirror around it, you would need to do
gpt add -s <numsectors-1> ...
where "numsectors" is the output of:
diskinfo <diskdevice> | awk '{print $4}'
In general GEOM requires you to build your topology inward: you're not
supposed to create a mirror out of a previously-generated gpt because
that's like inserting a new class in between the provider and consumer
which doesn't make sense.
> 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 don't believe this was the assumption, nor the reason for this
"feature".
> I think it's better to change gmirror to use the first sector on the
> provider.
Ack! That would be quite disruptive as you would have to increment the
sector offset number in the partition table (gpt or mbr) to make the
partition bootable. I thought most geom schemes added their metadata at
the end, since it fits the "container" philosophy. One exception is
gvinum and it's quite painful to make a gvinum root partition bootable.
It's even more painful if you ever wish to "undo" it. I've had terrible
luck trying to remove gvinum from the picture, whereas gmirror and others
are quite easy.
> 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...
No, but people would roar rather loudly if the partition isn't bootable.
To make it bootable, knowledge of each GEOM provider would have to be
embedded into boot2, which is already quite full. Sure it's okay for some
providers (like raid5 or striping) which you can't boot to already, but
such things as simple as mirroring should work to some extent with or
without GEOM.
-- Rick C. Petty
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090629210003.GA24038>