Drive swap bigger than parity

[smaster]

Hey guys,

I currently have 30 drives in my array.

Parities are 16TB and 14TB.

I've had a drive failure (3TB) and want to replace it with a 16TB drive.

I know the fact that the replacement being larger makes the process a little different and I'd just like to confirm that I have the right idea:

 

1. Stop Array
2. Remove the failed hard drive
3. Insert the new hard drive
4. In the "Main" section of unRAID, unassign the 14TB parity
5. Assign the new 16TB drive to parity
6. Assign the old parity drive in place of the failed drive
7. Proceed to a parity swap (essentially transferring the data from the old parity to the new one)
8. Start the array and rebuild the old drive from the newly created parity

 

If this is all correct, I'd just like to also ask a few questions:

• While the new parity drive is being built, is the array inaccessible?
• Is there anything I can do to my new drive before I put it in my server that will speed up the process? Pre-clear or something along those lines? I'd like to avoid as much downtime as possible.

 

Thanks for your time.

[JorgeB]

Array will not be accessible during the parity copy part, it will be once the rebuild begins, nothing you can do to speed up the copy.

[smaster]

21 hours ago, JorgeB said:

Array will not be accessible during the parity copy part, it will be once the rebuild begins, nothing you can do to speed up the copy.

 

Thanks for your answers.

I have a follow-up, currently my parity check seems to be stuck at 40.9% for a few days and even when I press cancel or pause it doesn't do anything. I'm just worried that the parity isn't fully up-to-date or correct and when doing a parity swap some data will be lost.

I attached the diags if that helps.

 

Thanks a bunch.

tower-diagnostics-20240105-1510.zip

[JorgeB]

You likely have a container constantly restarting spamming the log, check the uptime of all containers, because of that it's difficult to see if there was any issue with the parity check, but there's still read activity on all disks

[smaster]

5 hours ago, JorgeB said:

You likely have a container constantly restarting spamming the log, check the uptime of all containers, because of that it's difficult to see if there was any issue with the parity check, but there's still read activity on all disks

Should a docker constantly restarting stop me from cancelling or pausing the parity check?

When pressing pause or cancel here, it essentially doesn't do anything.

 

Thanks.

[JorgeB]

12 hours ago, smaster said:

Should a docker constantly restarting stop me from cancelling or pausing the parity check?

Nope, but it's making it difficult to search the log for other issues.

[smaster]

15 hours ago, JorgeB said:

Nope, but it's making it difficult to search the log for other issues.

Hey,

I found the culprit. It was mongodb.

It's fixed and the last 2 error messages are when I press "pause" or "cancel" in the parity check. Here they are:

Jan  7 00:53:28 Tower nginx: 2024/01/07 00:53:28 [error] 20161#20161: *24622960 connect() to unix:/var/run/emhttpd.socket failed (11: Resource temporarily unavailable) while connecting to upstream, client: 192.168.1.105, server: , request: "POST /update.htm HTTP/1.1", upstream: "http://unix:/var/run/emhttpd.socket:/update.htm", host: "192.168.1.118", referrer: "http://192.168.1.118/Main"
Jan  7 00:53:49 Tower nginx: 2024/01/07 00:53:49 [error] 20161#20161: *24622934 connect() to unix:/var/run/emhttpd.socket failed (11: Resource temporarily unavailable) while connecting to upstream, client: 192.168.1.105, server: , request: "POST /update.htm HTTP/1.1", upstream: "http://unix:/var/run/emhttpd.socket:/update.htm", host: "192.168.1.118", referrer: "http://192.168.1.118/Main"

 

Diags attached and there are a few more errors that I got previously, here is an example of one:

Jan 6 21:48:08 Tower kernel: pcieport 0000:00:1c.4: AER: Multiple Corrected error received: 0000:06:00.0 Jan 6 21:48:08 Tower kernel: atlantic 0000:06:00.0: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID) Jan 6 21:48:08 Tower kernel: atlantic 0000:06:00.0: device [1d6a:d107] error status/mask=00000041/0000a000

 

Any idea how to get the parity check going and making sure it's all good before going about a parity swap?

 

Thanks a bunch.

tower-diagnostics-20240107-0057.zip

[JorgeB]

There's still something reading from all disks, doesn't look like parity since it's reading them differently, any idea what that is?

[smaster]

16 hours ago, JorgeB said:

There's still something reading from all disks, doesn't look like parity since it's reading them differently, any idea what that is?

 

Hey,

So I've stopped the docker network completely and I now believe there should be nothing major running.

I also tried again to pause or cancel, but nothing happened.

The diags are attached.

 

Thanks and sorry for the hassle, just trying to do this the right way.

tower-diagnostics-20240108-0346.zip

[JorgeB]

Still some disk read activity going on, but less then before, if you cannot cancel the check type reboot in the CLI.