My accepted GSoC project this year is making a graphical FreeBSD
installer (see http://wiki.freebsd.org/finstall). One of the first
functional (not related to UI) things the installer does is disk
partitioning, and I'm trying to simplify this step. Currently, the
FreeBSD default is classic BSD partitions on top of MSDOS partitions,
and there are a couple of inconvenient things about this arrangement:
1. There can be only 4 MSDOS partitions and 8 BSD partitions per table
2. BSD partitions by convention or backwards compatibility have special
entries for "b" and "c" ("b" is by convention swap, "c" is because of
backward compatibility "the whole disk")
3. MSDOS and BSD partitions are limited in size to 2 TB
Many systems (including MacOS X and Solaris) are moving to GPT
partitions (http://en.wikipedia.org/wiki/GUID_Partition_Table), mostly
because they don't have the above limitations. My proposal is that we
deprecate BSD labels and move to GPT in 7.0 (or more correctly, if the
stars were to be benevolent on us, on the new systems that are installed
by the new GPT-aware installer :) ).
The FreeBSD kernel supports GPT, and AFAIK the ability to modify them
in-place was recently added with the "unified" GPT slicer. There are two
things that are stopping total use of GPT right now:
1. Dual-booting (e.g. between Windows and FreeBSD)
2. Boot code limitations
First can be somewhat avoided by supporting a hybrid model, and using
MSDOS partitions as exist on the computer, and (since GEOM is flexible)
creating GPT partitions inside the MSDOS partition dedicated to FreeBSD
(i.e. just like now, only using GPT instead of BSD labels).
The second is more serious: FreeBSD boot code cannot boot from a GPT
Part of the problem is that GPT uses GUIDs for distinguishing partition
types, so the current code that recognizes various partition types
(Linux, FreeBSD, NTFS - the famous "F1" prompt) may need to be thrown
out since each GUID is 16 bytes long and AFAIK there's only about 300
bytes in the MBR for the boot code. GPT specification encourages using
different GUIDs for different purposes, so a swap partition would have a
different GUID than a UFS partition, which would have a different GUID
than a ZFS partition. I think UFS reserves a few sectors at the file
system start for the second stage boot code, but I don't know if ZFS
follows in this fashion.
Except for this, and looking at the specification
the partition format is "sane" - it contains plain 64-bit LBAs (offsets
of sectors on the disk, so maximum disk/partition size is 2^64 * 512
bytes) that can AFAIK be directly used to access data.
Thee are some minor issues, like CRC32 checksums of GPT data included in
the tables, and I don't know if it would be worth the code to include
it, but this should be all.
The above discussion assumes the classical boot model (MBR -> chaining
to other partitions -> higher stage boot loaders) and not EFI.
Now, the problem is - is someone with enough assembler knowledge
interested in implementing a GPT-aware boot loader? :)
Due to the size constraint, the boot loaders would probably have to be
split - one for MSDOS partitions, one for GPT partitions.