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>