Handbook mirroring section

[Warren Block]

On Wed, 6 Jun 2012, Hiroki Sato wrote:

> Warren Block <wblock at wonkity.com> wrote
>  in <alpine.BSF.2.00.1206052220390.10777 at wonkity.com>:
>
> wb> On Tue, 5 Jun 2012, Hiroki Sato wrote:
> wb>
> wb> > Warren Block <wblock at wonkity.com> wrote
> wb> >  in <alpine.BSF.2.00.1206041331520.945 at wonkity.com>:
> wb> >
> wb> > wb> It's a little tricky.  What do you think about having two
> wb> > sections,
> wb> > wb> one for how to create a standard mirror from scratch, and one for
> wb> > wb> converting a single-disk system to a mirror?
> wb> >
> wb> > It sounds like a good idea.
> wb>
> wb> Here's a pass at it:
> wb>
> wb> http://www.wonkity.com/~wblock/mirror/book.html
> wb> http://www.wonkity.com/~wblock/mirror/patch-geom-2.diff
> wb>
> wb> Notes:
> wb>
> wb> I tried to factor out common information to the introduction and the
> wb> Troubleshooting section afterward.
> wb>
> wb> diskinfo(8) was used in place of gpart list because the disk capacity
> wb> is in the first three lines, so the command line is simpler.
> wb>
> wb> There is no entity for gnop(8) yet, but I have one locally.
>
> Thanks, I will review the new version.
>
> BTW, do you (or anyone) know the common failure pattern when trying
> to use GPT + gmirror of the whole disk?  IIRC it was a metadata
> corruption but I do not remember when it happens.

When gmirror is used to mirror two disks, metadata goes in the last 
block of each.  If GPT partitioning is used on the mirror, the GPT 
secondary partition table overwrites the mirror metadata because, by 
specification, GPT puts that secondary table at the end of the physical 
drive, rather than inside the gmirror logical device.

There's no good solution.  If the secondary GPT table was put inside the 
gmirror device, it would no longer be standards-compliant.  If the 
mirror is created after the disk GPT partitions are created, it 
overwrites the secondary GPT table.  The mirror will work, but the 
backup GPT is corrupted and /boot/gptboot shows a warning about it on 
each boot.

The alternative is to create a mirror for each GPT partition.  mirror 
metadata goes inside each GPT partition without problem.  However, 
multiple mirrors are running, at least three for a minimal GPT layout of 
one each of freebsd-boot, freebsd-ufs, and freebsd-swap partitions, and
six or more for a split-filesystem layout.  If more than one of those 
mirrors starts to resync at the same time, it will (may?) thrash the 
drive.

The gmirror resync code could have a lock to prevent more than one 
resync at a time.  At present, I don't know if it does, but doubt it.

If gmirror could keep and locate metadata in a special GPT partition, 
whole-disk GPT mirrors would be possible.  That might even be 
GEOM-compatible, with the label code detecting that partition and 
pointing the mirror code to it.