Date: Wed, 6 Jun 2012 05:26:34 -0600 (MDT) From: Warren Block <wblock@wonkity.com> To: Hiroki Sato <hrs@FreeBSD.org> Cc: doc@FreeBSD.org Subject: Re: Handbook mirroring section Message-ID: <alpine.BSF.2.00.1206060454200.13150@wonkity.com> In-Reply-To: <20120606.185023.497714372668376681.hrs@allbsd.org> References: <alpine.BSF.2.00.1206041331520.945@wonkity.com> <20120605.051840.668781590183332493.hrs@allbsd.org> <alpine.BSF.2.00.1206052220390.10777@wonkity.com> <20120606.185023.497714372668376681.hrs@allbsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 6 Jun 2012, Hiroki Sato wrote: > Warren Block <wblock@wonkity.com> wrote > in <alpine.BSF.2.00.1206052220390.10777@wonkity.com>: > > wb> On Tue, 5 Jun 2012, Hiroki Sato wrote: > wb> > wb> > Warren Block <wblock@wonkity.com> wrote > wb> > in <alpine.BSF.2.00.1206041331520.945@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1206060454200.13150>