From owner-freebsd-geom@FreeBSD.ORG Fri Apr 20 15:27:49 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 986B416A400 for ; Fri, 20 Apr 2007 15:27:49 +0000 (UTC) (envelope-from gcubfg-freebsd-geom@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 2724E13C469 for ; Fri, 20 Apr 2007 15:27:48 +0000 (UTC) (envelope-from gcubfg-freebsd-geom@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Hev1R-0001B7-TP for freebsd-geom@freebsd.org; Fri, 20 Apr 2007 17:27:41 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 Apr 2007 17:27:41 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 Apr 2007 17:27:41 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-geom@freebsd.org From: Ivan Voras Date: Fri, 20 Apr 2007 17:27:13 +0200 Lines: 95 Message-ID: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4A9CCDB6C7A3597A594040D8" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 1.5.0.10 (X11/20060911) X-Enigmail-Version: 0.94.2.0 Sender: news Cc: freebsd-current@freebsd.org Subject: GPT as default? X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2007 15:27:49 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4A9CCDB6C7A3597A594040D8 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi! My accepted GSoC project this year is making a graphical FreeBSD=20 installer (see http://wiki.freebsd.org/finstall). One of the first=20 functional (not related to UI) things the installer does is disk=20 partitioning, and I'm trying to simplify this step. Currently, the=20 FreeBSD default is classic BSD partitions on top of MSDOS partitions,=20 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=20 entries for "b" and "c" ("b" is by convention swap, "c" is because of=20 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=20 partitions (http://en.wikipedia.org/wiki/GUID_Partition_Table), mostly=20 because they don't have the above limitations. My proposal is that we=20 deprecate BSD labels and move to GPT in 7.0 (or more correctly, if the=20 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=20 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=20 MSDOS partitions as exist on the computer, and (since GEOM is flexible)=20 creating GPT partitions inside the MSDOS partition dedicated to FreeBSD=20 (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=20 partition. Part of the problem is that GPT uses GUIDs for distinguishing partition=20 types, so the current code that recognizes various partition types=20 (Linux, FreeBSD, NTFS - the famous "F1" prompt) may need to be thrown=20 out since each GUID is 16 bytes long and AFAIK there's only about 300=20 bytes in the MBR for the boot code. GPT specification encourages using=20 different GUIDs for different purposes, so a swap partition would have a = different GUID than a UFS partition, which would have a different GUID=20 than a ZFS partition. I think UFS reserves a few sectors at the file=20 system start for the second stage boot code, but I don't know if ZFS=20 follows in this fashion. Except for this, and looking at the specification=20 (http://technet2.microsoft.com/WindowsServer/en/library/bdeda920-1f08-468= 3-9ffb-7b4b50df0b5a1033.mspx?mfr=3Dtrue),=20 the partition format is "sane" - it contains plain 64-bit LBAs (offsets=20 of sectors on the disk, so maximum disk/partition size is 2^64 * 512=20 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=20 it, but this should be all. The above discussion assumes the classical boot model (MBR -> chaining=20 to other partitions -> higher stage boot loaders) and not EFI. Now, the problem is - is someone with enough assembler knowledge=20 interested in implementing a GPT-aware boot loader? :) Due to the size constraint, the boot loaders would probably have to be=20 split - one for MSDOS partitions, one for GPT partitions. --------------enig4A9CCDB6C7A3597A594040D8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGKNvYldnAQVacBcgRAubaAJsFHL/NoQXw0DoHlk/69ASIaatbbgCfRBUO pwt1cHQJKjfjE+gt4piV6C8= =UAyy -----END PGP SIGNATURE----- --------------enig4A9CCDB6C7A3597A594040D8--