Re: Default support for GPT

[apology for the series of quotes, but they all include info
that I want to refer to...]

Back on Apr 27/04, Marcel Moolenaar wrote:
>On Tue, Apr 27, 2004, Robert Watson wrote:
>  >
>  > The GPT partition table includes an fdisk compatibility partition
>  > table in it to describe the first partition (and reserve the rest?).
>  > That way you can boot from an older BIOS even if you lay down GPT
>  > over the entire boot disk, or at least I believe that was the intent.
>
>Not quite. The MBR on a disk with GPT is expected to be a protective
>MBR, which only serves the purpose of marking the whole disk (or as
>much as you can cover with the MBR) as used to avoid that MBR tools
>trash the GPT disk by thinking there's no data on it. At least EFI
>does not support both MBR partitions and GPT, but it is technically
>possible to create such a disk. Our GPT code currently allows this,
>but this is not by design. It's for convenience. The gpt(8) tool does
>not like MBR partitions with GPT, but it could be made less picky.
>
>It's not unthinkable to have bootable GPT on i386 and amd64. New boot
>blocks need to be written and we need a way to mark root partitions.

And on April 28/04,
     in the thread "More than 8 labels per slice ",
        Poul-Henning Kamp wrote:
>"David O'Brien" writes:
>  >On Tue, Apr 27, 2004, Harald Schmalzbauer wrote:
>  >> is there any chance that FreeBSD can adopt the OpenBSD changes
>  >> regarding UFS labels?
>  >
>  > I think there is a good chance -- many of us want it.  But someone
>  > needs to do the work and post patches for review.  Finding someone
>  > to port the OpenBSD or NetBSD changes to FreeBSD is the tricky part.
>
>Please, Can we just loose the BSD labels as fast as possible ?
>
>It shouldn't be hard to find something with fewer designed in
>warts and 2^32 issues.
>
>I belive GPT is about ready for primetime...

And now on Sept 20/04,
         in the thread "Possible bug in sbin/bsdlabel.c in -CURRENT"
            Brooks Davis wrote:
>IIRC you can't extend the number of partitions unless you don't need
>boot blocks so this isn't all that useful except in situtations where
>gpt(8) is a much better solution.  Fixing this hardcoding seems like
>a reasionable idea, but I'm not an expert on this subject.  We're
>trying to avoid stopgap hack to bsdlabel in general because it's an
>obviously dead-end solution and we want to move on to something like
>GPT as soon as feasiable.

This issue interests me once again, as I am getting a new PC with a
"small" 120 gig disk.  (the "small" disk was $15 cheaper than the
180gig disk they wanted to sell me...).  I always have multiple OS's
installed, so I would certainly like to split up that disk into more
than 7*4 partitions.  Even 15*4 would be very helpful for some of
the things I do.

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 have no reason to prefer the crusty old bsdlabel format over GPT,
but then I don't know anything about GPT.  Certainly it would be
even nicer if I could create more than 16 partitions, especially
for sparc64 (and PPC?) where I don't have the four DOS-level slices
to stuff partitions into.

Question 2:
The thing I don't know is:  If we go to GPT for FreeBSD, what does
that mean for other operating systems (including FreeBSD 4.x and
5.x) which I would like to install on the same hard disk?  Can I
mix MBR-based installs and GPT-based installs on a single disk?
If I cannot mix them, then I'm back to wishing for a 16-partition
version of crusty old bsdlabels...

Question 3:
If someone wanted to try getting GPT to work with FreeBSD, where
do they need to start looking?

-- 
Garance Alistair Drosehn            =   gad_at_gilead.netel.rpi.edu
Senior Systems Programmer           or  gad_at_freebsd.org
Rensselaer Polytechnic Institute    or  drosih_at_rpi.edu