On 4 June 2012 15:06, Christian Weisgerber <na...@mips.inka.de> wrote:
> Peter Kay <syllops...@syllopsium.co.uk> wrote: > > > GPT is a foregone conclusion unless you are blind to the future. The only > > alternative is OS specific disk hackery, and that does no-one any > favours. > > Well, OpenBSD/i386 (and now /amd64) has used such hackery since the > very beginning and doesn't fare too badly with it. > > Back in the day, I used to run FreeBSD with "dangerously dedicated" > disks that didn't have MBR partitioning at all, just a pure BSD > disklabel. (FreeBSD eventually discouraged/abolished this due to > some BIOSes refusing to boot disks without an MBR partition table.) > > Let's leave aside the boot techie stuff which I included mainly as a interesting (to me) related point. I don't have a particular issue with most of the disk hackery that OpenBSD currently performs, but the key detail is that at least under x86, powermac and sgi platforms [1] it seems to work within the boundaries of the native disk partitioning by using a custom disk format, performing custom partition labelling or using a native partition as a container for a custom format (disklabel inside MBR partition). That strategy tends to co-exist quite nicely with other tools/BIOSes/OSes that might inadvertently read the disk (with the exception of the pure BSD disklabel as you say). That's not the case with storing data outside the 2TB limit enforced by the MBR design. It seems to me it would be more sensible to stick a disklabel inside a new OpenBSD GPT partition type. All the data are successfully protected by a known standard and both the users and disk tools are happy. I'll grant that multiboot is a rare and usually inadvisable configuration (although I'd suggest it's useful on laptops sometimes), but protecting all the data on a uniboot system sounds advisable. GPT's main selling point is that it is superior to MBR if you use > either as your native partitioning scheme. That doesn't apply to > OpenBSD. > > GPT is also useful if you want different operating systems to coexist > on the same disk. For OpenBSD, that's more of a grudgingly tolerated > configuration and not recommended. > > [1] I don't have experience of the other platforms apart than sparc, and that was some time ago.
