AN INTERESTING DEVELOPMENT: Migrating my new SKYLAKE to NVMe.M.2 system disk

[BonzaiDuck]

I would not have discovered this if I weren't intent on increasing both system-volume sizes for my dual-boot Win7/Win10 -- already located on my brand new, hyper-expensive Samsung 960 Pro 1TB.

Here's the history of it.

I struggled with slipstream disks to install Win 7 first of all. The slipstream was required for ASUS USB3 drivers, and without those drivers, for some reason the install hangs at target-disk selection. so . . . I got that right.

Then, we had the wonderful option to get Win 10 free after the deadline last summer, so I did that. I chose to burn the install files/ISO to DVD -- previously relying on USB for it.

So the plot thickens. Of course -- the Win 10 puts a 300MB EFI partition/volume on the system in addition to the Win 7 100MB "system-reserved." Fine and dandy. A FAT partition, no less, but --hey-- that's what it does. Doesn't save you 15% on your car-insurance.

Ultimately, the dual-boot system resided on an ADATA SP550 480GB SSD. Didn't wonder why the ADATA's performance seemed just a tad low. It was "good enough."

But I'm sure I checked the alignment on that SSD -- BEFORE! -- BEFORE, I say! -- I installed Win 10 as the second bootable OS.

So the next step -- contemplated and agonized over months while people were waiting for the 960 Pro and EVO to ship -- was to replace the ADATA boot drive with the NVMe M.2 PCIE x4. And I've scattered a few posts around, as I clean up the loose ends.

I used Macrium Reflect Free to do the multi-boot clone within Windows 10. Certainly the only utility I'd seen thus far that mentions -- and recommends options -- for a "multi-boot source disk." And that was all good and wonderful.

But I couldn't figure out how the Pro spec of 3,500 MB/s seq-read and 2,100 MB/s seq-write would fall down to maybe 2,900 and writes even as low as 1,500. Every time Magician would occasionally benchmark the drive at 3,000 and 1,900, I'd convince myself that this had something to do with it being a boot-system disk.

Couldn't imagine anything wrong. But the Macrium Reflect cloning process only copies the partitions and volumes in the same size as those of the source. So I was left with about 506 GB of free space on the Pro drive. I also have a "plan" to use some of that space for 150GB SSD-caching volumes for maybe one SATA SSD and a 5,400 RPM 2TB HDD.

Further, when I'd initially experimented with a small 960 EVO and then more recently the large Pro, I created test partitions -- Simple Volumes, basic partitions -- just to run the test. And they came close to their full spec.

Macrium has a process for resizing volumes and moving them that seems convoluted at first, but it's really simple. You have to create a disk-image of the entire drive on a hot-swap medium -- I just used another 1TB 5,400 RPM spinner for it. You then set up a restoration process with the NVMe as target drive, and in the act of dragging/dropping the sequence of partitions and volumes from the image to the drive, you resize the drives of interest for that objective and select one or two other parameters to view and possibly change.

The program lists "alignment" for the partitions, and I went through to check them. I discover that my 300MB EFI partition for Windows 10 is not only a FAT partition, but an "XP(CHS)" alignment. To change, or not to change! the other option in the alignment drop-down menu is "Vista/Win7/SSD." And it dawned on me that anything but that option would likely cause a mis-alignment.

I even suspect that everything after that EFI partition/volume would then be misaligned -- I cannot say.

But suddenly, the performance of the 960 Pro is much closer to spec -- for reads and writes.

So HOW on EARTH did that EFI partition get "set up" that way? I didn' do it! I didn' do it!

Live -- and learn -- fellow geeks. Live -- and learn.

 

[Ranulf]

Gremlins man. Gremlins.

 

[BonzaiDuck]

Gremlins man. Gremlins.

Looking at my original post, I could almost feel sorry for taking your time with it! TLTR!!

I just can't tell how it happened. The drive was converted to GPT with EaseUS after initial installation of both OSes. Maybe EaseUS Partition Master did it, but I can't say.

 

[XavierMace]

I meant to mention in your other thread that your screenshots showed your drives weren't aligned.

 

[BonzaiDuck]

I meant to mention in your other thread that your screenshots showed your drives weren't aligned.

If you're speaking about the HDD that was cached, I also noticed that, but I saw elsewhere someone also observed it on their own and there was an opinion this was some error in Anvil.

Also, on the initial or temporary ADATA SSD boot-disk, I had checked alignment. But I would also deduce or guess that if one small partition/volume was not aligned properly, it could translate into the entire drive being out of alignment.

Acronis and other tools always seemed to assure proper alignment of an SSD. Macrium would also. But how that EFI volume came up as "XP(CHS)," is still the mystery. The EFI partition would have been created at the time Windows 10 was first installed. That's one possible point at which the anomaly might have occurred. The second point or possibility would be the conversion from MBR to GPT done by EaseUS Partition Master.

I just received an e-mail the other day from EaseUS tech support, apologizing that their software "did not support dual-boot" or they couldn't guarantee it -- for NVMe drives. But I didn't use their software for cloning to the NVMe -- I used Macrium Reflect.

I always take time in an attempt to "do it right the first time." Too much hurry or acting with any sort of panic or impatience always raises the costs of time and trouble.

UPDATE: I had occasion to download the program SSD-Life a week or two ago. The trial had expired, so I shelled out something like $15 and change. Turns out -- it doesn't "see" NVMe drives. All I wanted to do was check alignment.

So I opened MSInfo32 and did the arithmetic for each and every volume/partition. All evenly divisible by 4096 with no remainder. Looks OK to me . . . . now, anyway. . .