adding fdisk GPT support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi there,


First, let me briefly introduce my proposal. With my NAS box setup, I am using mdraid to chain several disks together and then partition them using the md_d0px partitioning scheme. Also, the catch is to have the whole thing scriptable and easilly managable on a very tiny embedded linux, which is why I used one partitioned array instead of the more traditional several smaller arrays approach. With today's drive capacities, it's probably not surprising that early in my attempts, i've bumped into the 2TB drive limit for MSDOS partitioning, and had to wander into the GPTland.

To make things short, after trying several different approaches, I ended up writing my own tiny utility that has as little functionality as needed for my exact need, but is able to create the GPT partition tables. That was mostly due to time constraints, because i already spent quite too much time dealing with the issue. However, for this kind of task, the perfect, most flexible, most simple, and scriptable tool still seems to be fdisk (and its variants), if it wasn't for the fact that it cannot create GPT headers, so IMO "fixing" fdisk is the right way to go. GNU parted was way too bloated for my taste and for embedded use with its filesystem support, and it kept malfunctioning on arm machines.


My setup may be rather obscure and uncommon, but 2TB disks are on the horizon, which will make this even more necessary, if fdisk is not to be dumped for good. Since there seems to be some interest in this in the mailing list archives, I decided that I'd like to go ahead and try my best at adding GPT support to fdisk myself. (a proper GPT support, not just check why fdisk cannot handle it) I already did some initial poking around the current state of things, and already realised that implementing the support into the current code would be messy, would duplicate a lot of things, and I'd basically have to write a support for all 3 *fdisk utilities individually. To do things the clean way, the initial task is a massive cleanup/refactoring of the code, in some parts possibly even rewrite.

Given my current basic insight into the code, I'd like to outline the individual major steps that I'd take, in this order:

1) Most of the fdisk code is based around MSDOS partitioning scheme. Other label types are obviously a result of incremental development, and while they are separate, the whole thing is definitely a mess with most of the code doing checks for other labels, and then performing the default (msdos) if no other label has been found. The idea here is to create a fdiskdoslabel.[ch], which will act just like the other fdisk*label* files, and will centralise all of the msdos-related code. For the most part, this will be moving functions around, and turning the originals into generic label-independent variants that just call the appropriate label-dependent function, ie. mostly cleanup.

2) Separating disk-independent and disk-dependent utilities
The utilities that do not relate to fdisk as such, and are used by some of the labels or fdisk itself can be separated. There's a large amount of various utility functions like gethex, getchar, getline,... which can basically be separate and have their own file/header. Unfortunately, each of the *fdisks have their own, sometimes prototype-incompatible variant of those functions, so there might be some changes with regards to that.

3) Error reporting/handling
Currently, the utilities have a fatal(), warn(), error() functions [not all have them all], each utility its own set with a completely different interface, and completely different body. The body is no surprise, as at the very least cfdisk, being based around ncurses has to differ, the interface less so. Since those functions are being used just about anywhere, it's near-impossible to make use of any common code for handling labels in all utilities, some heavy linking magic would have to be involved. Besides, it's a fundamentally wrong approach to have a library print error and exit instead of just returning an error code and leaving the termination to the main app. The task here is to define error codes, clean up all of the utilities and function returns, and make sure that any message printing/error handling is done at the top-level main file (which should be as small and as generic as possible). Only the main file should be then responsible for displaying the messages to the user, in the correct way.

4) Global variables
To avoid having to define proper API, most of fdisk is based around global variables, which is such a turnoff. I believe that this should be eliminated all the way up to leaving like maximum of 0-2 global variables, as in any other normal application. Making sure all the functions don't operate with anything that wasn't given them explicitly as an argument is definitely necessary, but in case of fdisk, this will be a _major_ change.

5) Unified label handling between *fdisk
Currently, each fdisk variant has it's own code to handle label-dependent stuff. This is a major no-no. Since fdisk's seems to be the cleanest and most separated, it should be probably used as a library and be imported into cfdisk and sfdisk. Right now i cannot even imagine how huge this would be, but i assume very. Also, it will be the most major code changes, not just moving things around.


Somewhere in here, it's probably safe to implement GPT support, which itself is not such a big thing. There's a few more things that can be done to refactor the code, but i guess it would be more appropriate to outline those after the previous steps are done.


Any comments on what I got wrong? Anyone already had the same idea and did at least some basic work on this?


Regards,

Zdenek
--
To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux