Dual-boot Win7 and Win10 system with Primocache Topic is solved

[BonzaiDuck]

First, I absolutely positively have to have dual boot for these Windows OSes. I could explain why, but just assume that it is necessary.

The system configuration includes an i7-6700K Skylake, 16GB 3200 DDR4, a GTX 1070 graphics card.

For storage, the boot-system disk for both OSes is a 500GB ADATA SSD. It is a GPT partition. All the OS boot partitions and volumes are on that disk.

So in each OS, no drive letters are assigned to the portions of that disk and other disks which are exclusively used by the other OS.

A 2TB Barracuda hard disk is similarly split in separate volumes -- each assigned to one or the other OS, drive letters appropriately eliminated for the logical volumes not to be accessed by the currently booted OS version.

There is a shared 1TB drive for which only RAM-caching with no persistence between restarts is allowed. This, because either OS can operate on the same files of that disk, and so the caching only lasts for a particular OS session from boot to restart/shutdown.

Now this all works OK except for one thing. I have been experimenting with an NVMe M.2 SSD (250GB Samsung 960 EVO), and thought I should be able to create separate logical volumes of 100GB each and assign them exclusively to one or another OS implementation of PrimoCache.

So I would name an L2 storage volume "Win7L2Cache," and use it for Windows 7. In Windows 10, I would create another logical volume and convert it to an L2 volume named "Win10L2Cache."

The idea was that I should be able to use these separate volumes as caches with each cache exclusive to either OS.

But once I implement L2 caching for Windows 10 (after it had been defined and working in Windows 7 with its own 100GB cache), a reboot causes a predictable blue-screen BSOD after the Windows splash screen appears. The first time this happened, it caused me considerable panic, as I discovered that I cannot do bare-metal restores from my 2008 server with the USB key created for a particular workstation. Then I discovered that merely pulling the NVMe M.2 drive from its PCIE slot would allow me to boot into either OS without problem, as PrimoCache will drop a cache task or its L2 component if it doesn't find the disk in the system. And the system boots normally in either OS.

So I thought it would be possible to have separate caching volumes on the same physical drive -- in this case -- an NVMe M.2.

Perhaps you could explain why it isn't working, or why it is impossible for it to work that way.

The NVME M.2 250GB was an experiment, and it works fine for a single OS -- even for sharing a 100GB cache-volume with 40GB allocated to the boot-ssd under that OS and 60GB allocated to the Barracuda logical-volume assigned to that OS.

I was planning to replace it with a 1TB model, thinking I could now put both Win7 and Win10 OS volumes on it by cloning the ADATA to the NVMe. And I thought I could add each of two 100GB caching volumes assigned to either OS -- just to cache any SATA data disk and the Barracuda. But it appears that may not be possible, or further attempts could lead to disaster. Since the OSes will be on the 3,000+ MB/s (read-rate) NVMe anyway, I was thinking to now use SSD caching with an SATA SSD exclusively for the Barracuda HDD storage volumes.

But logic tells me if I pursue this plan, I won't be able to split even an SATA SSD into two caching volumes as I explained. More likely I would need a separate SSD for either OS and either logical volume on the barracuda assigned to that OS.

Can someone enlighten me so I can chart a path forward?

[Support]

So I would name an L2 storage volume "Win7L2Cache," and use it for Windows 7. In Windows 10, I would create another logical volume and convert it to an L2 volume named "Win10L2Cache." The idea was that I should be able to use these separate volumes as caches with each cache exclusive to either OS.

I think there shall be no problems for such layout. Just make sure that you don't use the same L2 storage volume for both OSes.
Otherwise, I have no idea why there was a BSOD crash.

[BonzaiDuck]

So glad you came back about this, Support.

THAT'S what I THOUGHT MYSELF -- if you're splitting physical drives down the middle for dual-OS, you'd only have to keep the caches as separate volumes even if on the physical drive.

Nor do I fault Romex for my difficulty, but the problem isn't my hardware, it isn't the GPT disks and volumes. It may be a misunderstanding about some things going on with the partitions and volumes on that disk that may not be properly configured.

And even if that isn't the case, HOW many potential customers would need or configure dual-OS boot systems, even though Windows has provided a boot-menu for this since before XP? We're talking about SERIOUS customers here like the forensic data-analysis guy (maybe his name is Greg?) who has used an entire NVMe 1TB card to cache his data disks. But it's less likely you would create a dual-boot double-OS system disk with that.

One thing I did not do was to cache the "system reserved" and "GUID" volumes on the disk for Win 7 and Win 10. But what happens, relative to the cache, with those volumes?

I'll say this -- if you guys can accommodate a dual-boot solution with PrimoCache in the future -- if not now -- that would be tremendous if there is some obstacle now to doing it.

Maybe there's multiple causation. Maybe this could be made to work with regular SATA SSD-caching disks -- I can't say. Maybe it has to do with the newer NVMe M.2 drives in conjunction with these other things. I can only say I am mystified by it.

