Arrrrggggghhhhhhhhhh. Moving partition 3GB to right to make space for larger swap cos I upgraded memory to 4GB. 14 hours of hell!
Nooo, I hate how it like says 4 hours then after those 4 hours it begins another 4 hour process! I find partition magic much faster, but I've lost data more often in the past than GParted. About three times each by GParted and Partition Magic I lost all my data. Of course it's backed up, but both of these partitioning apps are very unstable.
Well, it's been long ago since you posted this but, depending on what you're doing with your computer (and whether or not you use hibernation) I could have told you you likely didn't need to extend your swap file.
The biggest reason you would need to do that is if you use hibernate. During the hibernate process system RAM is copied to the swap partition and, when you take the computer out of hibernate it copies the information back to RAM. The only other reason is if you're using a RAM intensive software that takes more than 4 GB of RAM at a time (and I surely don't know what that would be!).
I have 2 GB of RAM and approximately a 3 GB swap file. I don't use hibernate, and I have never used the swap file. Oh, and I have edited videos and audio clips, which take a bit of processing power.
I was wondering something which I don't believe was ever mentioned in the post; before performing these partitioning operations, did you defrag the partition (assuming that it was FAT or NTFS in the first place)? If you are performing partitioning operations on a FAT or NTFS partition, it is highly recommended to defrag it as much as possible before performing the operation(s) (as well as back it up, obviously).
It is much less difficult for the partitioner to perform operations on a defragmented partition and therefore takes much less time. I recently moved a (approx) 25 GB NTFS partition to the left, and since I removed unnecessary files and defragged it to death, it took me about an hour to do the whole operation. This is with 15 GB used.
Something that will also help with speeding up the process is to eliminate as many files from the partition as possible. If you have another hard drive to back some of it up to and then delete those files from the partition, that will speed the process up as well. "Less data to move = less time."
Yes, a 450 GB partition is a bit large and will take some time, but with some preparation the operations can be made a lot easier and quicker.
About defragging first, I never thought of that, but would it matter? I'm pretty sure GParted does it sector-by-sector whether data is there or not. If there's like 100GB of free non-contiguous space doesn't it still take the same amount of time to move that empty area as it would if data was scattered there?
Forum DOs and DON'Ts
Please use CODE tags
Including your email address in a post is not recommended
My Blog
No, to perform the actual resize, the filesystem itself is essentially truncated -- no free space is moved around needlessly. This truncation can only happen if there's no data blocks towards the end of the partition. Last time I checked GParted didn't do any logical filesystem defragging in order to empty the space at the end of the partition in preparation for the truncation -- this is left to Windows based filesystem defraggers.
However, any other moving of the partition obviously happens sector by sector and takes no notice of the filesystem blocks in the partition, so will take the same amount of time regardless of the fragmentation state of the filesystem in the partition.
"Python, the language that wraps itself around a problem to squeeze out a solution, swallowing it whole."Linux user number #14284
"A journey of a thousand miles begins with a single step." - Confucius.
Well i try to read all "conversation", but its endless.
Thank you for sharering your mistakes, cause i was about to do the same on my ps3 (320gb hd, 250gb for ubuntu and 70 for ps3 OS). I will backup everything (important stuff) to the original 40gb HD (now external), format from the beginning and reinstall ubuntu.
Hope that takes a few hours not days. LOL
What a useless piece of software Gparted is! To resize the same partition Acronis and most any other partition tool takes seconds!
Gparted developers should really have their heads checked.
ThinkPad W500: C2D 2,5GHz, 8GB ram, GPU Intel & ATI, Middleton BIOS, SSD + UltraBay HDD, USB 3.0 ExpressCard, BTRFS + full disk encryption.
Actually, if You look at what exactly GParted does You'll see that it does fsck after nearly each operation (sic!); it also often does read-only test before doing an actual move, it chooses optimal blocksize etc. etc. I don't see what is the reason for all that redundance. Come on, if I wanted to check my partition integrity, I would do it myself. Because of that I saw several times the following scenario on large partitions:
1) fsck - 1 hour
2) shrink/etc. - a few seconds
3) fsck - 1 hour
No wonder why it takes so much time...
Anyone knows what's the point of all those time-consuming steps?
Michał Gołębiowski
Dell Latitude E6500: P8600 | Intel GMA 4500MHD | 15,4'' 1440x900 LED (matte) | 4GiB DDR2 | 233 GiB HDD 7200 rpm (with Free Fall Sensor).
Jabber ID: mgol /at/ jabster.pl - let me write in within my profile details, please!
Bookmarks