9.1 and gmirror with GPT?

Lucas B. Cohen lbc at bnrlabs.com
Wed Oct 24 20:20:28 UTC 2012


On 2012.10.24 22:10, Lucas B. Cohen wrote:
> On 2012.10.21 17:44, freebsd at johnea.net wrote:
>> 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 at 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.
>>
> 
>> 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-)
> 
> What surprises me is that GEOM mirror provides a logical device that
> doesn't abstract the parts that hold its own metadata. It so happens
> that GPT wants to use one of those parts, but doesn't creating an MBR
> partition that spans the whole provider up to the last logical block
> create a similar - but in this case latent - problem, once that last
> block is written to by a filesystem living inside that partition ?

Nevermind, I just got this. It's code working at the physical device
level that gets confused and complains about a missing GPT backup in the
single disks it examines; not code that's working against the provided
GEOM mirror once it's assembled.

My first understanding felt so weird, I knew I was missing something !

I guess Hiroki Sato's patch Warren mentions doesn't answer the "danger
of overwriting gmirror metadata by an "unfriendly" UEFI-BIOS", though.

> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"
> 



More information about the freebsd-questions mailing list