GNOME Bugzilla – Bug 695078
Move of MiB aligned partition right to left yields unexpected shrink of 1 MiB
Last modified: 2013-03-19 16:56:14 UTC
When moving a MiB aligned primary partition from right to left, the resulting partition is unexpectedly 1 MiB smaller in size. From further testing, this occurs only if the move boundaries overlap the original partition boundaries. In cases where the move does not overlap the original partition boundaries, then the size remains the same. Steps to recreate the problem. 1) Create a MiB aligned ext2 partition with unallocated space in front of it. 2) Apply this operation 3) Select the partition and move from right to left by a value less than the size of the partition. NOTE: This means that the new location will overlap the previous partition boundaries. 4) Before applying the operation, note that the partition is 1 MiB smaller.
Created attachment 237898 [details] [review] Patch to fix move partition right to left shrinks partition 1 MiB Attached is a patch to address the problem raised in this bug report. Mike, when you have a chance please review this patch.
Created attachment 237948 [details] Details from test move partition to the left overlapping Hi Curtis, I've tested this on my Fedora 14 desktop, with libparted 2.3, using the current GParted master and didn't manage to re-create the fault. Please see details from the move attached. Can you see any differences between what you are doing an I am doing? Thanks, Mike
I've reproduced the fault now. It also have to be a primary partition, not a logical partition. GParted throws in a 1 MiB shrink as well as the move to the left. On a logical partition, performing an overlapping move, it looks like this: v Move /dev/sdb5 to the left > calibrate /dev/sdb5 > check file system on /dev/sdb5 for errors and (if possible) fix them > grow partition from 128.00 MiB to 192.00 MiB > move file system to the left > shrink partition from 192.00 MiB to 128.00 MiB On a primary partition it looks like this: v Move /dev/sdb1 to the left and shrink it from 128.00 MiB to 127.00 MiB > calibrate /dev/sdb1 > check file system on /dev/sdb1 for errors and (if possible) fix them > shrink file system > shrink partition from 128.00 MiB to 127.00 MiB > check file system on /dev/sdb1 for errors and (if possible) fix them > grow partition from 127.00 MiB to 191.00 MiB > move file system to the left > shrink partition from 191.00 MiB to 127.00 MiB
My apologies Mike for the omission of "primary" partition from the steps to reproduce the problem in the initial post. From rereading the initial post, the only place where I mention "primary" is in the first sentence of the post. My bad. ;( Today I hope to finish testing the psusi/refactor branch code, and then I can focus on testing your improved clearing of file system signatures.
Not a problem. Just had to start a VM when I couldn't re-produce it on my desktop, which already has it's quota of 4 primary/extended partitions. Seems a bit wrong to adjust partition boundaries afterwards rather than understanding the constraints and setting them correctly in the UI. align_to_mebibyte() seems especially complicated. Anyway this is idle speculation because its a big job to change. -- Curtis' patch from comment #1 has been applied to the GParted GIT repository for inclusion in the next release. Link to the commit: Fix move partition right to left shrinks partition 1 MiB (#695078) http://git.gnome.org/browse/gparted/commit/?id=34da790ef30a2bdb30932cbfd9c67fe61f6014d8
The code change to address this report has been included in GParted 0.15.0 released on March 19, 2013.