What is the fastest way to resize a large partition?

Due to a new HDD Configuration I am currently handling larger backup/resize tasks with partitions between around 900GB, which are 70-90% full.

some background:

First thing I've noticed was, that the Acronis TrueImage version from Western Digital was extremely slow while running it under Windows 7, even though on high priority. To create a normal backup for 650GB of data (900GB partition), it would have taken 3 days! The same task done with the Boot CD version of this Acronis version took about 2 hours (SATA3 copy from one disk to another, both around 110MB/s).

Now, after I have done all my backups, I've wanted to remove some obsolete partitions and resize the leftovers to full HDD size. Of course, usually this takes quite some time - in this case for this 900GB partition, to extend it to 931GB (30GB+ from front, 1GB+ from end), it will take around 6 hours (using gparted)!

Had I known that earlier, I would have just restored the image. But no - first it showed a reasonable time of 1:45h and 0 of 1 operations, but after finishing 1:45h it started again, only this time with 4h to go, still 0 of 1 operations, but now it was copying instead of moving.

Question:

However, why has it to be this slow to resize a partition? I am asking for a good explanation. This has bugged me, since I started partitioning - why does it require to copy all the data around, can't it just stay in place?!

Jook

Posted 2012-11-29T02:05:59.550

Reputation: 1 745

Possible duplicate of Resize primary partition

– Ramhound – 2018-03-24T15:27:29.600

Not an explanation,, sorry, just a recommendation that you try the excellent - and free - EASEUS Partition Manager from http://www.partition-tool.com/

– Mawg says reinstate Monica – 2012-11-29T02:52:37.890

thanks, looks promising, however, I could not find out, if it would just "attach" empty space in front of a partition, which is to be resized, or if it would move it there. might test this on the second one, if there will be no other definite solution. – Jook – 2012-11-29T03:29:20.057

2There are simple technical limitations to how "fast" a partition can be moved/resized. If the beginning of the partition is moved, usually all data has to be moved forward, or at the very least all data before an amount of free space adds up to the distance the partition is moved on disk. When the partition is shrunk, all data contained in the shrunk area needs to be moved into the free space that remains. There's no way around it. Also, under normal circumstances, process priority should have very little effect on I/O throughput. – oKtosiTe – 2013-03-26T09:07:01.470

@oKtosiTe usually all data has to be moved forward now, if you say usually, does this imply there IS in fact another way or not? Because that is the question here. Can't a resize of a partition be done without copying, when adding free space at the beginning of it? is this technically impossible? – Jook – 2013-03-27T01:34:15.917

@closeVoters - how is this question not constructive?! i am not asking for a debate, eighter it is technically impossible or not - eighter there is a tool, which is able to do such resize operations differntly or not. I do not see any room here for a debate. – Jook – 2013-03-27T01:38:48.970

1Although it may hypothetically be possible to add free space to the beginning of a file system (assuming there was... space available to add this free space to the beginning of the partition) and only rewrite the necessary parts of a file system to compensate, this would still take longer than adding free space to the end of the partition. As far as I'm aware there are no tools currently out there that do this to any of the most popular file systems today (NTFS, FAT32, exFAT, ext2/3/4, HFS+). Perhaps because it's harder to implement, perhaps because it's less safe in case of power loss etc. – oKtosiTe – 2013-03-27T07:52:38.317

1As for the vote to close: the title asks a debatable question (which doesn't match the question in the body). If you can rewrite to title to be more constructive, I believe this question will be a fit for Super User. If the question does end up getting closed, you can always request it to be reopened explaining that you have done so. – oKtosiTe – 2013-03-27T08:12:01.583

Answers

Resizing a filesystem is typically very quick - you just need to extend everything, writing new metadata into the empty space, etc...

What is slow, however, is moving a filesystem. As far as I'm aware, there is no way to extend a filesystem from the front (which is what you're ideally after). This is because you'd have to rewrite all of the file addressing information.

Consider the following diagram. By pulling the start of the partition forward, we've changed the address of the red/green/blue files, and even the end of the partition. You'd also need to be careful with alignment of the data, and other more technical aspects - the whole thing is a very complex operation.

As this isn't something that is simple to achieve, you instead move the whole filesystem, and then extend it.

This will, due to the nature of the operation, take a long time.

What you're doing (extend from front and back) will actually be executed as two operations:

Move the whole filesystem forward
Extend the filesystem

Attie

Posted 2012-11-29T02:05:59.550

Reputation: 14 841

As @Attie said expanding a partition to the right is easy and fast. Going to the left requires the whole file system to be moved.

Before I move to the left, I always shrink the file system to its minimum size first. That way it has a smaller amount of data to copy.

If your file system only has 50gb of data then it only has to move that much saving hours of time.

After shrink, then moving left, then finally expand it to the right as the last step.

Unfortunately, you say your hard drives are 70%-90% percent full so your saving are going to be far more modest.

cybernard

Posted 2012-11-29T02:05:59.550

Reputation: 11 200

True, though a shrink may incur a large amount of moving files within the filesystem, bringing them to the front to close up the gaps... so that in itself can take a long time. "Shrink" + "Move" may even take longer than simply moving the whole thing. – Attie – 2019-03-06T16:44:00.663

@Attie If you shrink it too much then yes, it can take longer to shrink, but if you knock it down to 10gb of free space it should take more than a couple minutes. – cybernard – 2019-03-06T22:32:02.707

-2

Try to use GParted LiveCD. It will take 4-5 hours: https://gparted.org/livecd.php

cvbnm90i

Posted 2012-11-29T02:05:59.550

Reputation: 1