GPT as default?

[Ivan Voras]

Hi!

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

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 
(http://technet2.microsoft.com/WindowsServer/en/library/bdeda920-1f08-4683-9ffb-7b4b50df0b5a1033.mspx?mfr=true), 
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.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-geom/attachments/20070420/066d4222/signature.pgp