GNOME Bugzilla – Bug 635113
Unable to change alignment from cylinder (63) to MiB (2048) in single step
Last modified: 2020-11-13 10:41:40 UTC
Part of my storage work is to make sure all partitions are properly aligned on a 4k offset (or 64K, 128K... for RAID chunks) and since Linux, Windows 2003 and earlier follow MSDOS tradition of starting on sector 63 this means I need to move partitions up to start at the 1MB offset. In gparted though if I set the rounding to MB and set the beginning offset to 1MB it rounds it up to 2MB. I suspect this is because it takes this new offset as relative to the existing offset instead of a new absolute offset. In other words it calculates sector 63 + 2048 = 2111 rounded up to nearest MB is 4096. To work around this I have to move the partition to sector 4096, then back to 2048 (if I care enough to do so). I think it's a bug that the starting offset is taken as a relative number instead of an absolute number. -Ross PS I know this is probably a feature request, but it would be nice if the interface just had a selectable unit (Sector(512), Sector, Kilobyte, Megabyte, Gigabyte, Cylinder) and it would re-scale the sliders appropriately, rounding to the nearest unit (and of course taking offsets as absolute values), of course for trailing space on a disk one would need to use a relative number to the remainder of the disk for a given unit so as not to skew the unit scale.
Thank you Ross for reporting this concern. I assume that you are trying to move an existing primary partition from sector 63 to sector 2048. If I am wrong, then please let me know because the following explanation might not apply. Assuming my assumption is correct, this behaviour is part of an effort to ensure that a resize operation does not become a move. This was an earlier problem experienced by GParted users, that sometimes resulted in a failure of the operating system to boot. See bug #571151 - gparted moves partition to the left even if unneeded Prior to version 0.6.0, GParted always defaulted to cylinder alignment. Now GParted defaults to mebibyte alignment. In order to respect that resizes do not suddenly become moves, GParted will only move the start of the partition if the space before value is changed. This means that to move a primary partition at sector 63, the space before value must be changed from 1 MiB to 2 MiB. One way I can think of to try to intelligently address both concerns is to figure out whether a disk is aligned to cylinder or aligned to mebibyte and use that as the default alignment. Then if a user changes the alignment GParted could consider that an instruction to move the partition even if the space before value was not changed. Is my assumption correct? If not could you restate the problem in a different way. Regarding your "PS", there are existing feature requests and bug reports for using different units: Bug #612928 - file size units not consistent with GNOME desktop Forum Feature Requests - Use sector/block as unit http://gparted-forum.surf4.info/viewtopic.php?id=452 Unfortunately I have been unable to come up with an elegant way to implement this in the source code in a maintainable fashion. If you have a chance to review the source code and can come up with a good suggestion or patch I am all ears. :-)
I have also found this to be an issue. With 63 sector offset the partition actually has something like 0.03MB free space in front of it, not 1MB I had to move the partition twice because first it would be moved from 0.03 to 1.03 or 2.03 and then from 2.03 to 1 MB. This is somewhat annoying.
Rename report from: GParted 0.7.0 Offset Bug to: Unable to change alignment from cylinder (63) to MiB (2048) in single step
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time. If you still use gparted and if you still see this bug / want this feature in a recent and currently supported version, then please feel free to report it at https://gitlab.gnome.org/GNOME/gparted/-/issues/ by following the guidelines at https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines Thank you for creating this report and we are sorry it could not be implemented so far (volunteer workforce and time is limited).