1

Topic: user feedback and requesting guidance

With all due respect to Bart Hakvoort and the gparted team, I have a hunch this project, as any, can be improved. If sharing is caring, allow me dump my experiences here, in the hopes that someone will see in here something fix-worthy and not just a rant. Feel free to use, comment or ignore any of my sketchy ideas as you see fit.

I just ventured on resising a 750gb ntfs partition to make room for another linux OS, and while I know it's not a linux-friendly filesystem and I get that keeping things simple is generaly a good idea, I must object to the way gparted handled this for me.

When I read "Depending on the number and type of operations this can take a long time" I wasn't expecting 12hours on sata3. Maybe 2. Then if you go check the forums you'll see people telling you not to resize left, because it's gonna take forever - a thing that not everyone readily kwows and a pop-up on which you can tick "do not show this again" could inform you about. Not a programing feat and not superfluos given that nowadays we mess with terrabytes.

Now I get the part where you have to consolidate data, I get the part where NTFS has indexes and intricacies, I get that it's not simple, but I really don't get the part where I wasn't warned about it actually recreating a file system from the ground with 8mb blocks instead of 16 and that it'll take much more than what I would expect a "long time" would mean.  Gparted was kind enough to do a simulation before starting the actual job, which is awesome, but didn't it know right afterwards that this is a 12+ hour job it's starting next ? Why exactly wasn't I warned ? I get that my disk is a big disk, but moving 1tb of data to another drive and back would have costed me less than 90 minutes if my calculations are right. I could have repartitioned the drive while empty and be done long ago.

I doubt it's impossible to estimate and warn the user. This must change. Resising NTFS might have it's challanges, but I swear I just expected it to move the data out of the way and change the partition table. Now if that's impossible with NTFS... could you please offer at least a warning ? Or something. I'd go as far as theorize that turning a disk with a difficult to handle ntfs partiton with some freespace available into a drive with multiple ext4 partitions without loosing data might not be impossible and could be a lot quicker. Even if that means ending up with 10 ext4s, that I'm not sure how well would handle merging right now, I'd take that option, either done on-the-fly or even do it myself manually, anytime over a process that takes 15 hours. Aren't there partitions that can grow ? Would the ntfs partiton collapse if parts of it were overwritten without it's knowledge always chopped of to it's left until we don't need to fidle with it anymore ? I never wanted a ntfs partition. I just wanted room for another. As you can see I'm ingenious enough to figure out how, but if this program ofers to resize ...

I'm also a bit surprised that my CPU is at around 30% my ram at 70%. The moving roughly copies 1.3GB per minute, which is 22MB/s, which is under 10% of the maximum transfer rate my drive could handle.  Where's the bottle neck ? It's like gparted could do the job faster, it just won't cause it likes to see you suffer through the day waiting for it to finish.

Another not necessarily cosmetic-flaw I'd like to bring to everyones attention, is having a cancel button available at this stage is also kind of more than wrong. It could say Abort or Revert or "Force interupt at cost of data loss", but not Cancel - you can't cancel this and we all know it. What would pressing Cancel at this stage (perform real move 33%) bring me ? Again, reprograming this button would seem like something that needs to be fixed, but filling a bug report is not something I'm keen on, as I expect this to end up to be something of least priority and never implemented. So if someone with an account ready, might want to vote for this as a good idea by submiting this as a bug, than it has a chance.

I'm not even sure if I didn't just mess this up by adjusting to cylinder in the first place. It says "Move /dev/sdb1 to the right and shrink it ..."There was like 1mb of unpartitoned space after this partition. Is it possible that I just lost 3 hours by moving a 750GB partition a few kB to the right by "adjsting to cylinder" or playing with other subtle settings ? Have I ? I only wanted to make room for a new partition at the begging of the hdd.

Was the block size change necessary, is it saving time or wasting time ?

I've used gparted dosens of times before and I don't remember ending up having to wait for it for hours. I'm not a noob when it comes to partitions, and although I might need to refresh my knowledge, I really think that a higher degree of idiot proofing wouldn't make gparted less elegant, quite the contrary.

All in all, I'm just trying to highlight that gparted is ambiguous and a program that plays with your data shouldn't be.

2

Re: user feedback and requesting guidance

Well, congrats. It actually worked out well, which kinda amazes me. It took less than the estimated time. Guess the bottleneck was writting in blocks of 8mb ?

Here's the log. It says "move to the right" which would only make sense if both the beginning and end would move together, shrinking in itself implies changing the boundaries. It should have read "Shrinking to the right" or something else. "move" is just another carelessly misleading and confusing word thrown in here like "Cancel" is. Please fix.

I just can't wrap my head around the parts in bold.
GParted 0.11.0 --enable-libparted-dmraid

