Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 24 Oct 2012 22:20:29 +0200
From:      "Lucas B. Cohen" <lbc@bnrlabs.com>
To:        freebsd-questions@freebsd.org
Subject:   Re: 9.1 and gmirror with GPT?
Message-ID:  <50884D8D.2010006@bnrlabs.com>
In-Reply-To: <50884B4A.1030603@bnrlabs.com>
References:  <5082EAEE.4040609@johnea.net> <50833F78.1060609@bnrlabs.com> <alpine.BSF.2.00.1210210827530.70277@wonkity.com> <50841872.3060305@johnea.net> <50884B4A.1030603@bnrlabs.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 2012.10.24 22:10, Lucas B. Cohen wrote:
> On 2012.10.21 17:44, freebsd@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@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@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org"
> 




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