6.3.2 - Red "X" on Parity Disk

[wreck]

I recently upgraded to 6.3.2 and now when I start things up I have a red X next to my parity disk and a message that says " ALL DATA ON THIS DISK WILL BE ERASED WHEN ARRAY IS STARTED ". All other drives show green, but I don't know if there is something I should do to avoid issues or having to rebuild my parity drive completely. Diagnostics are attached, if anything else is needed please let me know. Thanks in advance for any and all help.

 

bux

tower-diagnostics-20170326-1551.zip

[Dissones4U]

This may be too simple but when you assigned it did you by chance tell it to change file systems? I have to assume not if the other disks are ok but you never know. Otherwise did you find this? Hopefully one of the experts will have some advice for you, until then I'd refrain from doing anything drastic until you're sure, at least you have retrieved your logs and such before rebooting.

[wreck]

Dissones4U, thanks for the reply. No, I didn't change anything with the file system for that drive or any others. Is there something I can do to make sure that this wasn't changed by accident or anything like that? I do believe that the parity disk is the only one in the array that is formatted as the "new" file system, but things have been running like that for awhile now without issue. Any other ideas? Questions? Things to try? Thanks in advance.

[Frank1940]

The thing is that the parity disk does not have a file system.  Its contents are the result of a mathematical operation on the data contained on all of the data disks.  From what I saw, it was the largest disk (4TB) and thus it must have been the parity disk on the earlier version unless you made some changes in conjunction with the upgrade.  What is the history of this 4TB drive?  Is it new to this server? 

[wreck]

Frank1940, thanks for the reply. You are correct, this disk has been the parity disk all along. I haven't made any changes to the disks in quite awhile, nothing has been added, taken away or even swapped. This 4tb drive has been the parity the whole time it's been in the server and it was added awhile ago. The main change recently was the upgrade to 6.3.2, from 6.2.4 (I'm pretty sure).

[Dissones4U]

19 minutes ago, buxton said:

Dissones4U, thanks for the reply. No, I didn't change anything with the file system for that drive or any others. Is there something I can do to make sure that this wasn't changed by accident or anything like that? I do believe that the parity disk is the only one in the array that is formatted as the "new" file system, but things have been running like that for awhile now without issue. Any other ideas? Questions? Things to try? Thanks in advance.

 

Did you read the link in my post, I think that may answer it for you. I'm new to unraid so hopefully someone else will chime in but it sounds like that warning may be generic like the "are you sure" that Windows gives before making basic changes? 

[wreck]

Dissones4U, somehow I missed that link completely the first time. I checked it out now though and it makes sense. I took the super.dat from my backup I made before the 6.3.2 upgrade and copied it over, now the parity drive shows up like normal, green ball, no red X. I'm going to start it back up now and let it run the parity check, but I'm pretty sure that did the trick. I'll post back once the check is complete. Thank you both very much for all of your help.

[trurl]

Just now, buxton said:

Dissones4U, somehow I missed that link completely the first time. I checked it out now though and it makes sense. I took the super.dat from my backup I made before the 6.3.2 upgrade and copied it over, now the parity drive shows up like normal, green ball, no red X. I'm going to start it back up now and let it run the parity check, but I'm pretty sure that did the trick. I'll post back once the check is complete. Thank you both very much for all of your help.

This was not really the correct thing to do. I guess I see where you got that idea since I'm the one who posted it in that thread, but the entire thread was about a totally different situation than the one you were in. I think the point Dissones4U was trying to make was that the warning was completely normal and you should go ahead and let it rebuild parity.

 

Basically, copying your super.dat reset your configuration back to what it was earlier, before the disk was disabled, but that configuration was not really true any longer since you had gotten a disabled parity disk.

 

Fortunately you should still be OK, but copying super.dat in your situation was pointless, and unless you really understand why you are doing it, it can be a bad idea since if your backup super.dat doesn't match your current configuration you could make things very much worse.

 

What you should have done was let it rebuild parity like it wanted to. Since parity was probably not very far wrong it's likely there won't be many parity errors corrected when it checks. Hopefully you are doing a correcting parity check. A parity rebuild would have been quicker but just let it go.

 

The rest of this is the post I was composing while you went ahead without further advice, and since it might have some useful information I am including it. And if you have the problem again during the current parity check, it also tells you what you should do.

 

Looks like you rebooted before getting the diagnostic, so we can't see the event that disabled your parity drive. You should always try to get a diagnostic before rebooting.

 

unRAID disables a disk when a write to it fails. The failed write means the disk contents are no longer valid. As long as you don't have more disabled disks than you have parity disks, the valid data for a disk can be rebuilt from the other disks. This is generally true whether we are talking about a data disk or the parity disk.

 

SMART for the disk looks OK so it is probably something else like a bad connection. Bad connections are the most common reason for disabled disks. Check connections and proceed to rebuild.parity.

 

[wreck]

OK, the parity check that ran finished and everything looks to be back to normal now. It was a correcting parity check and it corrected 30883039 errors. I think I understand what you mean trurl about moving the super.dat not being the best move, but it seems that everything worked out in the end. I also believe you were right about the issue before being a bad connection, which also seems to be back to normal now (the drives are in hot swap bays, so I re-seated everything recently). It makes sense to rebuild a drive that shows an issue like that one did (the ability to do that is the whole point of unraid, after all), instead of trying to trust it and keep moving, I just think the idea of having to rebuild a drive still makes me uneasy a little. I'll get over things sooner or later, in the meantime, thanks again for all the help and advice.

 

bux

[trurl]

16 minutes ago, buxton said:

OK, the parity check that ran finished and everything looks to be back to normal now. It was a correcting parity check and it corrected 30883039 errors. I think I understand what you mean trurl about moving the super.dat not being the best move, but it seems that everything worked out in the end. I also believe you were right about the issue before being a bad connection, which also seems to be back to normal now (the drives are in hot swap bays, so I re-seated everything recently). It makes sense to rebuild a drive that shows an issue like that one did (the ability to do that is the whole point of unraid, after all), instead of trying to trust it and keep moving, I just think the idea of having to rebuild a drive still makes me uneasy a little. I'll get over things sooner or later, in the meantime, thanks again for all the help and advice.

 

bux

That's really a lot more parity errors than I would have expected, unless you had written a lot of data to the array after parity got disabled, or unless parity had never been built to begin with. You should do another parity check. Anytime I have any parity errors at all I always do another check. The correct and only acceptable answer is zero parity errors, since parity errors will prevent you from getting a good rebuild of a data disk if you ever need it.

[wreck]

Yes, I wrote a good bit of data to the array with partiy disabled, so that would probably explain the big number. I'm going to wait until the start of the month check in a few days and see how that goes. I'll report back in this thread about the # of errors. Thanks. 

[wreck]

Sorry it took me a few days to post the update, but the start of the month parity check completed and found 0 errors. I believe everything is good to go now. Thanks for everybody's help and input.