Libparted 2.3
Move /dev/sdb1 to the right and shrink it from 698.64 GiB to 648.34 GiB  11:28:48    ( SUCCESS )
        
calibrate /dev/sdb1  00:00:00    ( SUCCESS )
        
path: /dev/sdb1
start: 63
end: 1,465,144,064
size: 1,465,144,002 (698.64 GiB)
calculate new size and position of /dev/sdb1  00:00:00    ( SUCCESS )
        
requested start: 105,482,790
requested end: 1,465,144,064
requested size: 1,359,661,275 (648.34 GiB)
new start: 105,482,790
new end: 1,465,144,064
new size: 1,359,661,275 (648.34 GiB)
check file system on /dev/sdb1 for errors and (if possible) fix them  00:00:02    ( SUCCESS )
        
ntfsresize -P -i -f -v /dev/sdb1
        
ntfsresize v2012.1.15AR.1 (libntfs-3g)
Device name : /dev/sdb1
NTFS volume version: 3.1
Cluster size : 4096 bytes
Current volume size: 750153728512 bytes (750154 MB)
Current device size: 750153729024 bytes (750154 MB)
Checking for bad sectors ...
Checking filesystem consistency ...
Accounting clusters ...
Space in use : 688464 MB (91.8%)
Collecting resizing constraints ...
Estimating smallest shrunken size supported ...
File feature Last used at By inode
$MFT : 3223 MB 0
Multi-Record : 424210 MB 107
$MFTMirr : 375077 MB 1
Sparse : 417430 MB 113
Ordinary : 750096 MB 577
You might resize at 688463450112 bytes or 688464 MB (freeing 61690 MB).
Please make a test run using both the -n and -s options before real resizing!
shrink file system  00:42:41    ( SUCCESS )
        
run simulation  00:00:16    ( SUCCESS )
        
ntfsresize -P --force --force /dev/sdb1 -s 696146572799 --no-action
        
ntfsresize v2012.1.15AR.1 (libntfs-3g)
Device name : /dev/sdb1
NTFS volume version: 3.1
Cluster size : 4096 bytes
Current volume size: 750153728512 bytes (750154 MB)
Current device size: 750153729024 bytes (750154 MB)
New volume size : 696146567680 bytes (696147 MB)
Checking filesystem consistency ...
Accounting clusters ...
Space in use : 688464 MB (91.8%)
Collecting resizing constraints ...
Needed relocations : 13097487 (53648 MB)
Schedule chkdsk for NTFS consistency check at Windows boot time ...
Resetting $LogFile ... (this might take a while)
Relocating needed data ...
Updating $BadClust file ...
Updating $Bitmap file ...
Updating Boot record ...
The read-only test run ended successfully.
real resize    ( ERROR )
        
ntfsresize -P --force --force /dev/sdb1 -s 696146572799
        
ntfsresize v2012.1.15AR.1 (libntfs-3g)
Device name : /dev/sdb1
NTFS volume version: 3.1
Cluster size : 4096 bytes
Current volume size: 750153728512 bytes (750154 MB)
Current device size: 750153729024 bytes (750154 MB)
New volume size : 696146567680 bytes (696147 MB)
Checking filesystem consistency ...
Accounting clusters ...
Space in use : 688464 MB (91.8%)
Collecting resizing constraints ...
Needed relocations : 13097487 (53648 MB)
Schedule chkdsk for NTFS consistency check at Windows boot time ...
Resetting $LogFile ... (this might take a while)
Relocating needed data ...
Updating $BadClust file ...
Updating $Bitmap file ...
Updating Boot record ...
Syncing device ...
Successfully resized NTFS on device '/dev/sdb1'.
You can go on to shrink the device for example with Linux fdisk.
IMPORTANT: When recreating the partition, make sure that you
1) create it at the same disk sector (use sector as the unit!)
2) create it with the same partition type (usually 7, HPFS/NTFS)
3) do not make it smaller than the new NTFS filesystem size
4) set the bootable flag for the partition if it existed before
Otherwise you won't be able to access NTFS or can't boot from the disk!
If you make a mistake and don't have a partition table backup then you
can recover the partition table by TestDisk or Parted's rescue mode.
shrink partition from 698.64 GiB to 648.34 GiB  00:00:01    ( SUCCESS )
        
old start: 63
old end: 1,465,144,064
old size: 1,465,144,002 (698.64 GiB)
new start: 63
new end: 1,359,661,337
new size: 1,359,661,275 (648.34 GiB)
calculate new size and position of /dev/sdb1  00:00:00    ( SUCCESS )
        
requested start: 105,482,790
requested end: 1,465,144,064
requested size: 1,359,661,275 (648.34 GiB)
new start: 105,482,790
new end: 1,465,144,064
new size: 1,359,661,275 (648.34 GiB)
check file system on /dev/sdb1 for errors and (if possible) fix them  00:00:03    ( SUCCESS )
        
