Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 21 Oct 2012 08:44:50 -0700
From:      freebsd@johnea.net
To:        freebsd-questions@freebsd.org
Subject:   Re: 9.1 and gmirror with GPT?
Message-ID:  <50841872.3060305@johnea.net>
In-Reply-To: <alpine.BSF.2.00.1210210827530.70277@wonkity.com>
References:  <5082EAEE.4040609@johnea.net> <50833F78.1060609@bnrlabs.com> <alpine.BSF.2.00.1210210827530.70277@wonkity.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 10/21/2012 07:32 AM, Warren Block wrote:
> On Sun, 21 Oct 2012, Lucas B. Cohen wrote:
>
>> On 2012.10.20 20:17, freebsd@johnea.net wrote:
>>> Just wondering if 9.1 will bring any improvement to the situation of creating a full disk geom mirror while also using GPT partition table?
>>
>> I'm curious about what this is about. Could you refer me to an article
>> or a discussion where this issue is described ?
>
> The GPT backup partition tables goes at the end of a disk, the same
> place gmirror(8) and other GEOM modules keep metadata.  If GPT
> partitions are created inside a mirror, the backup GPT table is no
> longer at the end of the disk.  Hiroki Sato created a patch which fixed
> the gptboot complaints, but there was concern about the nonstandard
> location of the backup table.
>
> At present, MBR partitioning is recommended with gmirror(8).

Thank you Warren. That sums it up.

Lucas,

I found this blag post informative:
https://koitsu.wordpress.com/2012/09/18/using-freebsd-graid-geom-raid/

There are also several interesting posts on Michael Lucas' blag, such as:
http://blather.michaelwlucas.com/archives/1071

This is a good discussion thread that dives into a specific configuration and the implications:
http://freebsd.1045724.n5.nabble.com/disk-partitioning-with-gmirror-gpt-gjournal-RFC-td4912676.html

I've tried to determine which came first GEOM or GPT. It seems GEOM  is actually older, dating from FreeBSD 5, around 2003. While GPT seems to have been integrated with what is now known as UEFI in the later half of that decade.

It also seems "greedy" of GPT to require both the first and last sectors of the disk. This seems to almost guarantee it will have issues with other low level disk formatting tools. Of course, given the history of the "WinTel" partnership, perhaps not interoperating with other tools was a design specification 8-)

https://en.wikipedia.org/wiki/GUID_Partition_Table

In any case, the upcoming wide spread use of UEFI/GPT (i.e. windoze on commodity PCs) compared to the FreeBSD specific nature of GEOM, pretty much insures that it will have to be GEOM that changes to accommodate this conflict.

Even given the denial of who is David and who is Goliath, in the fact that the GEOM developers don't seem to consider this "their" bug:
http://www.freebsd.org/cgi/query-pr.cgi?pr=162147

It seems inevitable that the FreeBSD devs will have to capitulate and find another way to store the GEOM meta-data or we're going to loose the great benefits of whole disk mirrors under GEOM.

[please proceed with tongue in cheek]

This may not occur any time soon, as time progresses at a different rate for BSD than it does with the rest of the world. A great example is this sentence from the Architecture Handbook:

"The Universal Serial Bus (USB) is a new way of attaching devices to personal computers."

Of course USB is roughly 20 years old now 8-)

There are some other great quotes regarding the "new" computer input device, called the "mouse".

[safe to freely operate tongue again]

In any case, it seems my new 9.1-RC2 installation will be MBR partitioned with whole disk GEOM mirror. This motherboard is BIOS based, not UEFI.

It's become fairly de rigueur to accommodate the 4K sector size disks with fdisk and MBR partitioning. As we propel forward into SSDs this may not stay the case.

Any other comments or caveats are very greatly appreciated...

johnea



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50841872.3060305>