Hi, I am building a new computer and I am getting two 960 evo ssd's for the setup. The plan was to set one drive as system/boot drive and use the other for programs and games and such.. and in addition I am also going to have one or two larger hdd's (from my old computer) and I was thinking about using ssd caching for those...
1. Is it possible to create ssd cache for hdd if the hdd isn't empty or does it need to be formatted first.. ?
2. I read somewhere that the ssd used caching the hdd can't be bigger than 60 or 64gb or something like that... but the ssd I was thinking of using as cache is the old vertex 3 240gb boot drive from my old computer.. is it useable ??
3. Alternatively I though about using a partition from the new 960 evo drives for the cache.. but can partition be used as cache like that, or do I need to commit a whole drive for it ??
4. If I setup the ssd cache, will the data on the hdd become dependent on it somehow ? (ie. what happens if I setup the cache and then shutdown the computer and remove the ssd and then restart my computer.. will the hdd and showup ? will the data be there and useable as normal.. or will the setup become corrupted in the absence of the ssd ??)
I should be able to answer most of these questions, although likely there will be nods and smiles from our colleagues, since I became a "caching hot-dawg."
The source-disk -- the accelerated or "cached" disk -- shouldn't need any special preparation, and can already hold data. This would be true for either ISRT through the Intel controller, or other proprietary possibilities, such as Marvell's. So that would answer #1.
For earlier chipsets of which I have firsthand knowledge, the limit for the caching SSD in terms of maximum cache size was 64GB for ISRT.
ISRT, like Samsung's "RAPID" for RAM-caching their SSD products, is faux-proprietary. It's proprietary because that's the way Intel and Samsung want it. No less would that be the case for
Marvell's Hyper-Duo. I have had the opportunity to try Hyper-Duo for several years, but haven't, so have no "firsthand" experience.
That leaves us with a limited choice of software utilities which do the same thing(s) as the others. When I first started looking for such software, there were about four or five possible options, but one of them didn't work properly with OSes later than Win 7, and there were other drawbacks with a second one. This narrowed the choice down to:
Superspeed's SuperCache, and
Romex's Primo-Cache. It also became slowly apparent that hardware companies were buying the rights to some of these software products as soon, but these two are independent. Superspeed's headquarters are in in Massachusetts; Romex in Shanghai. For features and versatility, Romex Primo-Cache wins hands down.
Primo is a swiss-army knife of caching features. It will cache either SSD or HDD to RAM; it will cache SATA SSD to NVME SSD or SATA HDD to SSD of either SATA or NVME flavors. It will cache disks across different proprietary controller hardware. It will cache either AHCI or RAID, and it will cache BOTH AHCI and RAID in the same system. You could cache several SSDs and HDDs under one caching task and cache device, or create more than one caching task using different cache options. So I can cache my NVME to RAM, and a 5,400 Seagate Barracuda spinner to NVME or SATA SSD.
The larger the SSD cache size, the greater the overhead requirements in RAM. So having a 16GB RAM-kit, you might find that 80GB to 150GB is a comfortable limit for SSD-caching.
The license is lifetime, and probably costs about $30 with a generous trial-period under full-functionality. You could-- of course -- be reticent over speculations that the Chinese PLA hacker-battalion has a "hook" in your computer, but that's no different than current anxieties for Kaspersky users since it's a Russian company. After hearing the CEO of Kaspersky explain the impossibility for such things, and after having worked with Primo for some three years now on some three desktops and one laptop, I have no such worries.
To answer #3, I'll describe my current Skylake-system status-quo. It is dual-boot Win7/10, and both boot-system partitions are on a 1TB 960 Pro NVMe. I left about 150GB of unallocated space on the 960 Pro for a caching volume. They all co-exist. However, there was one problem or difficulty with defining separate cache volumes for each different OS, so the Win 7 installation is only cached to RAM. Win 10 has a RAM cache for the NVMe (not including the caching volume), and the NVMe volume caches either a spinner or an SATA SSD. It is used for the latter now, because I replaced the Barracuda with a Crucial MX300.
For #4, dependency only works in one direction. As the Primo "manual" explains, you must avoid situations with "off-line writes" to the source drive -- the one that is being cached. This will lead to automatic CHKDSK repairs of the source disk -- not a bad thing, but a time-waster and annoyance. So you define your caching strategy (especially for dual-boot situations) to avoid writing to an SSD-cached disk under one OS if the cache is defined on the other OS. You don't need to cache things like "media" drives.
If you have more RAM, and it is FLAWLESS and flawlessly configured RAM, it can be a better choice and you could conceivably avoid using an SSD-cache altogether. But you could easily use both, and I would personally recommend isolating the configurations. I had some troubles when I was caching an SSD volume to RAM while simultaneously caching an HDD to BOTH SSD and RAM. The difficulties don't cause data-loss, but they will cause on-the-fly drive repair episodes as I mentioned.
I guess this is the latest version of my prolix dissertation on the subject. Hope it serves you well. Currently, I'm planning a RAM upgrade to a 16GB 2x8 kit to a 4x8=32GB. It would've been easier and more likely successful to replace the 2x8 with a 2x16. But I've already cut the RMA ticket for the second 2x8 kit so that it will be a "replacement" RMA for a 2x16. If I don't like the outcome after testing during a 14-day period, I can execute the RMA. And if I don't -- I won't. Frankly, I'll be happier than a pig in s*** if I can make the 4x8 run at 3000 instead of 3200, as G.SKILL has pronounced their own best guess about two identical but unmatched kits.
PS I had previously left a smidgeon of unallocated space on my 960 Pro after defining the caching volume, thinking that I needed to "over-provision." This may not be at all necessary for the Pro drive, but I would advise over-provisioning an EVO, given the hardware features of the two models.
Post-PS -- The risk to data emerges when you choose the "maximum performance" option of deferred writes. This can be turned on and off within the same computer session to minimize risk. The risk arises with any possibility of BSOD or unstable behavior on your system. ISRT (for SSD-caching) has the same deferred write option, and therefore the same risk if you choose to use it.
You should have a regular backup configuration for your system as further insurance, no less nor more than you'd apply with or without any caching. I use Macrium Reflect for my Skylake and Home Server for the other systems using Win 7. Apparently, an active caching arrangement doesn't interfere with daily backups.
Post-PPS -- Pertaining to your question about "removal" of devices. Infer what you wish with this -- my personal experience (and delight when I discovered it). Don't bother "backing up" a caching volume on an SSD with PrimoCache -- only back up the regular Windows partitions including the Win 7 100MB "System Reserved" and/or win 10 500MB recovery stub. If Primo is configured to recognize its own caching volume, and if you remove the caching volume for some reason, you can then boot the system with Primo running and still won't miss a lick. If it doesn't find the caching volume that was previously available, it automatically disables the caching task that uses it until you fix things. I would think this works in the opposite direction: with an active caching volume, you could probably remove the source/accelerated disk and replace it, and Primo would see that it's "not the same disk" and disable the caching task.
Over the three years of usage, I've had all sorts of ideas about how things could get f***ed up by making hardware changes without thinking to disable caching, and I was surprised when things don't go wrong at all.
Facebook
Twitter