Steve,
I just finished my stress tests with 'fsutil behavior set DisableDeleteNotify 1' but the result is the same (verification faults).
Can anyone confirm, that disabling TRIM on this way cured the problem when using SSDs?
Best regards

Hi Bibo,

I think BillyDV did this test...

Zitat

---

I have finally tested with a driver that works with raid 1 ssd volume and does not fall apart. I used the same stress test that messed up every other raid 1 mirror. As I see it the problem lies in the enabling of trim on Windows 7/Server 2008r2 based systems. The 3.6 driver available from the intel website is the only driver that will not destroy the raid 1 mirror upon being stressed. I will rerun the test later this week but I am quite confident that the issue is the enabling of trim for raid 1. I have countless machines setup running win 8.1 with 2 ssd raid 1 volumes (or 4 ssd raid 10 volumes), I have never seen a single parity error on any of them even when power is suddenly shut off.
I will report back after rerunning this test.

---

Have a look at page 4/5 of posts.
Perhaps confirm with BillyDV.

Cheers
Steve

EDIT by Fernando: Removed some blank lines (to save space)

I have rebuilt my RAID1 array on Windows Server 2012 R2 from SSDs to HDDs and:

1) The data on the SSDs are okay, despite reporting 65535+ verification errors (I haven't stress tested the array as Stephen and billydv did, so it didn't get corrupted yet)
2) There are no verification errors (for the same data) on the HDDs

I'm using the 4.1 OROM, drivers and RSTe console. So my conclusion is that SSDs (presumably TRIM) is what is causing the problems.

Thanks Steve,
I read this post but I am not sure if BillyDV really tested and therefor proofed it.
@billydv: Did you test this case (RAID1 SSD + TRIM switched off using Server 2008R2 and no further data corruption) or was it (just) an assumption?
Best regards
Juergen

Hi Bibo,
Here are the tests I have run. Stress tests are done with Passmark Burn In software for approximately 4 days per test result. Cpu, Memory is set to about 50% duty, disks are set to 50-60% duty. Server is running 2008r2, os on a 2 drive raid 1 volume, sas chipset has a 4 volume raid 10 made up of hdds. Sata orom on X9DAi is 3.8

1- IRSTe 3.8, 3.9, 4.1, 4.2 with raid 1 ssds fails

2- IRSTe 3.8, 3.9, 4.1 with raid 1 hdds succeeds

3- IRSTe 4.2 with raid 1 hdds fails

4- IRSTe 3.6 with raid 1 ssds succeeds (I ran this twice to confirm my results, each time resulted in no parity errors. A 3rd test was to push the reset button on the server while it was running, Server restarted normal and parity verification reported no errors)

5- IRSTe 3.6 with raid 1 hdds currently testing, should have results on friday.

The difference between the 3.6 drivers and all the rest is that raid 1 has no trim enabled. I have not tried the other drivers with trim disabled, none of my tests have been done with any changes to fsutil behavior.

I have been told that the 3.6 drivers are not at all compatible with server 2012r2. I will soon be testing the 3.8 series drivers with trim disabled in the os by running this command "fsutil behavior set disabledeletenotify 1". I will report back.

During my test parity errors come out with driver 3.6.0.1086 also (probably due to RAID ROM 4.1.0.1026).

That's why I was sure to mention that I have Sata Orom 3.8. BTW Supermicro offered to give me a bios that would upgrade my Sata Orom to 4.1, I chose not to install it since I was getting the impression that the best way to go here was the 3.8 Orom and th 3.6 drivers as per Stephen Done's initial report.

Okay, I cut the 3.6 hdds stress test a bit short, 3 1/2 days, parity verification shows no errors. I wanted to move along to testing the 3.8 drivers with ssds and trim disabled- test is now running, set it for 7 days
here are the exact details:
Sata Orom 3.8, IRSTe 3.8.0.1111 drivers and gui, two intel ssd 530gb in raid 1 volume for the OS (server 2008r2), Trim disabled via "fsutil behavior set disabledeletenotify 1" in command prompt (reboot of machine followed), Passmark BurnIn test running at 60% load on disks.

I will report back but my gut instinct tells me that it will be okay, I am really believing that the trouble with all of this is Trim with raid 1.

I am actually repeating my tests with 'fsutil behavior set disabledeletenotify 1' having rebooted the Server under test after comitting this command (previously I did not reboot, because some MS doc stated that this is not necessary - but under this conditions my test failed, as mentioned above).
I hope, that this will help, because if not, I really do not know how what to do as next step...

Just wanted to add this. I found this document from Intel
http://www.intel.com/content/dam/www/pub...tions-paper.pdf
It has some interesting info, especially for you Stephen, regarding trim on the s3500 and s3700 series ssds. Apparently trim is not so beneficial with these units. Also some interesting points about checking alignment.

to the RealBibo
Is it my understanding that you have ssds in raid 1 running with trim disabled and 3.8 series drivers? How are you stress testing? Did your previous test fail?

@billydv
No, as Steve complained, I am not using the enterprise Versions - just because my server (board: supermicro x9scm-f) was not delivered with them.
Instead I am using:
Intel® Rapid Storage-Technologie für Unternehmen Information
Installiertes Kit: 13.6.0.1002
Benutzeroberflächenversion: 13.6.0.1002
Sprache: Deutsch (Deutschland)
Version des RAID-Erweiterungs-ROMs: 11.6.0.1702
Treiberversion: 13.6.0.1002
ISDI-Version: 13.6.0.1002
But in this configuration I ran into comparable, or even the same problem: regular check&verify faults...
I do stress testing using the 'h2testw.exe", which is a very usefull tool to check the consistency of harddisks or eben USB-Sticks.
Yes, my privious test with Setting TRIM to disabled (but not having rebooted after Setting this) failed!

RealBibo,
Your mboard is a socket 1155 and the reccomended irst for your sata chipset is 12 series on the Supermicro website. I have probably 20-25 computers built in just One location which ALL have raid 1 or raid 10 with 13.6 irst and win 8.1. None have ever had a single parity error. We have very different situations, I have had SUPER success with 1155 asus boards running 13.6 drivers. Me and Stephens problems lie with the C602 chipset and the IRSTe drivers.
What I will say is I don't understand why trim would be enabled on your chipset when it is not enabled on any of my asus 1155 boards.
Here is part of the release notes for the 11 series IRST

1. The Intel® Rapid Storage Technology driver and user interface version of this release is 11.7.0.1013 and the RST OROM/UEFI version hasn’t changed from the previous maintenance release which is 11.6.0.1702.


You may want to try that driver which is available here https://downloadcenter.intel.com/downloa...RST-RAID-Driver

Finally,
The results are in--- 3.8 series drivers with ssds in raid 1, trim disabled in OS, raid volume does not fall apart