How I copied my existing partitions to my new SSD

Note that none of this is really anything new. I just thought I'd throw together a bit of info about what I did to get my current stuff onto my new X25-M G2 with properly aligned partitions.

I currently use XP x64 with four partitions on my drive. I have an unattended install setup that puts the main system files on C:, my profiles and other user data on D:, and Program Files and other apps on E:. F: is the remainder of the drive and acts as generic file storage. On a disk, this partitioning can have a minor negative impact, as you're forcing data to different sections of the drive. Even if C: and D: aren't full, you still have to go beyond them to get apps on E:. I mitigate this by having very small C: and D: partitions, while gaining the benefit of easy backups and rebuilds.

At least for now, I decided that I wanted to put my C: and D: partitions to the new SSD and mount the remaining space as a folder on my E: drive for apps that I wanted to speed up. The basic plan was to copy the existing partitions, hide the old ones, and put the SSD on the first SATA port and move the disk down to the second one.

I started by plugging the SSD into the eSATA port on the existing system. I initialized the SSD as MBR in the standard Windows Disk Management console. I ran diskpar (see this OCZ thread) and created a 10GB partition with a starting offset of 1024 sectors to align the partition with a block boundary.

I then used techspec6's partition alignment spreadsheet and W1zzard's Online SSD Alignment Calculator to verify that the partition really was properly aligned.

Next I created the second partition back in the Windows Disk Management console. I pulled up its info, and the alignment calculator told me that it was not correct so I deleted the partition. Since diskpar only works on clean disks, I needed to find a different way to create the remaining partitions that would allow for proper alignment.

I booted up PartedMagic 4.6. I saw the first partition created by diskpar. I created a second partition with the GUI. It's designed like Parition Magic, and is somewhat similar to the Disk Management console's interface. It simply asks for a partition size and how much free space to have before it. I put in the same 0 and 50GB that I previously entered in Windows. I also made sure to uncheck the option to round it to a sector size. I then made a third partition out of the remaining space. I had PartedMagic apply the changes and I rebooted to Windows to double-check the partition details with diskpar.

Diskpar showed that PartedMagic without rounding had maintained the alignment and started the new partitions on block boundaries. I now had properly aligned partitions of approximately the correct size created on the SSD. Because the start and end points were arranged slightly differently, the new partitions were not exactly the same size as the originals. I wasn't sure if my tools would properly align the partitions simply by copying them, so the minor size mismatch didn't really bother me.

I used BartPE and Drive SnapShot to actually copy the data. These aren't necessarily the best tools for the job, but I'm very familiar with them. The basic BartPE build plus your SATA drivers should be enough to access the drives. I used Drive SnapShot's backup function to make copies of my original C: and D: partitions to free space on the disk. It does compress the backups and only backs up the actual used space, but you will need some temp space other than the SSD to do it this way. After the backups were made, I restored them to the partitions on the SSD. Drive SnapShot copied the data to the new partitions with no issues, despite the minor size differences. To keep things simple, raise the default backup file size in the advanced options so that a single file can hold the entire partition backup. Disabling hashing should speed things up since this is just a temporary backup copy rather than part of an actual backup solution.

