# gmirror questions



## jem (Aug 16, 2010)

I've been considering using gmirror to mirror the disks on some of my lower-spec boxes, ones that aren't really up to running ZFS.

I note from the gmirror(8) man page the following statement:



> The gmirror utility uses on-disk metadata (stored in the provider's last sector) to store all needed information.



This raises the question of compatibility with disks that are partitioned using GPT.  All my FreeBSD boxes use GPT now as I much prefer it over the legacy-laden MBR scheme.  GPT places a secondary header in the last sector of a disk and the man page line above suggests that gmirror's metadata would clobber that.

So I'm wondering if a gmirror can be built out of partitions instead of whole disks?  Would the partition be the "provider" in that case and therefore would the gmirror metadata would be placed in the last sector of the partition instead than the last sector of the disk?

If I had a disk with numerous partitions would there be problems caused by creating seperate gmirrors for each partition?

Thanks for any advice.


----------



## phoenix (Aug 16, 2010)

I believe it all depends on the order that you do things.  GEOM is smart enough to not write blindly to "last sector of disk" but to instead write to "last sector of GEOM provider".

IOW, use the raw disk device as the provider for gmirror.  This writes the gmirror metadata to the last sector of the disk.

Then partition the gmirror device using gpart.  This saves the gpt metadata to the last sector of the gmirror device.

If you want to fancy, to see how it all works, you can use glabel on the raw device, then gmirror the labels, then gstripe the gmirrors, and finally gpt partition the gstripe.    Each piece of metadata is written to the last sector of the GEOM provider "below" it.

(However, my understanding of GEOM may not be 100% accurate, and confirming this via reading the code or asking on the -hackers or -fs mailing list may be required.)


----------

