Running Unraid 5.0.5

 

I had disk #6 go bad on me. (1.5tb seagate).  Parity kicked in and everything was fine but unprotected.  I brought the system down and replaced the drive with a larger 4tb WD Red disk, assigned the drive to the #6 slot and started the array.  The web interface was taking a long time to return so I checked the log and it was spewing error messages all over the place (a sample is attached).  I decided this was probably extremely bad and killed the power because stopping the array was not possible.  I removed the old drive and brought the system back up.  Before starting the array the status was basically "a disk is missing, the data will be available and the array will be unprotected".  I started the array and the SMB export for disk 6 is missing and the system log reports that md6 cannot be mounted (errors below).  I can't tell if the data from the disk is visible in the array since I don't know specifically what was on it, but since the SMB export of disk6 dis missing and I got the md6 mount error, I assume it isn't there.  Any advice would be appreciated.

 

 

Jul 26 21:37:53 Tower kernel: EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: discard
Jul 26 21:38:29 Tower emhttp: shcmd (156): set -o pipefail ; mount -t reiserfs -o user_xattr,acl,noatime,nodiratime /dev/md1 /mnt/disk1 |& logger
Jul 26 21:38:29 Tower emhttp: shcmd (158): set -o pipefail ; mount -t reiserfs -o user_xattr,acl,noatime,nodiratime /dev/md2 /mnt/disk2 |& logger
Jul 26 21:38:29 Tower emhttp: shcmd (160): set -o pipefail ; mount -t reiserfs -o user_xattr,acl,noatime,nodiratime /dev/md3 /mnt/disk3 |& logger
Jul 26 21:38:30 Tower emhttp: shcmd (162): set -o pipefail ; mount -t reiserfs -o user_xattr,acl,noatime,nodiratime /dev/md4 /mnt/disk4 |& logger
Jul 26 21:38:30 Tower emhttp: shcmd (164): set -o pipefail ; mount -t reiserfs -o user_xattr,acl,noatime,nodiratime /dev/md5 /mnt/disk5 |& logger
Jul 26 21:38:30 Tower emhttp: shcmd (166): set -o pipefail ; mount -t reiserfs -o user_xattr,acl,noatime,nodiratime /dev/md6 /mnt/disk6 |& logger
Jul 26 21:38:30 Tower logger: mount: wrong fs type, bad option, bad superblock on /dev/md6,
Jul 26 21:38:30 Tower emhttp: disk6 mount error: 32
Jul 26 21:38:30 Tower emhttp: shcmd (169): set -o pipefail ; mount -t reiserfs -o user_xattr,acl,noatime,nodiratime /dev/md7 /mnt/disk7 |& logger
Jul 26 21:38:30 Tower emhttp: shcmd (171): set -o pipefail ; mount -t reiserfs -o user_xattr,acl,noatime,nodiratime /dev/md8 /mnt/disk8 |& logger
Jul 26 21:38:31 Tower emhttp: shcmd (173): set -o pipefail ; mount -t reiserfs -o user_xattr,acl,noatime,nodiratime /dev/md9 /mnt/disk9 |& logger
Jul 26 21:38:31 Tower emhttp: shcmd (175): set -o pipefail ; mount -t reiserfs -o user_xattr,acl,noatime,nodiratime /dev/md10 /mnt/disk10 |& logger
Jul 26 21:38:31 Tower emhttp: shcmd (177): set -o pipefail ; mount -t reiserfs -o user_xattr,acl,noatime,nodiratime /dev/md11 /mnt/disk11 |& logger
Jul 26 21:38:31 Tower emhttp: shcmd (179): set -o pipefail ; mount -t reiserfs -o user_xattr,acl,noatime,nodiratime /dev/md12 /mnt/disk12 |& logger
Jul 26 21:38:32 Tower emhttp: shcmd (181): set -o pipefail ; mount -t reiserfs -o user_xattr,acl,noatime,nodiratime /dev/md13 /mnt/disk13 |& logger
Jul 26 21:38:32 Tower emhttp: shcmd (183): set -o pipefail ; mount -t reiserfs -o user_xattr,acl,noatime,nodiratime /dev/md14 /mnt/disk14 |& logger
Jul 26 21:38:32 Tower emhttp: shcmd (185): set -o pipefail ; mount -t reiserfs -o user_xattr,acl,noatime,nodiratime /dev/md15 /mnt/disk15 |& logger

log.txt

Update:

 

On the suspicion that maybe the port the drive was in went bad, I connected the drive (outside the array) and was able to mount it (running reiserfsck now to verify).

 

I have more than enough space on the array to copy the contents of the "salvaged" disk to it so I'm considering killing the array config and setting the array back up minus 1 drive, copying the data from the "salvaged" drive back to the array and then expanding the array with the replacement WD Red disk (and either tossing the 1.5 on "suspicion" or re-purposing it).

As long as you are sure you did not loose data I would say go for it. I probably not reuse the drive in the array though. Carefull don't chose the wrong drive as parity. Then you will loose data.

That drive that failed (more accurately dropped from the array) turned out to be fine.  In fact the root of the problem seems to have been a failing power supply (I wish they would just power off entirely when they begin to get flaky; maybe PSUs should have their own version of SMART).  I've temporarily replaced the PSU with a standby unit I keep around and have a new beefier one of the way.  My controllers consist of 3 Supermicro AOC-SASLP-MV8 cards and up until that drive failed I hadn't used any of the ports on the 3rd card and I think that card may have gone bad (or been bad all along) so it's being replaced as well (luckily they're not very expensive and still available).