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.