[PATCH/RFC] fdisk: read/parse/print GPT disklabels

[Denys Vlasenko]

On Sunday 25 July 2010 02:53, Kevin Cernekee wrote:
> Since 3TB drives will soon be readily available, it would be nice if
> busybox had a way to partition them.  The three options that immediately
> come to mind are:
> 
> 1) Add GPT to the existing fdisk applet, alongside SUN, SGI, AIX, and
> OSF.
> 
> Pros: It's a relatively small change and can leverage much of what is
> already in the tree.
> 
> Cons: There's an awful lot of legacy code in there, and the non-DOS
> disklabels are not terribly well-supported today.  For instance:
> 
> a) This does not look like it is in working order...
> 
> 	if (LABEL_IS_SUN) {
> 		sun_list_table(xtra);
> 		return;
> 	}
> 	if (LABEL_IS_SUN) {
> 		sgi_list_table(xtra);
> 		return;
> 	}
> 
> b) This segfaults (as do many of the other commands, when in AIX mode):
> 
> echo -ne "\xc1\xd4\xc2\xc9" | dd bs=512 count=1 of=/tmp/aix conv=sync
> ./busybox fdisk -l /tmp/aix

Everything except DOS MBR handling probably bitrotted.


> The amount of effort needed to extend sector_t to 64 bits is unknown.
> It may be tricky to retest all of the supported permutations:
> 
> FDISK_SUPPORT_LARGE_DISKS
> FEATURE_FDISK_WRITABLE
> FEATURE_AIX_LABEL
> FEATURE_SGI_LABEL
> FEATURE_SUN_LABEL
> FEATURE_OSF_LABEL
> FEATURE_FDISK_ADVANCED
> FEATURE_FDISK_BLKSIZE
> 32-bit hosts vs. 64-bit hosts
> LE vs. BE
> 
> 
> 2) Add a new applet for this purpose.  e.g. a trimmed-down C version of
> gdisk.  Optionally add a scriptable version (sgdisk), or command-line
> options that would facilitate scripting.

I'd rather fix fdisk than add more applets.


> Pros: Provides a "clean start" and could be used to start phasing out
> the old fdisk applet.  Unnecessary complications like the CHS formulas
> could mostly go away for good.  New code would be simpler (based
> entirely on 64-bit LBA numbers) and easier to maintain long-term.

...assuming the new code is well-written. Which is, unfortunately,
isn't always true. Evidence is GPT format itself:

(1) why partition type is a binary blob? Wouldn't it be simpler
    to make it a string? Why should we use
    EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 instead of simply "Data"?
    0657FD6D-A4AB-43C4-84E5-0933C84B4F4F istead of "Linux swap"??
    Etc... I smell design by commitee.

(2) why sector numbers are only 64-bit wide?
    "640k will be enough for anybody" all over again.
    Just wait for molecular/atomic scale storage devices.


> Cons: May necessitate reimplementing the UI, utility functions, and
> other things we already have today.  Adding an applet is a bigger
> change than tweaking an existing one, and there may be resistance to
> the idea.

Basically, it's a matter of style. Some people rewrite from scratch.
Some people fix existing things. If you feel you have time
and inspiration to rewrite fdisk - you are welcome.
But it should at least support x86 MBR format too.


> 3) Just use the full-blown gdisk for partitioning.
> 
> Pros: Less work.
> 
> Cons: gdisk + sgdisk add up to ~250K and require C++ runtime support.
> busybox fdisk is about a tenth of the size.  Many embedded applications
> (including mine) just need something basic - and that is busybox's
> niche.
> 
> Any thoughts/opinions on the matter?

So far I applied your patch. Thanks.

Can you send me a few small GPT images for testing?

-- 
vda