Topic: Rounding problem with GParted


I am in the process of aligning my /dev/sda partitions to 1 MiB boundaries (2048 sectors) before moving my disk contents to an SSD.

And I fall on problems = the GParted Move/Resize dialog seems to be rounding numbers and keeping me from doing the job.

Here is the latest setup of my /dev/sda disk:

root@debian:/mnt/dm3# sfdisk -l -u S /dev/sda
Disk /dev/sda: 149.1 GiB, 160041885696 bytes, 312581808 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x165e165e

Device     Boot     Start       End   Sectors  Size Id Type
/dev/sda1            2048   2097151   2095104 1023M 1b Hidden W95 FAT32
/dev/sda2  *      2097152 102760447 100663296   48G  7 HPFS/NTFS/exFAT
/dev/sda3       102760448 144418815  41658368 19.9G 17 Hidden HPFS/NTFS
/dev/sda4       193185792 312581807 119396016   57G  f W95 Ext'd (LBA)
/dev/sda5       197103616 205629439   8525824  4.1G  7 HPFS/NTFS/exFAT
/dev/sda6       205632063 254935484  49303422 23.5G  7 HPFS/NTFS/exFAT
/dev/sda7       254935548 304094384  49158837 23.5G  7 HPFS/NTFS/exFAT
/dev/sda8       304094448 312580095   8485648    4G  7 HPFS/NTFS/exFAT

As you can see, sda1, sda2, sda 3 and sda5 are all well aligned:
- start sector on a number divisible by 2048
- end sector on a (number divisible by 2048) - 1

However, sda6 is not (yet), it is 2623 sectors away on the right from the point where I want it to be.

The Move/Resize Dialog shows the following values:

Free space preceding (MiB): 1
New size (MiB):             24074
Free space following (MiB): 0

