I have been upgrading my 1.5TB to 3TB drives. 

The drive upgrade works fine, rebuild completes without error.

I then run a parity check, and for the last 3 drive upgrades, I lose connection to a disk so parity stops, I rebuild the disk, then check parity again.  On that second parity check, a different random drive loses connection so I rebuild again.  The Third parity check then goes through.

 

I thought this was a co-incidence or fluke, but it has now happened 3 times on drive upgrades in the last month.  Each time it loses connection to 2 drives and I have to rebuild them and run parity again.

 

What could be causing this, it is different drives every time, and a combination of SATA connections from motherboard and PCI-e cards, and it has happened across my 2 different power supplies.

 

Syslog attached

 

syslogDec27.txt

Which model PSU?

 

I have an older modular Enermax running the motherboard and 7 drives - can't remember the watts and the model number is not visible anywhere once installed

 

My second PSU is a Corsair CX-430 running 8 drives.  I have had problems with the CX-430 dieing, but nothing intermittent like this.

 

*edit*

 

And to clarify what I mean by losing connection is that unraid red-balls on the drive because it cannot connect to the drive.  I cannot runs SMART reports or anything against the drive, there is no communication to it.

A simple re-boot restores connection to the drive every time without fail.  This is not a loose power or SATA cable.  At first I was re-seating these cables, but a reset restores connection without re-seating.

To eliminate PSU as a potential issue, I am going to pick up a single PSU to replace my 2 PSU.

 

*edit*

 

Any other potential causes for losing connection to a drive mid-parity check?  I just finished a disk re-build, I am going to upgrade the power supply then start another parity check and report back results.  If there is anything I can test in the meantime please let me know.

 

Thank you!

 

I put the Corsair ax750 in place of my two existing PSUs, started the Parity sync, and less than three hours in it failed out a totally different hard drive because it could not connect to it.

 

I have attached my syslog, please help.

 

Very frustrating cycle of restarting the server, rebuilding the drive, and re-running parity sync that fails out a random drive then resstarting the server, rebuilding the drive, and failing out a different drive on party sync.

 

Is there a way to force unraid to trust the array so I don't have to re-build the contents of the drive each time this happens, as it takes 10+ hours each time.

 

There is nothing wrong with these drives, the PSU is brand new, and it cannot be cabling because it fails out different drives each time.

 

What should I do, please help.

 

Should I be upgrading to rc8a, I am currently on rc6. 

syslogDec27_V2.zip

I checked the latest two drives that unraid has lost connectivity to during a parity check, and confirmed that one drive is connected to my motherboard sata, and the other is connected to my Supermicro AOC-SAS2LP-MV8.

 

So this doesn't seem to me like a SATA controller issue.

 

Anything in the syslog point to anything wrong?  Any ideas what to test next?

My disk re-build finished over night, I have started another parity sync, not sure what else to do.

Are the drives connected direct to the controllers or are there any backplanes involved?

Direct, as I don't know what a backplane is.

 

2 drives are connected to a PCIe 1x controller, 7 to my supermicro, and 6 to the motherboard.

 

The disconnecting is happening at both my supermicro and my motherboard SATA drives.  Might have happened earlier to my PCIe controller card but I don't remember which drives it happened to earlier.

With 2 hours left in the parity check, I thought I might finally have a completed parity check so I could start using my server again, then a third different disk in a row just red-balled due to lost connection.

 

Syslog attached, please help I am at my wits end with this.

syslogDec28.zip

After a reboot, I started another rebuild on the newly red-balled disk.

 

 

Logged the issue with Tom, and he was terrific working through the problem with me.

 

After significant testing, eventually identified the problem was the PCI-E slot that my supermicro controller was plugged in to.  Moved the controller to a different PCI-E slot, and parity checks complete now.

 

Currently testing a different supermicro controller in the "bad" pci slot to see if the mobo needs RMA or not, and so far the new supermicro controller works find in that PCI-E slot. 

 

Perhaps my old supermicro wasn't seated properly, or it just didn't like that particular PCI-E slot for whatever reason!

Interesting, looks a lot like the issues I was having. I sent my motherboard back and I am waiting for a replacement to arrive.

I just finished a successful parity sync, the replacement supermicro controller works fine in the PCI-E slot that was causing the other controller trouble.

 

So it appears as though 1 of my supermicro controllers doesn't like the PCI-E that supports a VGA card, but my other supermicro controller works in that PCI-E slot just fine.

 

Very strange, but with no other changes and 4 successfull parity syncs after 10 replications of failed parity syncs seems to prove it true.