Bad-ass Caching SSD+HDD through NVMe 960 EVO 250GB

Checked my e-mail today and found the response to my inquiry with Romex. Here it is beginning after this paragraph in boldface. I've found some other options that do what I want: one of them -- eBoostr -- isn't validated to work in Windows 10. No good. The other one is MaxVeloSSD -- a German outfit, somehow legally incorporated in UK. I may look at the Trial version of EliteBytes MaxVeloSSD, after their tech-support answers some of my questions. But if Primo's tech-support is being forthright about this, then I shouldn't sweat the minor shortcoming if the program is really caching to SSD. The statistics in the Primo GUI shows that it's being used. Because of my mishap with the SSD caching volume the other day, it looks more and more like it is working properly. And I can wait for version 3.0, because I'll get it free as far as I understand. More of my comment follows the letter. Also, it appears that whenever one of these programs shows stellar results exceeding ISRT, some company -- Western Digital slash HGST for instance -- buys them out, then doesn't offer the software. Here's the tech-support response, and XavierMace or anyone is invited to comment -- names edited to protect the guilty:

Dear [BonzaiDuck]

Thank you for your kind attention to our product!




Benchmark tools such as CrystalDiskMark, Anvil, and AS SSD test disk speeds by following two steps.


1. Preparation step: Create/write a test file with a specified test size first. This test file is usually 1GB size, and users can change it by setting the test size.


2. Testing step: Read/write the test file multiple times, and then calculate the speed.




When you set PrimoCache's level-1 cache size bigger than the test file size, the test file will be fully stored in the level-1 cache during the preparation step. So later in the testing step, benchmark tools actually read/write the file from the level-1 cache. That's why you see big performance boost.




For level-2 cache, in order not to affect other applications' tasks, PrimoCache only poplulates level-2 cache when it detects Windows is idle. Besides, currently level-2 cache doesn't support write-data. So during the preparation step the test file will not be stored into level-2 cache and in the testing step all reads/writes will be completed on the target disk.




In the coming PrimoCache 3.0 version, we'll support level-2 write caching. You'll see the different testing results then. Currently I think you may just see the performance boost with level-2 cache in real usage scenarios.




Please let me know should you have any questions.


Thank you.





Best Regards.


------------------


[The Tech-support guy]


Romex Software Support Team

Now, the update on my "latest experiences." My Media Center was freezing during live broadcast today. I re-ran the channel scan for HD HomeRun PRime, re-set WMC, pulled one of the Silly-Dust HDHR'-s off the network, then the other -- no problem. Then discovered my HDD LED was solid red, with the disk activity on the dedicated media volume without any caching.

I can count them all on one hand, but this is the fifth HDD to go south on me in more than 25 years. A WD Blue 1TB drive. Probably -- too many Breaking-Bad episodes from a couple weeks ago with the five-season marathon, Yo! Know what I'm sayin'? Better call Saul! I'm copying my files from it as I speak, and will probably try to save the DVRs and movies one at a time before I blow a hole in the drive with the Weatherby .457 Magnum bolt-action.

Maybe it was a bad batch from Heisenberg, but I think it was just that the "drive went south."

I'm going to add a post to this thread in case anyone is interested in the results.

The experiment with PrimoCache was "mostly" a success, as you discover that SSD-cache fills up slowly until there's none left.

Primo will make the OS check the RAM cache first for needed program components or data. If it doesn't find it, it will go to the SSD cache to find it. You cannot see the benefits just for creating the SSD cache and expecting either benchmark programs to reveal the advantage, or see the advantage right away, because the SSD cache fills up stealthily while the system is idle. Once you've used various programs or games from a cached disk, you will see how much faster things are, even if you reduce the size of any RAM-cache associated with the source disk and force the system to look in the SSD-cache.

The DUal-Boot downside: I have posted a query to the Romex forum about my unpleasant discovery. I cannot get an installation of Primo in both OSes to allow division of a single storage device -- in this case, the NVMe -- into two caching volumes each exclusive to either OS.

Even when I was able to create the caching volume for Win 10 on a remaining 100GB of unallocated space on the NVMe, it results in a BSOD at boot time until you remove the NVMe entirely. At such a point, you would be advised to enter Windows 7 and eliminate Primo's recognition of the two caching volumes leaving the NVMe clean and unallocated. Then you simply reinstall the NVMe M.2 hardware. The volumes will appear on the disk just as you had created them, so you'd delete them so ANY caching volume -- a single one -- can be created.