I know there's no problem between Win 10 and Primo, because I have at least one machine working with that OS and Primo.

I just don't want to go through the reset troubles by trying it again. The problem has occurred three times, each time when I went into Windows 10 to configure the other half of the equation.

The best solution for the moment: configure the SSD caching under the OS being used the most, and cache only to RAM with the other OS. Also, I think I was wrong in assuming that you could "Prefetch previous cache" for the dual configuration with caching only in RAM -- it also seemed to cause trouble. But I'm sure that caching for the boot session duration only is safe.

UPDATE

I'm suspicious about my choice of PCIE slot for the NVMe. Skylake CPUs offer 16 PCIE 3.0 lanes directly. An additional 20 lanes are offered by the Z170 chipset, but they communicate with the CPU through an x4 equivalent using a DMI link. The slot where I located the NVME M.2 drive is the only PCIE slot on the motherboard with lanes that go through the chipset.

Since I've decided against a second graphics card, I'm going to use the PCIE 3.0 x16_2 slot instead. That would mean 12 lanes would be used -- 8 by the graphics card and 4 by the NVME.

I'm putting in a 1TB 960 Pro drive, anticipating a different caching strategy, because the dual-boot OS is now on an SATA SSD and will be moved "up" to the NVMe. I don't know if I want to test SSD-caching with boot volumes on the 960 Pro, and essentially, I shouldn't need SSD caching but for HDD storage. I could cache to a regular SATA SSD instead, and perhaps with RAM-caching.

I'm just not sure if I want to attempt the dual-boot configuration again without more assurance or information from Romex. Or from anyone. If it hiccups again, it will be another round of hardware removal, Primo reconfiguration and hardware replacement. If I'm going to put my OSes on the Pro drive, I'm more hesitant about going through that hiccup headache and even a chance of some unforeseen addition to the boot-problem it generates.

[BonzaiDuck]

SUPPORT:

I hope you catch this, if I avoid jumping up and down for attention by starting another thread about it.

I've put a 960 Pro 1TB NVMe into my system, replacing the 960EVO 250GB I had discussed before. I was able to clone the dual-boot system/OS SSD to the NVMe and resize the partitions and volumes, leaving a planned ~250GB unallocated space.

When I created two different Primo caching volumes -- one for each OS -- on the EVO, I explained that the next reboot of the system caused a BSOD, and removing the NVMe allowed me to boot again and delete the caching tasks before replacing the NVMe with nothing more than the inconvenience.

YOU SAID: "Just make sure that you don't use the same L2 storage volume for both OSes."

Did you mean "don't use the same physical disk?" Or don't use the same caching volume?

I'm thinking about putting the EVO back into the system, because there should be no significant impact on my graphics performance if I use the PCIE_x16_2 slot for the EVO. I think I could use the unallocated space on the Pro for one caching volume, and the EVO for another.

I would really like to make this work symmetrically for both Win 7 boot sessions and Win 10 boot sessions, without BSODs. Specifically, I'd like to be able to boot into either OS with an L2 cache for either, without resetting or destroying the cache each time I switch the OSes.

Is there any more "intelligence" about this forthcoming? Or any suggestions?

[InquiringMind]

Could you please confirm what it is that you are attempting to speed up with L2 caching? It would only make sense to use it on your HDDs but you say you are using L1 only on these?

[BonzaiDuck]

OK. Yes -- I selectively use it for hard disk HDDs where there are frequent reads. If there are frequent writes, I can choose to use equivalent of Intel SRT "Maximum" setting which defers writes and makes writes therefore faster. There would only be risk of system instability causing disk corruption, or for instance power-outage without effective UPS battery and system management. But you can turn deferred writes on or off.

So mostly for HDD reads. The faster the SSD and SSD cache for accelerating HDD, the higher speed accessing frequently-used HDD files.

What I have discovered about this dual boot situation is really explained in the PrimoCache Instructions/online-manual, and I'm embarrassed that I didn't go looking for it before I went on my rants in this thread about my problem.

It is a problem of offline writes. Moving between operating systems, I can do this if I avoid offline writes between systems on the volumes assigned to those systems. In the meantime, I'm trying to decide whether to add some extra hardware first with a 960 EVO in my PCIE-x16-2 slot, even though I have caching space on my boot-system disk. I'm beginning to think that putting the cache for any HDD volume on the boot-OS-disk could pose a risk. It is better to have even a single cache on a different physical device. So this makes dual-boot system slightly problematic at the moment. But since Romex covered it in the manual and I can read with understanding, there may be a good answer to it.

The more I can use NVMe M.2 drive-space for SSD-caching volumes to accelerate HDDs, I can cache several HDDs in one SSD volume, but if there is offline modification of one disk accessed by either OS, there cannot be a persistent cache between boot sessions, or either cache contents will be outdated or superseded by writes/changes from the offline OS. At least that's the way it looks now. I can't have two different caches of the same drive and one per OS, and if I modify the HDD source disk in one OS and the drive has persistent cache between the OSes, then there may be a problem.

If you have files shared between the OSes -- working files like Outlook, documents, PDF archives, photos -- you don't want to cache them in more than RAM during a boot session. That way, there won't be any offline writes that will be out of sync with the cache. They may be slowest storage access, but they only require smaller RAM caches to make them faster.

Somebody else may have a better opinion. But I'm really exuberant now. I got all the bugs out of my Windows 10, and the Windows 7 had been tip-top for the last couple months other than these other problems from the caching experiments. And I haven't fully implemented my "speed demon" features yet. But I know most of it will work.

[InquiringMind]

You might want to experiment with a ramdisk for shared data. With an image file, this should (mostly - power cuts and system crashes can still cause problems unless you use a Real Time Save image) avoid the possibility of data updates not being written to hard disk. Plus I don't think (well, I don't know - that's why I say "experiment" ) there is an issue sharing an image file between OSes like there is with L2 storage.

You will need to relocate files and folders to the ramdisk using either the Junction tool included in the Primo Ramdisk GUI (under the Utilities button) or the free Link Shell Extension utility.

But yes, for data shared between OSes on a multi-boot setup, L2 Primo Cache is best avoided.

[Support]

I'm sorry for the late reply because we were on holiday.

@BonzaiDuck, yes, as you've discovered, "offline writes" must be avoided when using L2 cache because PrimoCache has no way to handle such scenarios.

[BonzaiDuck]

You might want to experiment with a ramdisk for shared data. With an image file, this should (mostly - power cuts and system crashes can still cause problems unless you use a Real Time Save image) avoid the possibility of data updates not being written to hard disk. Plus I don't think (well, I don't know - that's why I say "experiment" ) there is an issue sharing an image file between OSes like there is with L2 storage.

You will need to relocate files and folders to the ramdisk using either the Junction tool included in the Primo Ramdisk GUI (under the Utilities button) or the free Link Shell Extension utility.

But yes, for data shared between OSes on a multi-boot setup, L2 Primo Cache is best avoided.

I don't see the need for that, or maybe someone could show me. But I've been using PrimoCache for almost 3 years now -- short 4 months -- on an accumulated four different systems, and I've never had the sort of problems you describe. Of course, I avoided using deferred-writes on the fastest storage devices which are also chosen as OS-system-boot disks or volumes. But copying data to and fro doesn't seem like the sort of thing want to do. I'd rather just share a repository between OSes so that there's no duplication nor any developing inconsistency on the drive.

On the matter of disk-backup image files, I can image and then incrementally back up a dual-boot system on the single disk. Further, it appears that Macrium Reflect will differentially or incrementally update a volume backup even if it hasn't been assigned a drive letter and isn't currently active at backup time in the other OS. So I only need to backup from within one OS boot-session to catch the entire enchilada. Don't ask me how Macrium Reflect is able to do that, but it is abundantly clear that it does.

Confusing cache data from two different OS installations in the same L2 cache -- possibly even on the same device with two different logical caching volumes -- definitely big trouble, as support confirms.

I'll just have to move cautiously to prove that what I want to do can be done symmetrically for both OS installations with their respective boot-sessions. Otherwise I'll have to choose a preferred OS to implement a single L2 cache.

Tomorrow I will add the original 960 EVO to another slot in the system, remove the old L2 caching volumes on it, and run some performance benchmarks to confirm that I haven't pushed the performance limits of my hardware. If it all tests out, I may create my first L2 cache on that drive. We . . . shall see . . . .

I also think I'm moving closer to ordering another RAM kit and duplicating my total RAM available. I just don't relish the prospective need for testing it, and I'm not going to be so eager to see my hibernation file double in size.

[InquiringMind]

I don't see the need for that, or maybe someone could show me. But I've been using PrimoCache for almost 3 years now -- short 4 months -- on an accumulated four different systems, and I've never had the sort of problems you describe...

The ramdisk suggestion is about using a different tool (which has different strengths and weaknesses). If you're happy with your current config, stick with it. But if you want to speed up access to data shared between OSes and have that data stored outside of volatile RAM, then a ramdisk plus image file may suit your situation better.

... it appears that Macrium Reflect will differentially or incrementally update a volume backup even if it hasn't been assigned a drive letter and isn't currently active at backup time in the other OS.

Disk volumes are tracked by volume IDs, stored in the Windows Registry under HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices. Drive letters and their mappings to volume IDs are stored here also (look for key names \DosDevices\A: onwards). So any backup software capable of running on WinNT should be able to cope without drive names. You can also change drive letter -> volume mappings here (with care) but the boot volume will always be assigned the letter C:

...and I'm not going to be so eager to see my hibernation file double in size.

If your system is a desktop, why bother with hibernation at all? Suspend to RAM will be faster and, assuming your power supply is reasonably reliable, has minimal extra risk.