Topic: Unallocated disk space equal exactly to one MiB after shrink/grow
I am using gparted-live-1.1.0-5-amd64.iso on disk with gpt partition table.
Initial state of partition on drive is as follows (start sector, last sector, sector count) - it looks like every partition is MiB aligned at the beginning:
start sect last sect sect cnt
/dev/nvme0n1p1 2048 1026047 1024000
/dev/nvme0n1p2 1026048 123906047 122880000
/dev/nvme0n1p3 123906048 944005119 820099072
/dev/nvme0n1p4 944005120 976773119 32768000
So far I dry tried to perform two operations (with MiB alignment turned on):
shrink partition 'p3' by 20000MiB and move its start sector to the right
grow partition 'p2' into free space.
I end up with:
/dev/nvme0n1p2 1026048 164863999 163837952 (79999 MiB size)
unallocated 164864000 164866047 2048 ( 1 MiB size)
/dev/nvme0n1p3 164866048 944005119 779139072
This leaves exactly 1MiB (2048 sectors * 512 bytes/sector) of unallocated space.
The question is: I cannot understand why gparted insists on having this exactly 1MiB gap and not allowing p2 to grow to 80000 MiB. Now p2 size is 79999MiB.
As far as I understand information from this page https://gparted.org/display-doc.php%3Fn … alignment:
Use MiB alignment for modern operating systems. This setting aligns partitions to start and end on precise mebibyte (1,048,576 byte) boundaries. MiB alignment provides enhanced performance when used with RAID systems and with Solid State Drives, such as USB flash drives.
partition p2 which would look like this (it allocated this free 1 MiB and has size of 80000MiB):
/dev/nvme0n1p2 1026048 164866047 163840000
is perfectly aligned to MiB, so this gap that gparted introduced seems unnecessary.
Is this unallocated space a feature or a bug? Is is safe (from alignment point of view) to disable "MiB alignment" in gparted and manually "force" p2 to grow to 80000MiB?