Volume caching is great, though targeting caching within volumes would be more valuable.
Given personal knowledge of applications and data that are used most often and have the MOST DESIRED performance improvement, a system administrator or personal user can give specific directory (recursive or not) information to the program. This would provide a much higher level of flexibility and prevent the caching of less valuable data.
I'm really not an expert in this, but as far as I know PrimoCache works on the block level, so it is not aware of the files, directories.
It's not the most convenient solution, but you can create a partition for those important data and mount it in a folder. That's what I did as well.
As PrimoCache system is not able to understand the file system and only blocks. If a feature looks at the files via windows GUI app then created a list of blocks and make sure those blocks are in cache.
Yes, though essentially, with knowledge that the "ramdisk" isn't large enough for all that I want the speed increase for. So , if it (the cache) is smart enough to look ahead and a cache what I want, but limiting the set of possibilities to those that I believe are correct, it's a win.
I'm not sure if we are looking for the same thing. I want to be able to see what program is storing what data in the primo cache. In this way, we can measure the exact benefit for each individual program we have open.
Technically it would be possible to integrate a layer that reads NTFS file table and so PrimoCache could be aware of single files and their individual block-span, thus this probably would be very cpu-intensive task..
One problem is that MS - as far as I know - didn't describe how NTFS works internally but only gives us documentation for the official API, so hooking it indifferently might be a hack that would not be so great!
Another problem is that if you you want these feature to make certain files or folders stored permanently, not just for fun or "show" than the PrimoDriver would need to trick the NTFS filesystem, into handling those "files" from the ram-cache block-device.
Imho all in all to make this work efficently you would make the ram-cache no more block layer but a NTFS-formatted-disk... what follows no sense.. cause it could no more handle general blocks if you misconfigure such semi-filesystem/block-layer-device. Not a goo didea.
By the way if you want applications or specific folders or files accelerated permanently into ram, use primo-ramdisk, and re-link those NTFS-folders to the ram-disk. This is exactly what you seem to want. And If you want to check what files PrimoCache operates you just hove to open the windows ressource-monitor and keep track on the read/write-task of that disk. I dont get the point in showing that in Primo itself, according to the above noted needed effort.
The benefit of primo-cache or primo-ramdisk for certain application is determined by the applications individual demand, the hardware environment and the cache-configuration. Primo-Ram disk is best if your application using specific high amount of storage for high amount of IOps, so it's good for putting your hole Application or Game into a ram-disk. Primo-Cache on the other hand improves overall IOps for the hole drive for read and with defer-write also for write and because it is not slowed down by filesystem-logic, just raw-processing blocks it technically has a higher throughput.
Any term of breaking up withe the block-layer design would ruin the "Cache" benefit..compared to Ram-Disk, which is a suitable solution for "filesystem"-level tasks.
