tyoung5ND

I could not think of a reason why my MB didn't recognize the one drive. I decided to just re-install my Dell controller card and drive bays. After re-installing everything, unRAID is working fine. Running a parity check right now to confirm.

Thanks, I just checked my BIOS and it does look like it is missing. The drive must be OK since my Windows machine was able to recognize it, so I'll investigate why my unraid box can't recognize it.

My array was previously using a Dell H310 controller card with drive bays. I decided to reduce the size of my array and get rid of the controller card and drive bays. I removed the hardware and now have all the drives plugged in directly to my motherboard. After booting my array up, it says that one of my drives is missing. I tried swapping SATA cables from another drive, but the same drive is missing. I plugged the drive into my Windows machine, and the drive was successfully recognized. How do I begin troubleshooting this missing drive?

After being down for a few months, I finally got my array back up and running. However, I noticed that one of my 8 drives was reporting a failing attribute (End-to-End_Error is FAILING_NOW). I have a couple other spare drives, so I swapped the failing drive out with the spare. The funny thing is, my spare drive also began reporting the same failing attribute (End-to-End_Error is FAILING_NOW). I then moved the 2nd failing drive to a new bay and unRAID seemed to be fine with it then. It allowed me to do a data rebuild on the spare. I've run 2 parity checks since then and have found 0 errors. However, both drives have the End-to-End_Error attribute as FAILING_NOW in their SMART reports. I've done some reading it sounds like this attribute has to do with the HDD's cache becoming corrupted. It sounds like I should get these drives replaced, but I just want to make sure that this failing attribute couldn't be caused by some other component (SATA cable, motherboard, etc). From the attribute description, it sounds self-contained to the HDD itself, but I'm not very familiar with how SMART is implemented. I would surely rather replace a $5 cable than a $160 drive.

FWIW - I have also mad many issues with the SUPERMICRO AOC-SAS2LP-MV8 card. See my post here: https://lime-technology.com/forum/index.php?topic=44248.0

Sorry to stir up an old thread. Just wanted to give an update. This weekend I upgraded my unRAID server from 6.1.6 to 6.1.9. I also flashed my AOC-SAS2LP-MV8 to 4.0.0.1812. I was hoping that one or both of these changes would resolve my parity check issues. Unfortunately, I am still seeing parity check errors when using the SAS2LP card. I believe I am going to give up on the SAS2LP card and try buying another card.

Thanks garycase. I am running an AMD board, so I don't think it supports vt-d. I believe AMD has their own version though, so maybe I should try disabling that. I can spend some time to see if changing the spin-down setting is a valid workaround for my situation or not. You're right though, I wouldn't feel confident leaving it this way for an extended period of time. Knowing that if my array ever had to be shutdown I would lose confidence in my parity would make me uncomfortable. What do you think the long-term solution is here? Does it seem likely that unRAID could resolve this issue with a future update? Or should I start looking around for a replacement for the SAS2LP?

Here is my latest status. I unplugged all HDs from the SAS2LP and back into the motherboard. I ran 3 parity-checks with this configuration. Here are the results: 2015_12_10 Results from running a CORRECT Parity-Check Dec 10 11:30:25 unRAID kernel: md: correcting parity, sector=3519069768 Dec 10 11:30:25 unRAID kernel: md: correcting parity, sector=3519069800 2015_12_11 Results from running a CORRECT Parity-Check - 0 errors Allowed HDs to spin down and then started another parity-check Results from running a CORRECT Parity-Check - 0 errors The only two hardware pieces that are different with my parity-check error setup is the SAS2LP and breakout cables. I doubt the cables are the issue since I've seen consistent sectors fail the parity-check. So my best guess right now is that there is some bug with the SAS2LP. I would like to get the SAS2LP working if possible. Has anyone been using this card successfully without error? Maybe there is some settings I can play with?

