GParted leaves 1MB unallocated space at end of external HDD, override/alternative?

I only say external HD, I don’t have this issue with internal HDs.

I created a GPT table, then made one NTFS volume. It shows 1MB unallocated at end of disk. I know it is a backup of the GPT table, but I don't want it there. I back up my data anyway. This is only for data storage. I have had this issue when using MBR, and gaps between volumes. I recently moved to UEFI and want to use GPT on all drives, but I'm not yet very familiar with the inner workings of UEFI/GPT.

I’m not looking to argue on why I want the 1MB back, I just do. I want to encrypt the volume but can’t since it can’t easily be resized afterwards.

If anyone can name some other tool that will let me override this and let me have all my space, thanks. I have tried partitioning it in Windows but Gparted always shows this. I don't understand why the external is treated differently than the internals. GPT isn't supposed to have gaps. Maybe someone can also explain if/why this space is essential.

Edit: I'm messing around with gdisk, as suggested. But will gdisk create a GPT/UEFI standards-compliant partition that both Linux and Windows will recognize as valid? If so, why does Gparted leave the space? I still don't get why the external is treated differently than internals. Standards are standards, be uniform.

Solution 1:

The secondary label at the end of the volume is required by GPT; a disk without it is corrupted and may not be recognized by all systems. Using a corrupted format in order to gain a tiny amount of space, on a disk that's probably a few hundred gigabytes at least, doesn't make much sense.

However, the actual GPT label is only about 68 kilobytes in size. Modern partitioning software typically aligns the start of each partition on a 1MB boundary for performance reasons, since that's a multiple of any realistic disk sector or flash erase-block size, but there's no real need for the end of the last partition to be on a 1MB boundary. GParted may do that by default, but gdisk lets you create a partition that goes right up to the last usable sector (68k from the end of the disk).

Note, however, that the 1MB alignment of the beginning of your partitions means that you also have about 1MB of unused space at the beginning of the disk, between the GPT label and the first partition. If you know your disk's physical sector or erase-block size, you could align your partitions to that instead of using 1MB boundaries, in order to move the beginning of the first partition closer to the beginning of the disk. (But this seems like more trouble than it's worth.)

Solution 2:

I noticed an excerpt from https://wiki.archlinux.org/index.php/Btrfs#Partition_offset

GRUB can boot Btrfs partitions however the module may be larger than other file systems. And the core.img file made by grub-install may not fit in the first 63 sectors (31.5KiB) of the drive between the MBR and the first partition. Up-to-date partitioning tools such as fdisk and gdisk avoid this issue by offsetting the first partition by roughly 1MiB or 2MiB.

This seems to imply this is not a sector/boundary/etc.-alignment problem as other answers seem to indicate, but a safeguard. Other signs that support this argument: this occurred for me while formatting an SSD with btrfs, after I had specified the partition be aligned at the start of the free space... but the 1MB of empty space was located before my partition. So, perhaps this is the partitioning tool anticipating that the MBR may need extra space? And the partitioning tool just doesn't give the user feedback as to what's going on?