On 2012.10.24 22:10, Lucas B. Cohen wrote: > On 2012.10.21 17:44, free...@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, free...@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-unsubscr...@freebsd.org" > _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"