I've had an interesting weekend.. not one I want to repeat anytime soon.

 

Long Story short, I had a drive failure which lead me to replace, which I ended up screwing up my disk1 (was able to recover the most important stuff).

 

During my journey, I was able to bring the new replacement disk1 online, parity rebuild and an optimal array.  So on to recovering more data from the failed "Old Drive1".  I added to the unraid box and used SNAP to mount the disk.  I performed an rsync which ended up hitting the failed drives main issue (read errors).  These read errors caused all the drives on the same SAS/SATA breakout cable to go into an offline situation and my new disk1 went into a disabled state..

 

The new disk1 is fine, I've done all the scans and it's good.  I had to reboot to get the disks to show back up, of course disk1 was in the disabled state.  Given that I didn't really care about the data on disk1 at this point, I did the trust my array procedure and brought everything back online fine, parity check, all good. 

 

So, foolishly, I did the rsync again and it did the same darn thing again.  Disk1,disk2,disk3 and the olddisk1 are on the same sas breakout cable on a supermicro SAS/SATA 8port.

 

I've since removed the olddata1 drive and brought everything back online and will attempt further data recovery on a separate box and move the data over from a known good drive.

 

Has anyone seen the behavior?  Very odd that it causes the controller to whack out.

 

Thanks,

Mike

 

I've certainly seen frequent occurrences of the case where a drive acting up can take out the controller (and a reboot is required to recover).  I think in the end I decided it was a badly seated controller card (or a bad SAS cable).

that was my thoughts too, I replaced the SAS breakout cable and reseated and it happened after that.  I've ordered a replacement controller just in case it happens again.

 

 

very odd, but this morning, parity check/correct complete and my array is stable once again... Whew!