ntfsresize -P -i -f -v /dev/sdb1
        
ntfsresize v2012.1.15AR.1 (libntfs-3g)
Device name : /dev/sdb1
NTFS volume version: 3.1
Cluster size : 4096 bytes
Current volume size: 696146567680 bytes (696147 MB)
Current device size: 696146572800 bytes (696147 MB)
Checking for bad sectors ...
Checking filesystem consistency ...
Accounting clusters ...
Space in use : 688462 MB (98.9%)
Collecting resizing constraints ...
Estimating smallest shrunken size supported ...
File feature Last used at By inode
$MFT : 3223 MB 0
Multi-Record : 424210 MB 107
$MFTMirr : 375077 MB 1
Sparse : 417430 MB 113
Ordinary : 696147 MB 762
You might resize at 688461799424 bytes or 688462 MB (freeing 7685 MB).
Please make a test run using both the -n and -s options before real resizing!
grow partition from 648.34 GiB to 698.64 GiB  00:00:00    ( SUCCESS )
        
old start: 63
old end: 1,359,661,337
old size: 1,359,661,275 (648.34 GiB)
new start: 63
new end: 1,465,144,064
new size: 1,465,144,002 (698.64 GiB)
move file system to the right  10:46:00    ( SUCCESS )

        
perform read-only test  02:52:08    ( SUCCESS )
        
using internal algorithm
read 648.34 GiB
finding optimal block size    ( ERROR )
        
read 16.00 MiB using a block size of 2.00 MiB  00:00:00    ( SUCCESS )
        
16.00 MiB of 16.00 MiB read
0.416654 seconds
read 16.00 MiB using a block size of 4.00 MiB  00:00:01    ( SUCCESS )
        
16.00 MiB of 16.00 MiB read
0.421104 seconds
read 16.00 MiB using a block size of 8.00 MiB  00:00:00    ( SUCCESS )
        
16.00 MiB of 16.00 MiB read
0.376677 seconds
read 16.00 MiB using a block size of 16.00 MiB  00:00:00    ( SUCCESS )
        
16.00 MiB of 16.00 MiB read
0.351134 seconds
optimal block size is 16.00 MiB
read 648.27 GiB using a block size of 16.00 MiB  02:52:07    ( SUCCESS )
        
648.27 GiB of 648.27 GiB read
648.34 GiB (696,146,572,800 B) read
perform real move  07:53:52    ( SUCCESS )
        
using internal algorithm
copy 648.34 GiB
finding optimal block size
        
copy 16.00 MiB using a block size of 1.00 MiB  00:00:01    ( SUCCESS )
        
16.00 MiB of 16.00 MiB copied
1.05289 seconds
copy 16.00 MiB using a block size of 2.00 MiB  00:00:01    ( SUCCESS )
        
16.00 MiB of 16.00 MiB copied
0.865193 seconds
copy 16.00 MiB using a block size of 4.00 MiB  00:00:01    ( SUCCESS )
        
16.00 MiB of 16.00 MiB copied
0.812184 seconds
copy 16.00 MiB using a block size of 8.00 MiB  00:00:01    ( SUCCESS )
        
16.00 MiB of 16.00 MiB copied
0.763636 seconds
copy 16.00 MiB using a block size of 16.00 MiB  00:00:01    ( SUCCESS )
        
16.00 MiB of 16.00 MiB copied
0.771607 seconds
optimal block size is 8.00 MiB
copy 648.26 GiB using a block size of 8.00 MiB  07:53:47    ( SUCCESS )
        
648.26 GiB of 648.26 GiB copied
648.34 GiB (696,146,572,800 B) copied
shrink partition from 698.64 GiB to 648.34 GiB  00:00:01    ( SUCCESS )
        
old start: 63
old end: 1,465,144,064
old size: 1,465,144,002 (698.64 GiB)
new start: 105,482,790
new end: 1,465,144,064
new size: 1,359,661,275 (648.34 GiB)
update boot sector of ntfs file system on /dev/sdb1  00:00:00    ( SUCCESS )

========================================

3

Re: user feedback and requesting guidance

move1tbifyoudare1 wrote:

GParted 0.11.0 --enable-libparted-dmraid

Versions 0.11.0 is outdated software.  There have been major changes to the underlying code since 0.11.0 was released.

We recommend that you use the latest version (currently 0.22.0) when partitioning.  One of the best ways to do this is by booting from media containing GParted Live.

A list of all improvements can be viewed in the NEWS file.

4

Re: user feedback and requesting guidance

Thank you for the headsup. I am on lemenentary os/luna and apparently I have the newest possible version from it's repos. Freya just got out... I guess I should switch.

5

Re: user feedback and requesting guidance

No worries.  If you discover a problem with the latest version, then please feel free to let us know.