Topic: Resize partition to maximum not possible ... bug?


i use GParted since a long time already and i never had an issue like this.

I copied a partition (GPT primary partition) to a bigger new HDD and then tried to resize the copied partition on the new HDD to the max, but when i do that there is always exactly 1 MiB unallocated space left at the end.

The copied partition is starting at sector 2048 so it is aligned to MiB and it should be possible to have no unallocated space left at the end of the partition.

Other GPT primary partitions on different HDDs i can max out without this unallocated 1MiB at the end of the partition, but they all are much smaller partitions and HDDs.

Why is this happening? Is it a bug in GParted with really huge HDDs? This new HDD is 16TB.


Re: Resize partition to maximum not possible ... bug?

Leaving 1 MiB free at the end of the disk space is needed for the partition table backup copy. This comes from the GPT specification. That 1 MiB space isn't left free, but it is taken by the backup copy of the partition table. GParted keeps it ut of the partition space in order to prevent corruption in case OS writes data in that partition table space.
Perhaps other partitioning programs allow to take that space too in a partition.
For MBR disks, no such space is needed as the partition table is located in the first sector of the drive, and no backup copy is kept. As I remember, there has been in the past MBR software that kept unofficial copy in the second sector but no general rule was about that.

So it isn't any bug, it is a requirement for GPT drives.

As for the initial 2048 sectors, they are the 1 MiB space needed for the MiB alignment. A drive can work with any alignment, even with the old legacy MBR scheme alignment, with a performance penalty and a faster wear out for the SSD drives. The 1 MiB has been chosen because it is multiple of the various cluster size values used by hardware manufacturers (i.e. 512 kiB, 256 kiB, 128 kiB ... ) for the newer generations of their products (SSDs and high capacity HDDs). So, since the mid 2000s the 1 MiB (2048 sector) alignment is used for new systems, GPT as well as MBR.

Of course, your partitioning can be GPT only (no MBR) due to the big size of the drive. The MBR scheme can't make partitions bigger than 2 TiB.

*** It is highly recommended to backup any important files before doing resize/move operations. ***

3 (edited by Discjockey 2023-01-02 15:46:49)

Re: Resize partition to maximum not possible ... bug?

I thought the partition table backup copy is stored in the first 2048 sectors (the 1 MiB of unallocated space at the start of the partition) GParted is hiding this unallocated space.

I partitioned a lot of smaller GPT primary partitions on smaller HDDs with GParted and they all had no unallocated space of 1 MiB at the end. I was always able to use the max space.

So it seems GParted changed behaviour with newer versions and leaves this 1 MiB unallocated space at the end. With this new big HDD i also used a new version of GParted to make sure it supports the big HDD.

So it seems i have to get used to view more partitions with this 1 MiB unallocated space at the end in the future. It`s the new standard

Perhaps it is a good idea to hide this 1MiB at the end the same way like the first 1MiB of unallocated space is not shown in Gparted, if this is a GPT specification to have this space used to backup the partition table.


Re: Resize partition to maximum not possible ... bug?

You can find a few more details about the GPT scheme in the following page:
especially at the image on the left upper part.
There are two GPT locations: the primary GPT in logical blocks 1-33 and the secondary GPT (the backup copy) in the last 33 logical blocks of the drive space.
(logical blocks are emulated 512 byte sectors, as we know them from the legacy 512 byte/sector hard drives).
The first block of the drive (logical block 0) contains an MBR-type structure to prevent non-GPT aware tools and OSs to think that the drive is unallocated and so damage the content.

So, the minimum reserved space at the end of the drive has to be 33*512=16896 bytes.
However, in newer hardware the minimum space for hardware blocks is usually 4 KiB, and in some disk types (especially SSDs and various flash type media) the write operations are done in much bigger blocks, as 64 KiB, 128 KiB etc. In order to avoid problems of software compatibility with all these different block sizes, OSs prefer to use the common multiple size of 1 MiB that ensures that each partition is located on its own blocks and no block is shared partially by two partitions or the last partition and the secondary GUID partition table. For the microsoft systems, the MiB alignment for the partitions was introduced with the vista OS.

As I wrote above, the 16896 bytes are the strict minimum for the secondary GPT.
It is possible for GParted to use the existing partition alignment, in case of modifying existing HDD partitioning. You could even use parted from the command line to make any partitioning you want. However you have to be sure that it is compatible with your hardware and that it is safely supported by your operating system, your software and your filesystem maintenance tools. I insist on this point because all these are mostly tested for the usual/commonly used configurations. This "common" configuration is now the MiB alignment that leaves the last MiB free for the secondary GPT for the GPT systems. 
For those 16TB or bigger drives, I think it is much safer to stick to the "common practice".

*** It is highly recommended to backup any important files before doing resize/move operations. ***


Re: Resize partition to maximum not possible ... bug?

GParted alignment is set to MiB since 2010 (version 0.6.2).
According to the Change Log ( https://gparted.org/news.php?item=all ) the most recent change/fix concerning the partition alignment is in 0.29.0 version (August 2017).

I was always able to use the max space

I understand this, however lost space of 1 MiB is (almost) nothing for such giant drives. I think we can save much more space by a better/more efficient file management.

By the way, I remember my first steps in personal computing with those old 160 kilobyte "Apple ][" floppy disks, that made me really happy compared to the cassette tapes used for storage in "inferior" systems! And yes, I had sometimes to count each sector!!

To suggest changes / new features you can open a thread to the Feature Requests forum.

*** It is highly recommended to backup any important files before doing resize/move operations. ***


Re: Resize partition to maximum not possible ... bug?

I used such an old version of GParted 0.30 or 0.32 i think.

Yes, i am not concerned about this lost 1 MiB. I am more concerned that this partion now looks like a fool partitioned it and was not able to partition it to use the max space hehe, but it seems this is the way partitions look now when experts partitioned them too.

Thanks for all your help and information about this 1 MiB situation.

I will write a suggestion to GParted to think about hiding this last blocks with the gpt partition table backup. I think it is just confusing people.