Unless PRimo tech-support tells me I can actually use the same, single caching volume on the NVMe to cache BOTH OSes (something that just intuitively seems impossible or unwise), I'm beginning to suspect that you need a SECOND physical caching SSD for the other OS if the NVMe is already used by the other one.

Of course, this adds more complexity and trouble -- uses more SATA ports if you don't have room for a second NVMe drive. For me, the only place to put such a thing would be in the PCIE-x16_2 slot, which would otherwise be held back anticipating an 2x SLI configuration. Otherwise, you had best use another SATA SSD to cache the second OS.

I don't think Romex anticipated a dual-boot OS possibility for this, but I was hoping they had.

I'm about ready to pull the string and simply get a 1TB NVMe for direct OS storage. If the OS volumes are to be accompanied by a caching volume for SATA storage, it will have only one such item for a single OS only until I hear how using two as I'd planned could work.

So, assuming it's not possible to split an SSD into two PRimo caching volumes -- one for each OS -- what's the next best bet for a dual-boot system that I can verify TRULY WORKS?!

RAM-caching, such that either OS will save the cache for next boot time. I've verified that the dual-boot RAM-caching with "persistence" will work, as would the case where you don't save the cache for next boot-up. But your Windows start time will be delayed. Your RAM must be absolutely flawless, or your could run into trouble -- generally. One would then be tempted to double a 16GB RAM configuration into a 32GB setup -- larger for people doing specialized work that could take advantage of large cache sizes. And if you want to hibernate your system with a minimum 50% (of RAM) Hiberfil.sys, you will rack up some TBWs on you NVMe just because of it. Of course, for 32GB you could argue the Hiberfil.sys would default to 16GB anyway with half as much RAM. That would then be your choice. At least, a 960 Pro NVMe would offer up to 1.2 Petabytes of TBWs.

As it stands, SSD-caching by itself does not contribute to accelerated TBWs on a typical user workstation. Once the cache is full, the only thing that changes the contents would be use of a new program or data set that wasn't part of prior use. The cache would make room for it, pushing out some of the cached material from the earlier usage regime. But that's what you'd expect.

I had noted before that a 2-year-old system with a 60GB SSD-cache had only racked up some 6 TBW during that time, and the cache had filled up.

Just in case anyone looked at this, I've made a judgment based on the troubles I've faced trying to make Primo work in a dual-boot system. Without additional guidance by the SW house, I advise against implementing Primo in BOTH operating systems of a dual-boot setup.

Considering that you have "system reserved" and the 300MB UEFI Windows 10 equivalent or any others for GPT partitions, there are variables I cannot assess for how it may go "wrong."

So the $130 experiment "succeeded" -- you can use NVMe-M.2 for SSD-caching, in one OS. You're best not to set the other OS up with it until you plan to use that OS version frequently. At which point, I'd disable and eliminate the caching tasks for the OS you used more frequently before that.

I may pull the string on a "big" 1TB Pro or EVO soon. If anything is cached, I may even use a run-of-the-mill SSD. But not with Primo setups on both OSes.

FrostByghte said:

BonzaiDuck,

I registered just to say w00t thank you for all the testing and feedback. Granted this might not be something the layman would want to attempt but I always find experiments and feedback like this good fun. So thank you much.

Click to expand...

There seems to be a support assumption over in the Romex forum that you can cache to two different SSD volumes under each respective OS. Nobody there has answered my responses, though. Eventually, I may cautiously attempt testing it with DIFFERENT DEVICES (Disks) as opposed to putting two volumes on one disk.

I replaced the EVO with the 1TB PRO drive. Tomorrow I may put the EVO back in the system and use the remaining PCIE-16-2 slot. Right now, the dual-boot configuration is clean as a whistle.

The problem in defining a cache configuration seems to be exclusively that of avoiding "off-line writes" to either the source disk or the cache. I think it's still "do-able." But I'm not going to hurry. This system is plenty fast without Primo SSD-caching for the moment.

VirtualLarry said:

The same issue can occur ("off-line writes"), to a filesystem that has an OS that has been hibernated, and then dual-booted to another OS. If you write to the hibernated OS partition, or really, any filesystem that was mounted at the time that it was hibernated, you can really screw it up.

Click to expand...

