Date: Thu, 23 Sep 2004 17:48:31 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Brooks Davis <brooks@one-eyed-alien.net> Cc: Garance A Drosihn <drosih@rpi.edu> Subject: Re: Default support for GPT Message-ID: <200409240048.i8O0mVLk065051@apollo.backplane.com> References: <408F11C5.5030403@freebsd.org> <Pine.NEB.3.96L.1040427220746.51265D-100000@fledge.watson.org> <20040428033948.GA7603@dhcp01.pn.xcllnt.net> <20040921221631.GA14566@odin.ac.hmc.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
:> 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@backplane.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200409240048.i8O0mVLk065051>