Once the data was on the new partitions, I booted back into PartedMagic. I changed the flags on the partitions to make the new C: on the SSD bootable, and changed the old C: and D: partitions to hidden. I then rebooted and was able to start Windows as usual, but from the SSD this time. Once inside Windows, I was able to map the third SSD partition to an empty folder on my E: drive by essentially following the second half of this guide (since the partition already exists, you don't need or want to recreate it with Windows).

I was left with my main OS files running off the SSD, plus some space for other apps I want to speed up. I was able to do this without having to reinstall or alter my current partitioning scheme.

Note that I was learning during this process and ended up doing a lot of booting back and forth. It's very possible that some of these steps could be consolidated. Also, I'm not extremely proficient with Linux, so it's also possible that some of these steps could be done right from PartedMagic rather than needing to boot back into Windows for something minor. FYI, PartedMagic shows partition details in sectors - multiply those values by 512 (at least for this drive) to get the values in bytes for entering into the alignment calculators.

Thanks for typing this up.

Thanks - I also found this interesting and useful.

Deleted

As an update, I originally mounted my last partition as the specific game folder that I was using it for. I still had fee space left on it that I wanted to use for other apps, so I made a slight change.

I mounted the partition as E:\SSD\ (note that you can mount a partition under multiple locations at the same time). I moved the game's folder under the new SSD folder, making it E:\SSD\Game\. I then removed the original mount that I had as E:\Program Files\Game\. I used Link Shell Extension to easily make a junction from E:\SSD\Game\ to E:\Program Files\Game\ - just right-click and drag the Game folder into E:\Program Files\ and select the option to create a Junction there.

You can do that with any app you want on the SSD. Just move the app's folder from E:\Program Files\ to E:\SSD\, then create a junction in E:\Program Files\ pointing back at E:\SSD\AppName\.

I also created a second mount for the partition directly to a drive letter. The SSD Toolbox and other utilities make their selections by drive letter, so that third partition wasn't an option in those tools. By mapping it to S: as well, I could then select that partition for tests and maintenance.

There's a trick to creating concurrent partitions on an SSD and keeping them all aligned with Windows Disk Manager. The trick is to align the first partition, obviously, and select a size for the first partition that is a multiple of the SSD's block size.

For example:

If you have a OCZ Vertex with 512k blocks:

Create and align the first partition. We will assume it's aligned to 1024k. The trick is to END the first partition on a block barrier. The easiest way to do this it to pick an exact gigabyte size for the first partition. It takes a little math.

Assuming I have a 30GB SSD and want to create 2x 10GB partitions and the third will be whatever is remaining. Need to convert GB to MB to get the exact number. 10GB x 1024 = 10240MB, which is what you need to enter to get an exact 10GB partition. By stopping the first partition at the end of a 512kb block, we will be starting the next partition at the beginning of the very next block, thus the second partition is aligned. Therefore, where the previous partition ends determines whether the next concurrent partition is aligned. If you think of the partition OFFSET as a tiny partition, it basically follows this same rule.

Jason

Yea... I think I would rather just do a clean install...

A clean install with Vista or W7 will give you a single correctly aligned partition, but it doesn't autoalign concurrent partitions on the same SSD. That's why a single partition is best for most and multiple partitions are only usefull with organization with SSDs. No performance boost like with HDDs.

Jason

Agreed and to be honest I don't really see the purpose of multiple partitions on a single drive anymore.

techspec6 said:

There's a trick to creating concurrent partitions on an SSD and keeping them all aligned with Windows Disk Manager. The trick is to align the first partition, obviously, and select a size for the first partition that is a multiple of the SSD's block size.

For example:

If you have a OCZ Vertex with 512k blocks:

Create and align the first partition. We will assume it's aligned to 1024k. The trick is to END the first partition on a block barrier. The easiest way to do this it to pick an exact gigabyte size for the first partition. It takes a little math.

Assuming I have a 30GB SSD and want to create 2x 10GB partitions and the third will be whatever is remaining. Need to convert GB to MB to get the exact number. 10GB x 1024 = 10240MB, which is what you need to enter to get an exact 10GB partition. By stopping the first partition at the end of a 512kb block, we will be starting the next partition at the beginning of the very next block, thus the second partition is aligned. Therefore, where the previous partition ends determines whether the next concurrent partition is aligned. If you think of the partition OFFSET as a tiny partition, it basically follows this same rule.

Jason

Click to expand...

Your math is right but you're slightly wrong on the description. This is due to the difference between megabytes and mebibytes. Megabyte can be used to mean 1000x1000, 1000x1024, or 1024x1024 bytes. According to your example, Windows seems to see "1MB" as 1x1000x1000 bytes and allocates exactly 1,000,000 bytes. Divided by 1024, that comes out to 976.5625KiB. If you use 1x1000x1024 you get 1,024,000 bytes which comes out to an even 1000KiB.

It's not that you're converting GB to MB, it's that you're entering 10,000MiB by telling Windows 10,240MB. Based on what you're saying, SSD blocks are 512KiB rather than 512KB (the x1000 defintion). The issue comes from Windows and the SSD using different byte values for KB and MB - if the blocks were really 512KB, then any number of MB should be an even multiple of that (since 2x512KB = 1MB). However, 2x512KiB != 1MB, which is where this issue seems to come from.

I don't really feel like repartitioning right now to see if it's a difference between the Disk Management versions in XP and Vista/7. I think this could be at least contributing to it. I just know that I entered 50,000 in XP and it wasn't aligned. I entered the same 50,000 in PartedMagic and it was aligned. Maybe if I get bored I'll play with some partitions on an old drive and verify that it's not just XP's old logic optimizing things for conventional HDDs or something stupid like that.

criccio said:

Agreed and to be honest I don't really see the purpose of multiple partitions on a single drive anymore.

Click to expand...

I can back up my D: drive and have all my user data saved - everything on my Desktop, everything in AppData, everything that I've manually saved to one of my "data" folders. I don't have to go searching for miscellaneous config files buried in system folders. I can format my C: drive and know that I'm not losing a single file containing user data, only Windows system files.

I copied my existing partitions mostly because I was lazy and didn't feel like reinstalling again. All of the above stuff only took like 20 minutes, excluding the actual drive backups (to another partition on the same drive). My last install took 18. I'm sure the SSD would've made it faster, but this way I didn't have to change a single setting - everything was just as it was when I shut down to install the SSD. And since I'm using XP, I would've had to do manual partitioning anyway for aligning the SSD.

@InvisiBill

I don't remember how XP disk manager handles it, but Vista/W7 considers 10MB as 10,485,760 bytes. I just created a 10MB partition on my spare 60GB agility to test it.

Jason

InvisiBill said:

I can back up my D: drive and have all my user data saved - everything on my Desktop, everything in AppData, everything that I've manually saved to one of my "data" folders. I don't have to go searching for miscellaneous config files buried in system folders. I can format my C: drive and know that I'm not losing a single file containing user data, only Windows system files.

I copied my existing partitions mostly because I was lazy and didn't feel like reinstalling again. All of the above stuff only took like 20 minutes, excluding the actual drive backups (to another partition on the same drive). My last install took 18. I'm sure the SSD would've made it faster, but this way I didn't have to change a single setting - everything was just as it was when I shut down to install the SSD. And since I'm using XP, I would've had to do manual partitioning anyway for aligning the SSD.

Click to expand...

I don't know why couldn't you just make an image of C drive or something, and do a clean install..