Re: Default support for GPT

From: Matthew Dillon <dillon_at_apollo.backplane.com>
Date: Thu, 23 Sep 2004 17:48:31 -0700 (PDT)
:> Question 1:
:> Since David's comments in April, Matt has changed Dragonfly (based
:> on FreeBSD 4.x) to support 16 partitions in the standard BSD label.
:> How hard would it be to install those changes in 6.x-current?
:> Brooks mentioned the boot-blocks, and I recall that Matt had to
:> move them up.  Is there any reason to *not* move the boot blocks?
:> (not in 5.x, certainly, but in 6.x-current)
:
:I believe PHK has a reason, but I don't know what it is.

    The location of the boot2 code used to be offset sufficiently from
    the partition table that the partition table could be extended, and I
    even considered doing this a few years ago (but got hung up on available
    minor device bits).  

    However, at some point someone moved the boot2 code so it sits right up
    against the 8-partition partition table, presumably in order to make
    room for the UFS1+UFS2 support.  For DragonFly I shifted it back to its
    old location and then extended the partition table to 16 partitions,
    but DragonFly does not support UFS2 so there's room.

    Eventually DFly is going to redo the entire partition table mechanism,
    probably moving to a dynamic [offset,size] for the boot2 area and
    [offset,size] for the partition table area, stored in the first sector
    of boot2 (remember it has to be simple enough for boot1 to be able to
    load boot2, and boot1 has < 512 bytes to work with).  This will be a
    pre-req for any support for booting off non UFS1 filesystems and will,
    of course, require the disk to be freshly partitioned.

    I considered GPT but I want to have much more control over the DragonFly
    'partitions' then I believe GPT offers.  e.g. we need to be able to
    uniquely identify partitions in a WAN environment, store the core RAID
    topology, and so on and so forth... everything you need to operate in
    a clustered environment really has to be made part of the partition table.

:an appropriatly named parition.  Note that if Intel follows through on
:their plans to make EFI standard on IA32 servers, we won't have a choice
:about using GPT as the native partition table.

    I expect there will be a few years where both will be supported by
    BIOSes, simply because otherwise existing Windoz systems might not
    work.  However, even in a native GPT environment I don't think I
    would want to use it to specify BSD partitions.

:There's a post from marcel on this topic, I can't remember where.  It
:might have been on developers.  IIRC the big things a boot block that
:understands enough GPT to find a root partition and boot.  It's worth
:noting that GPT labels look just like MBR labels except that normally
:they reserve the whole disk (or at least the addressable 2TB) as a
:single partition for them selves and store the real data elsewhere.  It
:may be possiable to build GPTs that have some MBR slices as well, I'm
:not sure what the standard says.
:
:-- Brooks

    Oh ick.  Just what I expect from Intel and MS, though.

					-Matt
					Matthew Dillon 
					<dillon_at_backplane.com>
Received on Thu Sep 23 2004 - 22:48:32 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:13 UTC