Just performing a community service here. For a long time, ever since the X58 platform, I have used Intel's RAID controller to configure my SSD's for RAID-0 and for the most part and most of the time, this worked flawlessly (from 2009 - 2017). I started with 4x X25-M 80GB G1's in 2009. I eventually migrated those same drives over to the P67 platform and at then swapped out the drives for Samsung 840 Evos (3x250GB) in 2013. Then brought those over to the Z87 platform. At some point, starting near the end of 2016 or early 2017, I noticed that the RAID-0 controller would lock-up when doing large file copies to it. This never happened before. I didn't think much of it, I almost thought it was the issue with the Samsung 840 Evo debacle. You know, the firmware issue that saw performance degrade after 30 days of stale data. So, I did what a lot of people do, I broke the array (after backing it up, of course), ran the firmware update, secured erased the drives and rebuilt the RAID array. Problem appeared to be be resolved.
However, a few months later I noticed that "Write-Back Caching" was disabled. This was sometime in 2017. So I did what most people do, I turned it back on. Otherwise, without this turned on, write performance suffers. Without write-back caching enabled, even an SSD is painfully slow to write too in a RAID array. So, most people turn it on, of course, bypassing the dire warning of "Warning! You might lose data in the buffer if under a power outage, blah, blah, blah". For a home user that has non-important data, this is irrelevant. Obviously in the enterprise world, this would be a no-no, but for that matter, so would using Intel's RAID controller...
Anyhow, once Write-Back Caching was enabled, my system's I/O would lock up after doing a large file copy. So, for example, I would try and write 400GB (multiple files/folders) to it, and it would copy about 50GB, then slow down to 0MB/Sec (literally, zero). I couldn't even reboot windows. I didn't lose control of the system, however, only things that required that drive. So any application that was on the Array wouldn't respond, but anything on my OS drive would still work correctly. Still, Windows wouldn't reboot or shutdown with the array being locked up, so this required forced shutdown. Often times the RAID Volume would have errors on it (Note: not the array itself, the logical volume from windows disk check. Intel RST said the array's integrity was fine when checked, despite windows saying the volume was corrupt)
At this point, I still didn't figure out what was the problem. I blamed it on my 840 Evo's or motherboard. Wasn't sure, and didn't want to spend all my life trying to figure out the problem. I mostly do READS from the array, so it didn't really bother me. Just an annoyance. That said, I decided to upgrade to Samsung 860 Evos 3x1TB. After setting those up, guess what? Same problem. Ok, crap, so now I am pissed. It wasn't my SSDs and I probably didn't need to buy those 1TB drives. Still, I needed the space, so I wasn't THAT upset. This finally proved to me that my Samsung 840 Evos were not to blame, so I suspected it was the Intel Raid controller.
So I did some google searching, and found some information scattered around by users who seemed to have a partial solution or workaround, but was rather incomplete. Well, long story short, Intel released a bad string of drivers (though I can't find this publicity mentioned in the notes) for Intel RST that would only manifest itself on RAID volumes that had Write-Back Caching enabled. Again, Intel Raid without write-back caching is just all around crappy and you'd be better off just using single drives and spanning them via windows disk management if you want to pair 3 drives together for a single volume. But that is only if you can't enable Write-Back Caching. Anyway... Problem was resolved by updating to the latest Intel RST driver. I can confirm that the latest Intel RST driver on their website (Version: 15.9.0.1015) resolved my issue and that Intel RST driver (Version:15.8.1.1007) was problematic for me and many others.
TLDR
If you are using Intel RST drives with RAID-0 and are experiencing issues with large data being written to the volume and eventually having the volume no longer respond, you can either 1) Update to the latest RST Driver (Version: 15.9.0.1015) found on Intel's site or 2) Disable Write-Back caching. You could try "Write-Through", instead, but I am not sure if that is problematic, I never tried it. From what I understand, there were multiple releases that had this problem and it appears to have appeared sometime in 2016/2017 with the release of their first 15.X.X.X driver. Their latest driver (or rather, the one they have as their default download) works just fine and the problem is now fully resolved. I can write plenty of data to the volume with no lock-ups while having write-back cache enabled.
I wanted to write this up, because I had to piece this information among several posts on the internet to deduce what the main issue is and how to correct it. Upon my search I came across at least 10+ people reporting this issue and the answers were incomplete and scattered with some nuggets of good information. Ultimately, I felt that many people's solution went unresolved. So I am hopeful that this will help someone from pulling out their hair and spending a great deal of time trying to figure out what this issue is.
The problematic driver was: Intel RST version 15.8.1.1007, though many other drivers in the that series (seems to be relegated to several 15.X releases) had the same problem. Again, hope this helps someone.
However, a few months later I noticed that "Write-Back Caching" was disabled. This was sometime in 2017. So I did what most people do, I turned it back on. Otherwise, without this turned on, write performance suffers. Without write-back caching enabled, even an SSD is painfully slow to write too in a RAID array. So, most people turn it on, of course, bypassing the dire warning of "Warning! You might lose data in the buffer if under a power outage, blah, blah, blah". For a home user that has non-important data, this is irrelevant. Obviously in the enterprise world, this would be a no-no, but for that matter, so would using Intel's RAID controller...
Anyhow, once Write-Back Caching was enabled, my system's I/O would lock up after doing a large file copy. So, for example, I would try and write 400GB (multiple files/folders) to it, and it would copy about 50GB, then slow down to 0MB/Sec (literally, zero). I couldn't even reboot windows. I didn't lose control of the system, however, only things that required that drive. So any application that was on the Array wouldn't respond, but anything on my OS drive would still work correctly. Still, Windows wouldn't reboot or shutdown with the array being locked up, so this required forced shutdown. Often times the RAID Volume would have errors on it (Note: not the array itself, the logical volume from windows disk check. Intel RST said the array's integrity was fine when checked, despite windows saying the volume was corrupt)
At this point, I still didn't figure out what was the problem. I blamed it on my 840 Evo's or motherboard. Wasn't sure, and didn't want to spend all my life trying to figure out the problem. I mostly do READS from the array, so it didn't really bother me. Just an annoyance. That said, I decided to upgrade to Samsung 860 Evos 3x1TB. After setting those up, guess what? Same problem. Ok, crap, so now I am pissed. It wasn't my SSDs and I probably didn't need to buy those 1TB drives. Still, I needed the space, so I wasn't THAT upset. This finally proved to me that my Samsung 840 Evos were not to blame, so I suspected it was the Intel Raid controller.
So I did some google searching, and found some information scattered around by users who seemed to have a partial solution or workaround, but was rather incomplete. Well, long story short, Intel released a bad string of drivers (though I can't find this publicity mentioned in the notes) for Intel RST that would only manifest itself on RAID volumes that had Write-Back Caching enabled. Again, Intel Raid without write-back caching is just all around crappy and you'd be better off just using single drives and spanning them via windows disk management if you want to pair 3 drives together for a single volume. But that is only if you can't enable Write-Back Caching. Anyway... Problem was resolved by updating to the latest Intel RST driver. I can confirm that the latest Intel RST driver on their website (Version: 15.9.0.1015) resolved my issue and that Intel RST driver (Version:15.8.1.1007) was problematic for me and many others.
TLDR
If you are using Intel RST drives with RAID-0 and are experiencing issues with large data being written to the volume and eventually having the volume no longer respond, you can either 1) Update to the latest RST Driver (Version: 15.9.0.1015) found on Intel's site or 2) Disable Write-Back caching. You could try "Write-Through", instead, but I am not sure if that is problematic, I never tried it. From what I understand, there were multiple releases that had this problem and it appears to have appeared sometime in 2016/2017 with the release of their first 15.X.X.X driver. Their latest driver (or rather, the one they have as their default download) works just fine and the problem is now fully resolved. I can write plenty of data to the volume with no lock-ups while having write-back cache enabled.
I wanted to write this up, because I had to piece this information among several posts on the internet to deduce what the main issue is and how to correct it. Upon my search I came across at least 10+ people reporting this issue and the answers were incomplete and scattered with some nuggets of good information. Ultimately, I felt that many people's solution went unresolved. So I am hopeful that this will help someone from pulling out their hair and spending a great deal of time trying to figure out what this issue is.
The problematic driver was: Intel RST version 15.8.1.1007, though many other drivers in the that series (seems to be relegated to several 15.X releases) had the same problem. Again, hope this helps someone.
Last edited:
Facebook
Twitter