Log in

No account? Create an account
Off in the distance
my journal
May 2016

The Bellinghman
Date: 2010-08-19 17:17
Subject: When logic fails
Security: Public
Last night, we used Acronis to clone bellinghwoman's main hard drive. The existing drive was 80 GB, split into two equal partitions. The target drive was 2 TB, and we decided that it should be partitioned as ~1780 GB for C:, and ~70 GB for the other partition. (Yes, that sums to 2 TB, as measured by drive manufacturers.)

This requires some manual picking rather than the 'just do it' option, but we picked the relevant settings, let it reboot so it could get exclusive access to the drives, and off it went, while bellinghwoman retired to bed.

It took me a little while to note that it was actually copying the first partition to a 932 GB target.

And it copied the second partition to a 932 GB target partition.

Oh, thought I, it screwed up, we'll have to retry once it's finished all of this.

And then once it had finished copying that second partition, it started resizing it back down to the size we'd asked for.

And once it had finished that, and there was space before that second partition, it resized the first partition all the way up to the size we'd asked for.

And it finally finished, leaving the right partition size after all.

I'd love to know just why on earth it didn't make the target partitions the right sizes in the first place.
Post A Comment | 4 Comments | | Link

Barry: 12 Wizard Speed Time
User: hobnobs
Date: 2010-08-20 11:04 (UTC)
Subject: (no subject)
Keyword:12 Wizard Speed Time
I know that some controllers/systems have a problem creating and/or writing to volumes larger than 1TB (or 932GB in real money), so it may be related to that. (Possibly software, possibly hardware.)

Alternatively, if the drive was already a single partition, NTFS stores a copy of the MFT exactly in the center of a volume so the system could have been working around that as a safety measure. (Unlikely, but I can't think of many other reasons for something to split at the midway point, other than the first suggestion.)
Reply | Thread | Link

The Bellinghman
User: bellinghman
Date: 2010-08-20 11:20 (UTC)
Subject: (no subject)

At the half-way point, it had converted a pair of 37 GB partitions to a pair of 932 GB partitions.

Then it did the resizing, with one partition ending up much larger, and one much smaller. It could surely have made the latter its final size to start with.
Reply | Parent | Thread | Link

Barry: 00 Bikkits
User: hobnobs
Date: 2010-08-20 13:15 (UTC)
Subject: (no subject)
Keyword:00 Bikkits
I'd guess it's a simple way to make sure the smaller partition was at the "end" of the drive, and ensure that it could upsize the main partition afterwards.

Only way I can think to test that is to redo it with the smaller partition "first" on the drive... and see if it still creates a large partition for it.
Reply | Parent | Thread | Link

The Bellinghman
User: bellinghman
Date: 2010-08-20 13:22 (UTC)
Subject: (no subject)
But it has to have better control than that anyway, to ensure that when it resizes the second partition, it's shrinking it towards the end.

And anyway, changing partition sizes is almost instant if you don't have to worry about the data in them. As far as I could see, this process involved it creating the new first partition at 932 GB, and spending 20 minutes or so copying the source data in, doing the same for the second partition, and then in-place resizing the partitions with their data in.

So half the entire time was spent creating and populating two partitions, the other half was spent resizing them.

You can see why I was puzzled.

(And no, I am not redoing it.)

Edited at 2010-08-20 01:24 pm (UTC)
Reply | Parent | Thread | Link