As for the "reiserfsck /dev/md10" command, it did mention: "1 found corruptions can be fixed when running with --fix-fixable". Is it safe to go ahead? Should I go ahead and run it?

 

Yes, it's waiting for you to rerun it with the --fix-fixable parameter.  That should take care of any file system issues on Disk 10.  Either reiserfsck --fix-fixable /dev/md10 at the command prompt, or type the --fix-fixable option in the options box of the webGui, Check Filesystems section.

As for the "reiserfsck /dev/md10" command, it did mention: "1 found corruptions can be fixed when running with --fix-fixable". Is it safe to go ahead? Should I go ahead and run it?

 

Yes, it's waiting for you to rerun it with the --fix-fixable parameter.  That should take care of any file system issues on Disk 10.  Either reiserfsck --fix-fixable /dev/md10 at the command prompt, or type the --fix-fixable option in the options box of the webGui, Check Filesystems section.

 

Thanks RobJ, I just ran it. The xfs partition didn't seem to have found anything (or at least, it wasn't very verbose regarding what needs to fixed, if anything.) Should I go on thinking disk 12 is good. One thing to note is my disk 12 SMART has a high command timeout since the controller failure. Should I be worried?

 

188	Command Timeout	0x0032	100	099	000	Old age	Always	-	8590065666

 

Last question, now that everything is back to normal and file systems are fixed, what do I do with parity check? When I did the New Config, it took barely a second upon starting the array to report errors (as stated in a post above.) Does that mean I cannot run a parity check anymore?

 

Thanks again!

The xfs partition didn't seem to have found anything (or at least, it wasn't very verbose regarding what needs to fixed, if anything.) Should I go on thinking disk 12 is good.

It's something we have little experience with.  The convention is to report problems, and none were reported above, so the assumption would be that all is fine.  You could always run it again, see if the result is any different.

 

One thing to note is my disk 12 SMART has a high command timeout since the controller failure. Should I be worried?

 

188	Command Timeout	0x0032	100	099	000	Old age	Always	-	8590065666

Command timeout is a relatively new attribute, with inconsistent behavior.  It's not a critical attribute, and the scaling algorithm looks like just a dummy one, and the RAW number seems to be vendor specific, a coded set of subfields, unusable for us.  I consider it an unusable attribute and ignore it, but I note that BackBlaze seems to give it some credence, but they haven't explained why, or how to interpret the values.  There's nothing you can do with it currently, so I recommend ignoring it too.

 

Last question, now that everything is back to normal and file systems are fixed, what do I do with parity check? When I did the New Config, it took barely a second upon starting the array to report errors (as stated in a post above.) Does that mean I cannot run a parity check anymore?

If you are sure the data drives are now correct, then it's time to bring the parity drive into sync with the array drives.  Run a correcting parity check, ignore the errors.

Thanks for your reply RobJ!

 

I'm also new to this "Command Timeout" attribute. It's worth to note that Unraid reports this attribute as an error through notification popup whenever I start the array. I'll do like you mentioned and ignore it.

 

As for the drives being correct, I'm not 100% sure. The reiserf partition had 1 error in the table and was fixed with the proper command. The xfs partition didn't report anything that would lead me to an issue. I'll run it again.

 

So, I'll do a parity check. When you say that I may ignore the errors, is this because the content differs from the parity? If so, when the parity will be fixed, no content should be lost, right? This should only update the parity's checksum for each bit?

 

Thanks for all of your help Unraid community! It's appreciated!

I'm also new to this "Command Timeout" attribute. It's worth to note that Unraid reports this attribute as an error through notification popup whenever I start the array. I'll do like you mentioned and ignore it.

I've requested an update to the SMART handling to remove Command Timeout.

 

So, I'll do a parity check. When you say that I may ignore the errors, is this because the content differs from the parity?

Yes, that's why you saw errors before, and you will again on the rerun.

 

If so, when the parity will be fixed, no content should be lost, right? This should only update the parity's checksum for each bit?

That's correct, content is fine, will not be changed.  Only the parity is being updated to correctly match the content.

Thanks RobJ, trurl and all of the nice folks from the forum for the support!

 

Also, thanks for the removing the timeout value. It may reduce support on the forum for that error code, if it ever happens to someone else. I'll give a parity check a try and report back if anything. I'm just glad to be back in business (fingers crossed!) Have yourself a great weekend!