(SOLVED) Replacing a drive with a larger size drive

[elbobo]

I currently have 5 3TB drives in my oldest UnRaid server, one of my drives has 7 as a UDMA CRC error count that seems to have added 1 to that count in a 2 week time and 1 as a Current pending sector that has not changed in the 2 weeks. 

I have a 4TB drive that can be dropped in, but I know this would need to become the Parity since it is the largest in the system. 

On to the question(s)

How risky is doing a full new parity while that disk has these errors? (Should I hunt down a 3TB to not risk it?) 

Does it make any sense to move the parity to replace the drive with the errors when the parity drive has 5y and 4 days of up time? The SMART looks clean and I cannot afford to replace all 5 at this time but I can grab another 1 If it would be silly to go through the work of rebuilding on such an old drive (and replace the others as time goes on) 

 

Of note: There is nothing on there that I cannot live without that doesn't have redundant backup to an offsite location, but I'd rather not have to go that route.

 

Thank you for your time

 

Edited December 5, 2018 by elbobo

[JorgeB]

9 minutes ago, elbobo said:

one of my drives has 7 as a UDMA CRC error count that seems to have added 1 to that count in a 2 week time

This is not a disk problem, usually a bad SATA cable.

 

9 minutes ago, elbobo said:

and 1 as a Current pending sector

This is, though is same cases it's a false positive, run an extended SMART test on this disk and then post the diagnostics.

[elbobo]

Attached is the outcome of the extended SMART test. Thank you!

WDC_WD30EZRZ-00WN9B0_WD-WCC4E6ZYVE2Y-20181119-1755.txt

[John_M]

That disk is failing.

[elbobo]

On 11/19/2018 at 6:28 PM, John_M said:

That disk is failing.

Thank you, with that being said

I have a 4TB drive that can be dropped in, but I know this would need to become the Parity since it is the largest in the system. 

 

How risky is doing a full new parity while that disk has these errors? (Should I hunt down a 3TB to not risk it?) 

Does it make any sense to move the parity to replace the drive with the errors when the parity drive has 5y and 5 days of up time? The SMART looks clean and I cannot afford to replace all 5 at this time but I can grab another 1 If it would be silly to go through the work of rebuilding on such an old drive (and replace the others as time goes on) 

[JorgeB]

45 minutes ago, elbobo said:

How risky is doing a full new parity while that disk has these errors? (Should I hunt down a 3TB to not risk it?) 

You can use the parity swap procedure, it's exactly for these situations:

https://wiki.unraid.net/The_parity_swap_procedure

 

[elbobo]

I did the parity swap procedure as suggested and everything seemed great. Last night my monthly parity check ran and it came back with 183141001 errors. Reading the forum it appears that during the process the extra 1TB that my parity is as compared to the drives in the system didn't properly wipe during the parity swap procedure. 

In the conversations that followed there was the recommendation to do another parity sync instead of a parity check (fix) because the it is less intensive (write to parity vs read from parity, compare value, write if necessary) for all the sectors that have an error. 

I cannot find how to just do a new Parity sync. 

 

Thank you,

[John_M]

The quickest way to force a parity re-sync is to stop the array, un-assign parity, start the array without parity, stop the array, re-assign parity, and finally start the array and let it build. Grab new diagnostics - there might be some indication as to what went wrong.

 

But is that what you want to do? Since Disk 3 is failing it might not be entirely readable, which was the reason for doing the parity swap in the first place - so that you could then rebuild Disk 3 onto a new disk.

 

Edited December 1, 2018 by John_M

[JorgeB]

Reading the forum it appears that during the process the extra 1TB that my parity is as compared to the drives in the system didn't properly wipe during the parity swap procedure. 

This shouldn't happen, do you by any chance have the syslog/diags covering the swap?

 

 

[elbobo]

20 hours ago, John_M said:

The quickest way to force a parity re-sync is to stop the array, un-assign parity, start the array without parity, stop the array, re-assign parity, and finally start the array and let it build. Grab new diagnostics - there might be some indication as to what went wrong.

 

But is that what you want to do? Since Disk 3 is failing it might not be entirely readable, which was the reason for doing the parity swap in the first place - so that you could then rebuild Disk 3 onto a new disk.

 

The failing disk has been pulled. 

I made it through the entire parity swap without any issues, and was able to rebuild the failing disk onto the former parity disk also without errors. 

It was only during the monthly parity check that this issue was discovered. (hindsight I should have run a parity when it was complete)

 

[elbobo]

16 hours ago, johnnie.black said:

This shouldn't happen, do you by any chance have the syslog/diags covering the swap?

 

 

Attached... I misspoke (mistyped) in my previous reply, the failing disk has not been physically pulled, it is in the system but is in the unassigned devices. 

Thankfully this means my current diagnostics still has the entire process in it. 

tower-diagnostics-20181201-1413.zip

[JorgeB]

Everything appears to have been correctly, it's not the first time this happens but I was never able to reproduce it, did a couple of swaps myself recently without any issues, it's strange, will try to investigate further when I have the time.

[elbobo]

I'm happy to know that it wasn't something I did. I unassigned and reassigned the parity to begin a new sync. Once it completes I will run a parity check for piece of mind. 

I've gone ahead and marked this as solved. Thank you for your help