2 minutes ago, clowncracker said:

5) Start the array.

6a) Run a parity check, if there are issues I should restart the process with another drive.

Yes, but just to confirm, after step 5 you need to wait for the parity sync to finish

17 minutes ago, JorgeB said:

Yes, but just to confirm, after step 5 you need to wait for the parity sync to finish

 

Even if it detects issues?  I should be running a non-correcting parity check right?

Edited November 9, 20232 yr by clowncracker

Do you think it's worth testing the parity drives even if they are brand new?  I wasn't having any issues until a drive failed mid-parity check (non-correcting), so it makes me think the parity drives cannot be the problem.  If I did want to test them, I should remove both parity disks and put in a new drive and rebuild parity?

Part of me is concerned about rebuilding the parity disks if one of the data disks might be an issue.  If another drive fails during a parity rebuild, then at that point won't I have corrupted data permanently?

If not testing parity, which disk do you think is most likely the culprit?  Disk 3 that was just recently replaced that started the whole problem?  Disk 4 that has some relocated sector counts? Or Disk 10, which is the newest disk in the array?

Edited November 9, 20232 yr by clowncracker

28 minutes ago, clowncracker said:

Even if it detects issues?

After a new config with a missing disk parity won't be valid, so you fir need to sync parity, then run a non correcting parity check

4 minutes ago, JorgeB said:

After a new config with a missing disk parity won't be valid, so you fir need to sync parity, then run a non correcting parity check

Based on my comments what do you think about checking the parity drives?  Do you think it's worth the risk, especially since they are essentially brand new?

Something else I'm curious about.  If I start the array with a new config and a disk missing, won't I just lose the data currently on the disk?  Since it isn't on the array and it won't be emulated since the disk doesn't exist in the new array.

Edited November 9, 20232 yr by clowncracker

On 11/9/2023 at 10:47 AM, JorgeB said:

After a new config with a missing disk parity won't be valid, so you fir need to sync parity, then run a non correcting parity check

 

Just wanted to follow up.

On 11/9/2023 at 6:50 PM, clowncracker said:

Something else I'm curious about.  If I start the array with a new config and a disk missing, won't I just lose the data currently on the disk?  Since it isn't on the array and it won't be emulated since the disk doesn't exist in the new array.

Yes (as you also will not have valid parity at that point).

7 hours ago, itimpi said:

Yes (as you also will not have valid parity at that point).

Then won't @JorgeB's solution lead to permanent data loss?  Aren't I just better off just doing a correcting parity check?

Edited November 11, 20232 yr by clowncracker

23 minutes ago, clowncracker said:

Then won't @JorgeB's solution lead to permanent data loss?  Aren't I just better off just doing a correcting parity check?

If you read @JorgeB answer he recommends a sync (which is effectively a correcting check) followed by a non-correcting check to make sure everything is now good.

2 hours ago, itimpi said:

If you read @JorgeB answer he recommends a sync (which is effectively a correcting check) followed by a non-correcting check to make sure everything is now good.

So I shouldn't be deselecting any drives then?  What is the functional difference between doing a sync by creating a new config and and just doing a correcting parity check?

18 minutes ago, clowncracker said:

So I shouldn't be deselecting any drives then?  What is the functional difference between doing a sync by creating a new config and and just doing a correcting parity check?

Functionally they are identical.   

 

In one case you do not tick the Parity is Valid box after New Config so Unraid knows it has to rebuild parity with the new drive set and starts doing this as soon as you start the array.    In the other case you incorrectly check the Parity is Valid box so Unraid thinks it does not need to rebuild parity when you start the array, but when you run the correcting check it ends up having to correct sectors that do not agree with parity.   I have a feeling that there may be a slight performance difference in that the sync is likely to be slightly faster.

 

In both cases until you have valid parity your are not actually protected against a drive failing.

@itimpi I opted to go for the correcting parity check since it was functionally the same.  Did a second parity check afterwards and there were 0 issues.

 

@trurl thank you for your help with the original issue, I wish I could give you both the solution.

I've started running my monthly non-correcting parity check and it was going smoothly until about an hour ago.  Now the estimated finish is in ~30 days.  It looks like a lot of writing is happening to disk 3, but I don't know what is happening:

 

Edited December 1, 20232 yr by clowncracker
removed diagnostics

You are likely to get better informed feedback if you attach your system’s diagnostics zip file to your next post in this thread so we can get an idea of what might be going on.

I'd like to note that writes to parity and disk 3 are continually increasing every second:

 

I think I found the issue, it looks like mover started running during the parity check.  I thought that couldn't normally happen, but that explains the writes to drive 3 and the parity drives.  I noticed the amount of free storage on my cache was increasing, so I paused the parity check and sure enough mover was running.  Once mover is done I'll resume the parity check and see if that solves the problem.

That ended up being the issue, parity check and mover were running at the same time.