That's certainly understandable. Right now, each OS is separate. The hyberfil.sys is written to the appropriate boot-system volume at hibernation, restart or shutdown. It shouldn't matter which OS is booted next, but hibernation occurring normally and booting normally would lead to "Resuming Windows" normally to avoid the Windows OS-selection menu completely. If one brought a system out of hibernation but interrupted the process before "Resuming" to enter the BIOS, there could be troubles, even if Windows gives you a chance to resolve them in passing. But with any kind of unmanaged reboot, either OS would have its own hiberfil.sys. It's probably good regardless to be mindful of how to clean up hibernation or simply start a new file through a command-line execution.

At present, my system works flawlessly, but I'm only able to hide partitions and volumes related to the unbooted OS from the one currently booted by deleting any drive-letter assignment to them. I'm wondering if I can actually "unmount" those volumes within either OS that doesn't need to see or access them. I would think they would emerge as mounted in the next boot session of the same OS. I'm not really sure. Certainly, switching OSes, you wouldn't want them to be "unmounted" at boot time.

Even my pagefil.sys is created separately for either OS on an HDD partition/volume assigned specifically to one or the other OS. I don't have any problems there, either.

But if you had an SSD-cache of such a drive, you definitely wouldn't want to use the same cache between the OSes, and you definitely wouldn't want offline changes to take place on the accelerated-HDD partition/volume that is cached.

So there are features of cache tasks that allow for more control -- choosing not to load a cache task at boot time, for instance. You can lock a cache's contents -- that's another possibility. But the more you explore these possible options (if they exist) for a dual-boot system, the more manual steps.

Even without this caching arrangement, dual-boot is no Mainstreamer aspiration. It can be made to work very well, or so I've seen over the last few months. But it requires attention. And it definitely -- posi-lutely-abso-tively -- needs a complete, reliable, updateable, and incremental backup solution.

So far, I think Macrium actually does that -- within a single OS session. I can create an image of the drive with all the OS partitions from within a chosen OS session. If I restore it -- using a Macrium disc made within the chosen OS -- it will restore the incrementally-updated partitions/volumes of both OSes so either is then again bootable from the multi-boot menu. In fact, I think I used a rescue disc created in Win 7 to restore an image-set created under Win 10, with the restore operation initiated in Win 10. EDIT: NO, that's not true. I installed Macrium in Win 10 only. And if that all works properly, I'm not going on any explorations to see whether I can do it either way with the same image. No sir.

Also, with dual-boot, I thought I discovered a problem managing Afterburner OC settings for the graphics card. And so far, the solution to that involves unchecking the item for "apply at startup" so for either OS it remains in its default setting. Then you can apply a saved profile in either OS session to clock up the graphics. That also has been working very well without a problem.

Finally, it is also imperative to configure the VSS service and "system protection" checkpoints so that only those volumes used by the active OS are turned "on." Any discrepancies will generate the same sorts of Event ID 8193 problems that Mainstreamers seem to experience with single-OS systems. And sometimes, you don't know how these inconsistencies occurred, but it requires a little attention, as do the Event Logs that display the symptoms. Now that I think of it, that's another possible source of problems if not managed properly.

So there's an accumulation of little potential risks complicated by dual-boot. Some people prefer separating the OSes between physical devices, but I'm not so sure if that resolves any of it.

I'm leaning toward an outright purchase of Macrium Reflect Workstation. It costs about $6 more than the "Home" version, and supports dynamic volumes. I have no need for dynamic volumes now, but for $6, I can entertain any possibilities or options.

With Macrium, I'm now confident that I can back up locally, to a network folder, differentially and incrementally --- across physical devices and with multiple volumes (such as the dual-OS disk). I haven't been able to assure myself that Windows native backup in either OS will do that.

Whether or not MS advises dual-boot on a single physical disk, they don't advise installing "Program Files" to different volumes or devices, but someone wrote a long dissertation about it at either TechNet or MSDN. You can actually manage moving those folders to another volume and drive, but without a utility, you wind up doing a comprehensive Find and Replace in the registry to change "C:\Program Files\. . . ." to "E:\Program files\ . . . . " I'd rather either get it right the first time, or find another utility with the reliability I see in Macrium for what I've found it to do.

This also means, if you begin installing software to other than the OS-boot disk, you definitely cannot use Windows native backup and expect to restore the OS disk. You have to use something like Macrium.

Ever have any experience with another software utility called "Mini Tool?"