Re: gmirror gm0 destroyed on shutdown; GPT corrupt

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'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.

This wasn't the idea:) People started putting gmirror on top of
partitioned disk, because it was easier/simpler/faster than creating
mirror, partitioning and copying the data. I for one never put mirror on
already partitioned disk. Although it is sometimes safe to use the last
sector.  Gjournal already looks for UFS and if UFS is in place, it
figures out if the last sector is in use - it isn't if partition size is
not multiple of UFS block size.

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

There were two reasons to use the last sector instead of first:

1. You want to be able to boot from gmirror. If all your data will be
   moved forward your boot sectors and kernel will be harder to find.

2. For recovery reasons you may want to turn off gmirror and still be
   able to access your data.

Note that gmirror can handle the case where disk, slice and partition
share the same last sector - it simply stores provider size in its
metadata, so once it gets disk for tasting it detects its too big and
ignores it, then slice will be given for tasting, but it also has larger
size than expected and will be ignored as well. Finally partition will
be tasted and gmirror configured.

-- 
Pawel Jakub Dawidek                       http://www.wheel.pl
pjd_at_FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!