I wonder if someone can help me since I am new to unraid, and I want a second opinion before I mess something up. I thought it may be easier to read in bullet point form.

 

1) I precleared 2 disks, no errors and ran them without parity for 2 days as put a bunch of stuff on it.

2) I precleared a third disk with no errors and mounted it as parity.

3) I let the parity build run overnight. At around 3am I got about write 500,000 errors that one of the data drives couldn't be written to. About 4 hours later I got an email that the parity check finished.

4) I now see a red X for that drive http://imgur.com/tcD9Xcb.

5) I booted in maintenance mode and ran a parity check. It came back with no errors but the drive with the red x didn't have a temp reading so I think it was spun down and it says it's contents are emulated. I ran short and extended smart of the red X drive with no errors.

6) I unmounted the suspect drive and booted the array. I then stopped it and booted again with the disk reattached.

7) It says that the disk is unmountable and has the orange triangle, but the array is running a parity check and this time I can read the temperature on the suspect disk which tells me that it is spun up, I think. (I'm actually a little confused on whether this parity check is using the questionable disk at all because lower down it is telling me to format it because it is unmountable. Will that go away once the parity rebuilds that drive or do I need to format it?)

 

So what should I do here? I think the error was probably due to a power supply / cabling issue which leads me to trust the drive still. I do have 2 precleared disks so I could theoretically swap one of those in and see if the rebuild happens correctly, but since I don't innately distrust the data on the problem disk I wanted to see if I could give it a shot. Anyway, that's my thought, what do you think the best procedure to do is now?

 

Thanks so much!

 

Post your diagnostics, without them I'm just guessing.

 

Assuming the errors were during the parity sync it should not be considered valid and probably the reason the disk is unmountable.

 

If yes, and assuming disk2 is OK, you should do a new config, reassign the data disks and do a new parity sync.

 

 

Thanks, sorry for not including them the first time!

alaska-diagnostics-20170105-1030.zip

Syslog is after a reboot, so we can't see what happened, but all disks look fine, advice is on the assumption that the errors were during the initial parity sync.

 

Disk2 has 4 CRC errors, not normal for such a new disk, so replace the SATA cable and do a new config and let the parity sync again.

Thanks, so I did a new build, added the 2 data drives without the parity and launched it. The non-problematic drive mounted fine but the other one says 'unmountable'. Is there an additional thing I need to clear or does that really mean that I am out of luck? If out of luck, it was formatted using xfs so is there a good way to salvage what I can? In any case, this has definitely been a good lesson in what not to do, I'm just glad that most of my really important stuff was on the drive that seems to be working.

Run xfs_repair:

 

https://lime-technology.com/wiki/index.php/Check_Disk_Filesystems#Drives_formatted_with_XFS

Ha, that totally worked! Thank you so, so much for your help on this johnnie.black!

 

Just as an added bit of information in case other people run into a similar issue, I logged into my server and tried to run this command

xfs_repair -v /dev/md1

It gave me the following warning:

 

ERROR: The filesystem has valuable metadata changes in a log which needs to

be replayed.  Mount the filesystem to replay the log, and unmount it before

re-running xfs_repair.  If you are unable to mount the filesystem, then use

the -L option to destroy the log and attempt a repair.

Note that destroying the log may cause corruption -- please attempt a mount

of the filesystem before doing this.

 

I assumed that since unraid couldn't mount it during normal mode that using the -L option might be my only choice. I then ran the command again using the -L flag:

xfs_repair -vL /dev/md1

and the repair finished with only one change made. I could then start the array with no problems and I can see files from both disks.

 

Thanks again!

Don't forget to replace that SATA cable.

Thanks, I did and switched the raid port that I plugged it into. (It's funny that the cable was a new one, but I replaced it with an old one that I didn't have troubles with before.) I also have a brand new PSU coming in the mail tomorrow since this was an old HP computer that I repurposed.