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
xcl...@mac.com
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