Well, I started another parity-check last night. This was a NO-CORRECT check: Dec 10 01:34:01 unRAID kernel: md: parity incorrect, sector=3519069768 Dec 10 01:34:01 unRAID kernel: md: parity incorrect, sector=3519069800 I've decided that I want to rule out my HDs, memory, and other hardware. So I unplugged my HDs from the SAS2LP and back into the motherboard. I'm going to run a CORRECT parity-check and then maybe a few more checks just to make sure everything is good. If no errors, then we can safely assume something is wrong with either the SAS2LP or the breakout cables.

So I ran the CORRECT parity-check on 12/8 and the results: Dec 8 15:30:11 unRAID kernel: md: correcting parity, sector=3519069768 Dec 8 15:30:11 unRAID kernel: md: correcting parity, sector=3519069800 After that I started another NO-CORRECT check and it found 0 errors. It also found 0 errors last time I ran a check after the correcting parity check. I'm thinking I might shut down the server for 1 day and then run a couple more parity-checks to make sure everything is OK.

Alright, I upgraded to 6.1.6 last night and ran another NO-CORRECT Parity-Check. It found the same two errors as last time: Dec 8 01:56:27 unRAID kernel: md: parity incorrect, sector=3519069768 Dec 8 01:56:27 unRAID kernel: md: parity incorrect, sector=3519069800 I did originally run a CORRECT Parity-Check after I installed the SAS2LP, so maybe I need to correct them again to get them back to what they should be?

Cool, I won't worry about the read counts. It seems very odd to me that the SAS2LP would have errors with the same sectors. Now granted my hardware knowledge isn't that great to really explain this. It just seems that if the controller was having errors, then it would be random rather than consistent sectors. Unfortunately, I do not have ECC memory (the processor/socket I went with doesn't support it - mea culpa). I did retire my single RAM stick a couple weeks back though and replaced it with a brand new one. I ran MemTest for ~36 hours without any errors. I am currently running unRAID Server Pro Version: 5.0.6 I was hoping to get a "stable" build before I upgraded to 6. Are there known issues in 5 that were resolved in 6? Thanks!

Only at 55%, but I just noticed something interesting: Device Identification Temp. Size Free Reads Writes Errors parity ST4000VN000-1H4168_Z300MCV2 (sdg) 3907018532 36°C 4 TB - 12206615 42 0 disk1 Browse /mnt/disk1 (sdf) 3907018532 40°C 4 TB 45.95 GB 12216606 10 0 disk2 Browse /mnt/disk2 (sde) 3907018532 39°C 4 TB 1.23 GB 12220766 10 0 disk3 Browse /mnt/disk3 (sdd) 3907018532 34°C 4 TB 5.37 GB 7062978 10 0 disk4 Browse /mnt/disk4 (sdk) 3907018532 37°C 4 TB 1.6 GB 12202240 10 0 disk5 Browse /mnt/disk5 (sdj) 3907018532 42°C 4 TB 4.05 GB 12207924 10 0 disk6 Browse /mnt/disk6 (sdi) 3907018532 39°C 4 TB 10.77 GB 12197476 10 0 flash Browse /boot (flash device) DT_100_G2 - 8.01 GB 7.91 GB 444 15 Sorry if this is hard to parse... But disk3 (sdd) has only 70XXXXX reads vs the other disks that have 122XXXXX reads. Considering that all my disks are the same capacity and all have a small amount of free capacity, why would one disk have a smaller read amount than the others?

Yesterday I finished running a long pre-clear routine on my new 6TB hard drives. Everything was OK with them, so I decided to run another NON-CORRECT parity check on my setup without the new drives added. I'm only 50% through the parity check, but I've unfortunately found 2 errors: Dec 6 23:39:53 unRAID kernel: md: parity incorrect, sector=3519069768 Dec 6 23:39:53 unRAID kernel: md: parity incorrect, sector=3519069800 These 2 sectors are errors that were found before. Does the community have any advice for trying to troubleshoot what is wrong with my build? I'm worried that the SUPERMICRO AOC-SAS2LP-MV8 or new breakout cables might be causing these errors, but isn't that unlikely since the same sectors are affected?

Update - NON-CORRECT parity-check completed with 0 errors. I'm hoping this means everything is fully functional.