Small unallocated space left, when partitioning harddrive. What is is meant for and why can't I use it?

Question

Every so often I encounter a small unallocated space in the partitioning scheme of a hard drive, when I want to create a maximal sized partition, even though I have set the "Free space following" to zero in the partitioning dialogue. (see first picture below.)

Of what use this free space of 2048 sectors? The chosen partition table is GPT. Is this small space meant for the MBR equivalent of GPT? If so, why is it at the end of space, should it not be at the beginning of the HDD?

---

Solution

I'm not sure why libparted does this, but I have three hypotheses:

• It may be a relic of times past. When using the old-style cylinder alignment, the number of sectors on a modern disk would seldom work out to an exact number of cylinders -- that is, the last cylinder would be partial. Thus, when partitioning MBR disks with cylinder alignment, it was once common practice to leave a few sectors at the end of the disk unused. It's possible that the algorithms that libparted uses to do this end up creating a 1MiB gap on GPT disks. If so, this could be considered a bug, albeit a very minor one.
• It may be a rounding error. In recent versions of libparted, partition start points are aligned on 1MiB boundaries. The developers may have intended to have the partition end at the very last usable sector, but a rounding error might have caused it to drop down by the partition-alignment value of 1MiB.
• It may be intentional. A gap at the end of the disk could be used for a BIOS Boot Partition (which users must sometimes add after partitioning because they didn't realize they needed it) or to adjust the size of the partition table. Unfortunately for this hypothesis, libparted doesn't enable use of this space in either of these ways, although gdisk does.

I've listed these options in order of decreasing plausibility. Note that I'm the author of GPT fdisk (gdisk, sgdisk, and cgdisk), so I'm extremely familiar with the needs of GPT partitioning. I've even contributed a few lines of code to libparted, but I'm not familiar with the specific areas of libparted that are responsible for this behavior, hence the speculative nature of my hypotheses.

Comments

[Admin]

It is because 3.815.391 isn't evenly divisible by 2048 leaving you with roughly 1MIB of unused space...

[Admin]

Could you go into some more detail? Why do I have to divide by 2048? Newer hard drives use 4096 byte (4 kB) sectors. Is the problem, that I have chosen an alignment of megabytes not sectors?