GNOME Bugzilla – Bug 432525
Resizing first partition becomes a Move too
Last modified: 2008-06-15 18:02:54 UTC
Please describe the problem: I used GPartEd on one drive, and I was pretty sure I only shrank it by using the mouse to drag the right border to the left. However, when I realised it was taking ages, I really looked at what it was doing and saw it say "Move left and shrink". I let it do its thing, and 2 hours later it was finished (successfully). On another system, I wanted to shrink two partitions, one in the middle and the first one. I used the keyboard this time, and shrank the middle one with no problems in under a minute (I pre-defragmented them) - it was reported as a simple shrink operation. When I went to do the first partition though, it again reported it as a "Move and shrink" even though I only (keyboard) edited the size. So I undid the pending operation and watched carefully what I did (see below). Steps to reproduce: 1. Start GParted (I booted with LiveCD). 2. Look at the information on the first partition. Start sector: 63. 3. Choose Resize/Move, and edit ONLY the size (I shrank it). 4. Look at the new information on the partition. Start sector: 0. 5. Look at the pending operations. "Move left and shrink" Actual results: Given that the dialog box is in MiBs, I believe you're rounding 63 sectors (31.5 KiB) down to 0 MiB, then when converting it back to sectors, setting the sector number to 0. Expected results: I would expect the start sector to remain at 63. Does this happen every time? Yes Other information: My first machine is a Vista-only machine with two partitions, while the second is a XP/Vista hybrid with three.
forgot to mention, i use gparted 0.3.3 thanks
Similar experience here. I tried shrinking a JHFS+ (Journaled HFS+) partition, and it became a resize + move. Details: --using gparted-livecd-0.3.4-11 on a external USB drive --drive using MBR partition table --affected partition was the 3rd in the disk; wanted to go from 350 GB to 300 GB --had been toying with the GUI prior to the actual resizing; but cleared pending actions before the final, true resize action (perhaps those actions had not been really cleared?) --configured the resizing by keyboard, not mouse --configured to resize from the end of the partition --the partition had 80 GB of free space, defragmented --when I noticed it was taking too long, gparted was well into the moving (+6 GB had been moved, as reported by the GUI). I had to cancel (low battery, laptop). The interesting thing is, the shrinkage worked (the partition is now 300 GB), and the filesystem contents *seems* to be OK, as far as I have been able to test. So I am thinking that perhaps the "move" was in fact a read+write in place? I don't understand the gparted_details.html file (the start block varies a lot there, though I think it shouldn't); but I am attaching it in case it helps. Anyway, my partition table now looks like this, as reported by Mac OS X 10.5.2's fdisk: 63,67108864,0xAF,-,0,1,1,1023,254,63 67108986,166723584,0xAF,-,1023,254,63,1023,254,63 233832627,639917145,0xAF,-,1023,254,63,1023,254,63 976170139,603029,0x05,-,1023,254,63,1023,254,63 976170195,602973,0x0B,-,1023,254,63,1023,254,63 0,0,0x00,-,0,0,0,0,0,0 0,0,0x00,-,0,0,0,0,0,0 0,0,0x00,-,0,0,0,0,0,0 Note that the affected partition (the 3rd) is reported as using the block numbers reported by gparted_details.html in the shrinkage step.
Created attachment 106870 [details] Mijail's gparted_details.htm gparted_details.htm file as created by gparted after being stopped in the middle of a partition movement that had not been asked for (I only wanted a shrinkage).
Thank you for the detailed bug reports John Burger and Mijail. I have been able to recreate the problem and will investigate what needs to be done to fix it.
I believe that I have found the source of the problem. Following is my theory, application of the theory, and a possible solution. THEORY The resize/move operation always performs a "snap-to-cylinder" function on both the starting and ending sector. The "snap-to-cylinder" function ensures that the starting or ending sector number is evenly divisible by the size in sectors of a cylinder (cylinder size = heads * sectors per track -- usually 255 * 63 = 16065 sectors for large disks). This represents a problem in the following two cases: A) It is a problem for the first primary partition since the Master Boot Record occupies the first 512 bytes of track 0, and the first partition begins in track 1 (usually sector 63). B) It is also a problem for logical partitions because the Extended Boot Record also occupies the first 512 bytes of the track, and the actual data portion of the partition begins in the next track (usually an offset of 63 sectors again). Note that the dialog box for the resize/move function does not include an option to turn off "snap-to-cylinder". Only the dialog box for creation of a new partition contains an option for "round to cylinders" (same as snap-to-cylinder). APPLICATION OF THEORY John Burger's Situation: From what I have read of the details of the listed in this bug, the above theory would account for what occurred -- first primary partition starts at sector 63. In this situation, GParted should never have performed the move regardless of whether the snap-to-cylinder function was enabled or disabled. Mihail's Situation: For this situation, the starting sector of the third partition was (and still is) 233832627. This number is not evenly divisible by the cylinder size (assuming that GParted was working with cylinder size of 255*63). Hence GParted did not think that the partition started on a cylinder boundary. The new starting value calculated by GParted was 233842140, which is evenly divisible by the cylinder size. Since the move step was interrupted, the starting sector had not yet been changed to this new number. In this situation, the ability to turn off the snap-to-cylinder function would have helped. POSSIBLE SOLUTION A possible solution to this problem involves two changes: 1) Fix the math in the snap-to-cylinder function to address the 63 sector offset problem for the first primary partition, and for logical partitions. And 2) Provide the same "round to cylinders" enable/disable option as found in the create new partition dialog. CONCLUSION I believe I have located the cause of this problem. Since the snap-to-cylinder function is based on math using Cylinders/Heads/Sectors, I also need to check of the implication on GPT partition tables. GPT uses Long Block Addressing instead of Cylinder/Heads/Sectors
Follow up on GPT for above Theory: GUID Partition Tables (GPT) have the data partition start at sector 34 so an additional check is needed for the first primary partition of GPT when "round to cylinders" is used.
The math used for snap-to-cylinder has been enhanced to handle the two situations described in the THEORY above, and also for the first primary partition of GPT partition tables. This enhancement has been committed to the gnome SVN repository for inclusion in the next release of GParted. Closing this bug.