The U**x/Linux universe provides more than one tool for each task. To alter partitioning tables for instance, it is not a big risk anymore. Is it really? And how about conventions for sizes? Gparted is the de facto standard under Linux, but there is also the Gdisk suite in the pipeline, and the Arch distribution installs it by default. Will it be the next top choice, will it displace Gparted? And for what reason do we need another partitioner?
I asked Rod Smith, the inventor and maintainer of Gdisk for the CHIP Linux magazine 01/2015. Here’s his unabrigded original wording.
weisskunst.de: Why another partitioning tool? And what’s the core difference between gdisk and parted?
Rod Smith: At the time I wrote gdisk, parted was EXTREMELY buggy and limited when it came to GPT partitioning. gdisk actually began as a quick hack to fix a few problems that parted had created on my first GPT-partitioned computer. By the time I’d used that proto-gdisk to fix the problems I’d encountered, I realized that my program had most of the features needed in a full-fledged partitioning tool; adding an fdisk-like user interface was the main thing that needed to be done. I created that user interface, tightened the code, and released the first public version of gdisk.
Since then, parted has cleaned up most of its GPT bugs, but it’s still got issues. Generally speaking, parted doesn’t show you exactly how the disk is partitioned; instead, it shows you its INTERPRETATION of how the disk is partitioned, which means you lose data between the disk and your eyeball. For instance, parted presents two different types of GPT data (namely, the partition type code and partition attributes) using a single user interface element (namely, partition „flags“). Furthermore, this user interface element is incomplete — it permits setting just a handful of partition type codes, and will not show the user if some type code that it doesn’t recognize is in use. Similar problems exist in other areas. One of my goals in writing gdisk was to minimize such problems; gdisk shows you and enables you to modify just about every GPT data structure that it makes sense for a user to modify. (Some protective MBR details are hidden, though, as are some GPT details that users should NOT be modifying, such as the CRCs and GPT version information.) In particular, you can set ANY GUID as a type code, and you can set ANY partition attributes you like. This capability isn’t important for 99.9% of Linux uses, but it can be important if you’re dealing with a multi-boot computer or some exotic tool that expects unusual partition type codes or attributes.
In sum, gdisk provides better low-level control of a GPT disk than does parted. OTOH, parted supports more partition table types (MBR, APM, etc.), and variants of parted (such as GParted) are easier for novices to use, or to use for tasks such as resizing existing partitions. Thus, each tool has its unique advantages, and there’s a wide middle ground in which either tool will work equally well.
If I’d known what would have happened with gdisk, I might have instead focused my efforts on contributing to parted. OTOH, there is merit to having two entirely unrelated code bases for a critical task like partitioning — a bug that affects gdisk is unlikely to affect parted, and vice-versa. This fact gives users recourse in case they run into a serious problem with one tool.
w: I felt that with respect to different size values different programs spat out…
RS: When different partitioning tools spit out different sizes, it’s usually because one uses power-of-10 (SI) values (MB, GB, etc.) and another uses power-of-2 (IEEE-1541) values (MiB, GiB, etc.). Sometimes power-of-2 values are given SI suffixes, which confuses the matter.
w: When did you start with your bundle, and how many contributors do you have now?
RS: The first version (0.2.0) was released on February 17, 2009. Six people, other than myself, have contributed significant code and are referenced in the README file. I’ve also taken a few pieces of open source code from other projects, like a CRC-computation function from a project called efone and code related to disk I/O and computation of the disk size from fdisk.
w:If you explain, that there’s a niche for different types of partitioning software in the habitat, does that mean you don’t expect GPT fdisk to supersede the parted/Gparted bundle in many distributions as THE standard?
RS: Some distributions already favor GPT fdisk as their partitioning tool of choice for GPT disks. Funtoo, for instance, specifies use of gdisk in its installation instructions (http://www.funtoo.org/GUID_Booting_Guide). Arch Linux gives equal weight to all the available tools (https://wiki.archlinux.org/index.php/GUID_Partition_Table#Partitioning_Utilities). Distributions that favor gdisk tend to be aimed at more advanced users. GParted is more accessible to less-sophisticated users than is gdisk (or parted, for that matter), and the GUI installers in Ubuntu, Fedora, and so on all rely on libparted, which is a convenient choice for that function. Even if I were to split off the core behind-the-scenes functions of GPT fdisk into a library, it wouldn’t provide good support for MBR or other non-GPT partitioning schemes, so libparted would remain a superior choice for tools that must support multiple partition table types.
w: Or is the question waste because parted/Gparted is more universal than GPT fdisk?
RS: That’s a good part of it, yes.
w: Looking at the roadmap: When will GPT fdisk leave beta status?
RS: I’ve been thinking of making the next release a 1.0 version, since there’s been very little need for change recently, and bugs have been mostly minor things introduced recently, rather than big problems in the core functionality.
More information: http://www.rodsbooks.com