Whether I set "Align to" on MiB or None (didn't try Cylinder as this is not what I am looking for), there is no way I can bring "Free space preceding (MiB):" to 0 !!

- The little arrow for decreasing the value is not active / grayed out.
- Replacing 1 by 0 on the keyboard sets back the value to 1 as soon as I leave the box
- Moving the graphical handles at top never goes below 1.

Therefore, I have no way to bring my partition to the left by 2623 sectors to the start value of 205629440, which is divisible by 2048 and so is a MiB boundary :-(

Is there a workaround ? A bug to fix ? Or something I am doing wrong ?

Thanks for the support, Erwin9.


Re: Rounding problem with GParted

It seems that the logical partition /dev/sda5 is aligned to Mib but the other 3 logical partitions /dev/sda6, /dev/sda7 and /dev/sda8 are aligned to cylinder (the start sectors are divisible by 63). I can't know how these partitions were created (I guess they were created perhaps by various tools and in several phases over the years).
This means that you have to align all these 3 partitions by MiB. I would advice to proceed one by one, so that you can check the result after each step. This takes longer but it is safer.
Furthermore, I don't stop to advice backup of any important files before doing any work on the partition table, as there are many factors that could go wrong (especially hardware or power failures).

It is safer to use the latest GParted version in order to avoid older bugs. I'm not sure how large gaps it leaves.
You can try, keeping the "Align to MiB" setting. This will perform a move & resize operation to recreate the partition according the selected settings. If there is any gap larger than 2048 sectors, you can try to move or expand the partition to the left.
It is better to respect the minimum suggested by Gparted, as there is some space needed for the "partition boot records".
However, it is better to know what all these partitions are for. This isn't a typical windows partitioning. If they are related to any system function like system recovery, this function could not work.

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


Re: Rounding problem with GParted

This is a known issue with GParted when changing a partition from non-MiB alignment (e.g., Cylinder alignment) to MiB alignment.  The operation currently requires two steps.

See Bug 635113 - Unable to change alignment from cylinder (63) to MiB (2048) in single step

Because the space you may recover is very small (2623 sectors as you mentioned), if I were you I would leave the start of the partition where it is.  It can take a long time to move a partition and there is more risk involved in doing this operation.

4 (edited by erwin9 2016-03-12 11:32:01)

Re: Rounding problem with GParted

Hello, thank you for the answer. Too bad this bug is around since 2010 !

If I may offer a suggestion which should help solving the problem, and also address the demand in the above mentioned bug report of "selectable unit (Sector(512), Sector, Kilobyte, Megabyte, Gigabyte, Cylinder)", that would be to decorrelate input from output.

Basically, inside the Dialog:
- maintain a set of input parameters for resize/move in sectors unit only, and manipulate all in sectors intenally,
- initiate with current values when opening the Dialog, and save them as start values in a second structure
- display current input values in the modification boxes according to "alignment" chosen, and when a new alignment is chosen, convert the box contents as needed
- display besides input section an output section (not modifiable) containing the resulting current values in sectors, and show in bold for example what has changed compared to start values
- you can even display a kind of warning on the start sector side when it is modified, in addition to the pop up appearing when Ok is pressed, to highlight such a modification.
- any time something is changed on input side (a value entered or up/down arrows pressed or units changed), recalculate current sectors value according to alignment and refresh the output display
- add a button to Reset all back to initial values
- and a Cancel and Ok buttons of course

When Ok is pressed, you are able to tell if the start sector of the partition was changed or not.
And with the "bold" (or whatever else) feature, the user is conscious when the start sector has changed.

Sorry if this is not very clear. If you want that I take a look to express things better, could you point me at the module(s) handling that part in the code as I am not familiar with it ? I'll try to express things better in code, and post my suggestion in the bug report, if you agree.

(note: to my problem, since my purpose is to align partitions on 1 MB boundaries , I will have to do the 2 steps thing for now. I was suspecting it, thanks for the confirmation).

Best regards, Erwin9.


Re: Rounding problem with GParted

Thank you Erwin9 for your suggestions.

GParted is a volunteer effort that we maintain in our limited amount of spare time.  If you would like to help out, please see the Development page to learn more about how development works, and what is involved in creating your own patches.


6 (edited by erwin9 2016-03-12 22:48:32)

Re: Rounding problem with GParted

Ok, I do not have Linux right now on my system so won't be able to compile / verify anything.
I'll wait to get my SSD to add one more partition and install Linux .. smile (will just have to be careful that Grub2 does not mess up my GRUB4DOS ..), and then I'll take a look at whether I can help or not.

Meanwhile, I'll try to wander in the code to see if I can easily find my way and logics surrounding the Dialog (I am not familiar with GTK).

Now, on what appears to be the same root problem, I found one more symptom / bug if I may ..

You remember my 2 partitions above:

Device     Boot     Start       End   Sectors  Size Id Type
/dev/sda6       205632063 254935484  49303422 23.5G  7 HPFS/NTFS/exFAT
/dev/sda7       254935548 304094384  49158837 23.5G  7 HPFS/NTFS/exFAT

So to align sda6 in 2 steps, I decided to add 2-3 MiB at start.

When opening the Resize/Move Dialog, it was showing the following initial values:

Free space preceding (MiB): 1
New size (MiB):             24074
Free space following (MiB): 0

I pressed 3 times the up arrow on "Free space preceding" to get:

Free space preceding (MiB): 4
New size (MiB):             24071
Free space following (MiB): 0

Pressed ok, and got the idea to look at the new information for the sda6 partition.

New start moved by +5569 sectors to get to 205 637 632.
Old start was 205 632 063 as you can read above, which is 575 away from the immediate lower 2048 boundary (at 205631488), so that looks good smile

575 + 5569 = 6144 = 3 * 2048

However,  the end moved also.
New value was 254937087, which is 1603 sectors more "to the right".
I can understand why .. 254937088 is the next 2048 boundary (1 MiB), so this value got aligned also.

But .. look at the start point of partition sda7 above: this new end for sda6 is overlapping with the start of sda 7 !!  neutral

Happy that I looked at it ... it would have failed !
I had to increase the "Free space following" to a value like 2 or 3 to get proper values.

And now that I say it, I remember I had gotten the same problem when aligning my last partition (sda8, see above post) previously.
It had failed, and when looking at the details log, no wonder, its end was getting aligned on a value which was beyond the end of the disk .. same problem obviously.
I believe I got around it at the time deleting and recreating the partition. Indeed, since it is my Win7 SWAP partition, there is no static data on it.

Hope this helps .. I'll come back hopefully when I get my SSD and have installed Linux on a new partition to start looking at code.

Meanwhile, let me know if I can be of any use, cheers smile


Re: Rounding problem with GParted

As you have discovered, there are some issues with the code that might arise when changing from Cylinder alignment to MiB alignment.  Having said that if one sticks with either Cylinder alignment, or MiB alignment then operations run smoothly.  Fortunately Cylinder alignment is only needed for old operating systems like DOS.  For more recent operating systems the default of MiB alignment works best.

This is an area for improvement and the cause of a few bug reports.