1. Will my Asus Z170 Pro Gaming/Aura mobo boot from an NVMe M.2-PCIe 3.0 SSD?
2. Is it really that likely that I'll have to clock my 3000MHz DDR4 down to auto/2133MHz for it to play nice with NVMe, as I've read is sometimes the case?
3. If booting from an NVMe drive isn't possible, are AHCI M.2-PCIe or AHCI M.2-SATA cards worth the expense, or should I just get a 1.8"/2.5" AHCI SATA SSD?
4. Oh, and Windows 10 does have decent native NVMe drivers now, right?
5. Lastly, is migrating my Win10 install from HDD to SDD just a simple matter of creating a partition table on the SDD and cloning the partition over from the HDD?
Sorry for the fuckload of questions.
I should add that NVMe is not referenced anywhere in the manual.
To anyone who cares: through a lot of googling I've worked out that yes the Asus Z170 Pro Gaming Aura does support NVMe1.1 over M-key M.2Gen3-PCIe3.0x4
http://hexus.net/tech/reviews/mainboard/96166-asus-z170-pro-gamingaura/?page=5
http://www.userbenchmark.com/System/Asus-Z170-PRO-GAMING-AURA/40284
http://www.intel.com/content/www/us/en/support/solid-state-drives/consumer-ssds/000022677.html
>>273121
1. You can boot a UEFI OS off anything, so long as there's a UEFI driver for it, and the EFI partition the driver is on is on a device the BIOS can read. tl;dr: yes you can, but you might need a USB key to hold the NVMe driver if the BIOS doesn't have one.
2. No frikkin idea. If you're overclocking the PCIe clock to get that RAM speed, you'd also be overclocking your SSD, which strikes me as a very bad idea.
3. M.2 PCIe is NVMe; M.2 mSATA is SATA. There's no difference other than the form factor. M.2 NVMe has the same compatibility issues NVMe has, and M.2 mSATA has the same performance issues SATA has.
4. Always has. The manufacturer drivers get extra performance by playing fast and loose with write barriers and write-through caching. Which is fine so long as your PC never crashes.
5. Kinda. UEFI gives every partition and partition table a GUID, and it's an understatement to say it does not like it if you clone a partition or drive without changing the GUID. Similarly, NTFS has a Volume Serial Number that Windows does not like to see duplicated.
If you're just cloning the partition, the procedure would be roughly as follows:
- recreate partition structure (paying attention to 4k alignment)
- clone old partition into new partition
- change VSN on old partition
- boot off Windows installer, repair boot (this will format and repopulate your EFI partition)
The way I did this last was:
- boot Ubuntu live
- install dd_rescue using dpkg
- resize the old partition to fit on the SSD using gparted
- dd_rescue the entire old drive onto the SSD using sparse writes
- clone the GPT onto the SSD using sfdisk*
- generate new GUIDs on the old disk using sfdisk
- change the volumeid on the old disk's NTFS partitions (I used another PC, a toaster, and Microsoft's VolumeID tool, but you can also just hexedit it).
* yes, that's right, GPT is such a snowflake that cloning the entire disk is not sufficient to clone the partition table.
>>273121
- oh, and of course "boot off a Windows installer and do the fixboot thing", because UEFI booting is so fucking fragile.
Back in the day, you could just clone disks, but now there's a partition table at each end, and GUIDs everywhere, and then the BIOS keeps track of the GUIDs and can't find the OS if you change them, and generally there's a lot more fucking about. The positives are you can now boot off stuff the BIOS and OS never even heard of; the negatives are you have what amounts to an OS loading before your OS does, so now you have two OSes you need to get working just to get your PC up.