Re: Default support for GPT

On Tue, Sep 21, 2004 at 05:59:27PM -0400, Garance A Drosihn wrote:
> [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 believe PHK has a reason, but I don't know what it is.

> 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.

As long as you don't want to boot off of it, you can stuff a GPT label
on one of your sunlabel partitions partitions today (or at least you
should be able to).  Since GEOM doesn't care about the order of the
disks, you can even do silly things like put an MBR on one of the
partitions (subject to convincing fdisk to do it.)

> 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...

The OS needs to understand the partiton table so at this time 4.x won't
work on a pure GPT system.  I suspect we're going to end up with some
odd compatability hacks such as using undersided native partition tables
followed by a modern table like GPT.  That would be fairly easy to
implement with GEOM, just present any space after the partition table as
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.

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

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

-- 
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4