support wrote:Thank you for informing us about the possible issue. We'll check this scenario.
One of the FancyCache's core components is a storage class filter driver which resides in the storage stack, intercepting I/O requests for data on volume/disk.
A HW-Raid like his LSI-storage-controller-card reports to the BIOS as a disk, not a raid, this is why intheory the HW-raid ha sthe highest chance to work compared to FW-Raid and software-raid, that assume highly impossible.
Any I/O-request to the disk (raid) is intercepted, and therefore any defered-write write doesnt reach the raid before timeout-duration (or full-cache-situation)... so nothing there the raid would like to defer to the disks before, except there is some process running that tries to gather health/status/warnings/error-messages or a expects an "alive-signal" within a decent time or sends internal-commands... all that would intercepted by primocache, running into unexpected problems of all kind.
Theres no way his HW-raid controller is causing this by trying to defer "regular"-dats-r/w internally what had not even passed on to the "disk" by fancycache.
The problem is not fancycache/primocache, thats for sure. Technically it should work... but Im sure it is unable for romex to find the root of this error.
When you use a third party application that helps you to maintain/configurating your true HW-raid through the OS on runtime, than you have to disable primocahce/fancycache for that time you need to configure the HW-raid-controller before. Only standard drive commands would work. Sending any interal maintaining command from a "tool" would high likely run into BSOD.
These maintaining tools request health status of the disks by the controller or report controller warnings to your desktop... what-so-ever. This would not work properly with fc/pc. These tool might think the controller died or a drive died and send a shut-down command for safety
I dont even see what he means with setting the defer write lower than in primocache. You cannot set the defer write lower or higher, except you mean 0 for disabled and 1 for enabled. Only thing beeing left would be "timeout-duration" of defer-write... guess he means that, just was to unspecific, what he exactly means.
I think his note is simply misleading from the real causing problems of such controllers in combination with fc/pc.
Anyhow when the raid-disks expect regular write out of nothing or for no reason to run into BSOD, that would be quite curious and a problem of the internal FW of the HW-controller. Hope i could help on the topic.
I guess a legit solution could be: uninstall all software that came with the LSI, reboot, then try to set higher defer-timeout-duration in primocache.