[prev in list] [next in list] [prev in thread] [next in thread]
List: busybox
Subject: Re: [PATCH/RFC] fdisk: read/parse/print GPT disklabels
From: Denys Vlasenko <vda.linux () googlemail ! com>
Date: 2010-10-25 0:12:25
Message-ID: 201010250212.25603.vda.linux () googlemail ! com
[Download RAW message or body]
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
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic