GParted eats my day…

Today, I wanted to shrink a partition by 5GB, and move it 5GB to the right. Well, I expected that it would take some minutes, but now it seems to take more than 5 hours, because GParted moves around the whole 87GB of the resized partition.

This is what happens:

  • Check file system for errors (30min)
  • Resize the file system (30min?)
  • Resize the partition
  • Check file system for errors (30min)
  • Move the file system
    • Read-only Simulation (!!!!!!!!!!!!!)
    • Do it (~5 hours)

It really should tell me that it takes such a long time. I mean, why does it have to copy all 87GB, when all I want to do is get 5GB moved to the front? It should free these 5GB on the filesystem, move them to the end of the filesystem, decrease the partition size and finish.

It should not copy 87 GB 2 times, and should not run 2 filesystem checks without informing me before how long this will take. Now I wonder what happens when it resizes my 110 GB extended partition to 105 GB, and moves it?

Bad software, bad day.

45 thoughts on “GParted eats my day…

  1. The problem is that I do not resize partitions normally, and so did not know the way this will be done.

    From my old Windows days, I remember that only the relevant parts have been moved by the partition software. This only took a few minutes.

    I simply expect to be informed if an operation may take a large amount of time, and I guess this is what all users want to know.

  2. What I want is simply a filesystem resize which resizes the filesystem in a way that the first parts are returned, not the last ones. Same for the partition.

    GParted gives you the impression that this is a very easy task.

  3. Are you using the newest version of GParted? About a month ago I was doing almost the same thing and it took 38(!!!) hours to resize 60 GB partion. But when I tried newest version, it was much faster. I think version 0.3.9 or so fixed a bug when counting the blocksize for copying.

    1. Perhaps. But a dialog telling the user a time estimate when the operation takes more than, say, an hour would be nice, as Julian suggests.

  4. Admittedly, it should’ve been smart and tried to find the fastest order to run the jobs in (shrink first, then move the newly shrunk partition). Of course, the reverse should also be recognized (move first, then grow if that’s what is needed).

  5. ‘What I want is simply a filesystem resize which resizes the filesystem in a way that the first parts are returned, not the last ones.’

    Obviously, filesystems are not optimized for that kind of operation. The contents of the filesystem are indexed by distance from the start, so if you want to move the start, you have to either:

    – make sure there’s room at the start, update all the indexes,
    rewrite the header
    – make sure there’s room at the end, and move the whole thing towards the end.

    Now the ‘update all the indexes’ phase is extremely complicated, and only needed for moving filesystem starts. You can imagine the tool authors not implementing it.

    During the complete ‘move the filesystem to the right’ phase, the filesystem is in a mostly unrecoverable state. Should the program encounter a read or write error, the complete contents of the filesystem would be lost. I guess that’s why it does the read-only test first.

    It would be nice though if gparted would only copy the parts that actually have data in them.

    You may be better off simply copying the data on the filesystem to another disk, creating a new partition and then copying it back. You should really do a backup before the move anyway.

  6. only moving the bits that it needs to would be good. i am sure a clever file system person could write that, given enough time. would it need things like renumbering all the inodes and stuff like that?

    all the checks. i am glad gparted does everything it can to keep my data safe. if there were a fast and safe button i’d use safe.

  7. I reinstalled my wife’s Ubuntu AA1 laptop with Debian Lenny today; that included resizing the 120Gb (whole-disk apart from swap) partition to 100Gb (was /, now /home) to allow for a 20Gb / partition for a clean Debian / Dual-boot install.

    Although I didn’t move anything, the process took less than an hour. That’s using the Debian 5.0 install DVD, with 512Mb RAM, FWIW.

  8. Should you perhaps blame something else than GParted, for instance parted itself? I doubt that the nice GTK interface is making it any slower than the code it uses to do the resizing, which probably is not in gparted itself or is in gparted but almost directly copied from parted or similar. Also, depending on filesystem type there may be other reasons to shift the entire filesystem and not just part of it, however that will probably never be the case for any of the native linux filesystems.

    1. I love playing the blame game! Good one.

      (I had one today too! Lifereas 1min20s startup time was all because of sqlite😀 yay and it still takes 1min20s to start)

  9. Exactly why I don’t resize anymore. I just delete it all and recreate with the new size(s). 10 minutes – 400gb.

  10. Among all above comments there is one short but very helpful posted by Lubomir:

    ‘I believe it is this bug: http://bugzilla.gnome.org/show_bug.cgi?id=546423

    I think everyone should check above link out and also change logs for GParted 0.3.9 and later versions before indicating what is the problem and where it belongs to (GP itself or its dependiences).
    Here goes another link with version changes:
    http://svn.gnome.org/viewvc/gparted/trunk/NEWS?revision=1064&view=markup

    As Julian said he was using GP v 0.3.8. Relevant changes related to the issue were introduced after that version.

  11. Hello!
    Very Interesting post! Thank you for such interesting resource!
    PS: Sorry for my bad english, I’v just started to learn this language😉
    See you!
    Your, Raiul Baztepo

  12. Hello! I have the same problem. I am not amused…

    I wanted to delete sda4 and grow sda3 into this newly unallocated space. No need to move anything, right?

    Wrong! For some reason, GParted is currently copying every. single. sector. of the entire 582GB partition sda3. There is no room to move sda3 to the left, because sda2 is there. Why is it copying sectors in a partition that isn’t going anywhere? Where is it putting them? Surely it isn’t loading the sectors and then writing them to the exact same place as before? The mind boggles.

    This operation should be instant.

    It beggars belief that someone actually thought this additional action contributes to data protection. To my untrained eye, unnecessarily copying 582GB must only increase the risk of data loss compared to moving nothing but the outer boundary of the partition.

    There is no estimate given before GParted actually starts. However, by then it is too late.

  13. GParted seems to approach partitioning differently to other products I’ve used, even Vista’s built in disk management partitioner. It seems to want to move every bit of data in a partition being resized, even if the bloody partition is being grown by 5% into unallocated space!

    Obviously I don’t understand the program’s genius, and every linux fanboy says “it’s because of all the safety checks, would you rather lose all your data?” Oh toss off you braindead freaky-deakies! Try growing a partition into unallocated space in (oh no!) Vista and see how long it takes. On my laptop, it takes about 15 seconds to grow an 85Gb partition to 90Gb using Vista’s disk tools. I’m doing the same thing in Gparted (0.3.9) right now and so far it has taken 1.5 hours and I’m pretty bloody pissed off about it.

    What the fanboys/girls don’t want to admit is: GPARTED DOESN’T KNOW HOW TO DEAL WITH NTFS PARTITIONS PROPERLY. And it probably never will. Take that back to your dirty little Slackware hacker-holes you cheetoh eating freaks.

  14. I’ve yet to hear that Vista’s tool is able to work with ext3 or any other filesystems besides which MS created.

    You’ve just made an idiot of yourself.

    1. Tee hee, was I talking about ext3? Noooooo. I’m strictly talking about NTFS. Who’s the idiot now?! Pucker up!

  15. I’m shrinking ext3 partition 465.76GiB to 126.96GiB for about 1 hour and 40 minutes already. Gparted has no real progress bars, no time estimates, nothing that would indicate for how long I have to endure this torture.
    This is the first and last time I’ll use this piece of shit partition editor.

  16. I been repartitioning for 2hrs now and during those 2hrs the damned thing keeps telling me there is more than 3hrs remaining. It can delete and shrink partitions in seconds, but when it comes to growing by a few gig, it takes fuck knows how long.

    It should be faster but it ain’t and besides it is free so what you expect? Paying hundreds of $ for micro$oft, yea the arseholes beeter be able to do shit fast.

  17. I have used GPartEd for about 5 years now and had maybe one loss due to a knackered HD.

    I have lost count how many times use it.

    Easily once a week on average, sometimes many times a day.

    All I can say is it is the ONLY tool I would trust.

    Plus if you are using a Ubuntu live disc, you can get on with other stuff while it is partitioning, remote into another machine or access the internet/email even temporarily install software and do some work if you have enough RAM.

    It’s not perfect, but it’s good where it counts, i.e. not trashing your data.

    Hats off to the free solid partitioning tool and the guys who wrote it.

    If you have problems then submit bugs or suggestions to the developers and stop bloody whining.

  18. OMG !!!
    Gparted is currently resizing the 500GB FAT32 parition of my USB hard drive to 200GB and moving it to the end of the disk.
    I Googled a little to find out why it was so slow (it is running since 10 hours now) and now I read your blog… 5 hours for 5GB ? OMG my 500GB resize will never end !!!

    1. AH ME TOO. it’s been going for 3 days now and it hasn’t even started creating a new 20GB partition.

  19. I am using the gparted from 9.10 ‘Karmic Koala’ and it says it will only take 33 minutes on my 111.86 GB filesystem move.

  20. 45 Minutes – i envy you.

    I’m using the latest gparted. I have 2 partitions on an 81G eide disk and want to move them to a 79G sata.

    I am only shrinking the first (boot) partition which is 5GB. All that is on there the basic windows boot files, 2.?gig swap file, and not even 100meg of dell drivers – 53% unused. All the windows system files are on the second partition. This partiton has been defragged and is NTFS.

    I started to shrink this partition and started 4pm yesterday eve (saturday). Currently it is 12.19pm and the numbers grow larger, but the end is not insite😦

    As of monday I am away all week and do not want to leave to machine on for 5 days. Besides wanting to get some work done on that machine, I also wanted to upgrade the system which now it looks like next week.

    A really big bummer all round😦 😦 😦 !!!

  21. okay geniuses. gparted uses libparted. fact: ntfs partitions take longer to resize than ext ones. also, this little gem: “Applying all listed operations. / Depending on the amount and type of operations, this may take a long time.” Should be warning enough for anyone. Also, you can use a different partition editor that isn’t free as in beer that may be faster, but good luck doing it from within linux. Personally, I’m using gparted to save me the hassle of reinstalling windows 7 to a raid 5 cluster I’m building. I could have done it without but it would have taken me just as long to reinstall windows as to wait for gparted. sure, it’s on the ham sandwich connection, but at least it’s automatic.

    The magic words are YMMV, RTFM and DBIIF (don’t bitch if it’s free). You take the time to learn a language, write a robust library, include a frontend for it, make it rock solid stable and then GIVE IT AWAY. THEN you will have earned the right to complain about the hard work of others.

Comments are closed.