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

next in thread | previous in thread | raw e-mail | index | archive | help
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 ?



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