I have a 6 drive array. The other day I noticed drive 1 was failing with sync errors. I upgraded it to an 8TB drive. As it was rebuilding the array, drive 4 started having massive sync failures.

Parity 8TB

Drive 1 (old 4TB new 8TB)

Drive 2 4TB

Drive 3 8TB

Drive 4 4TB (I have a new 4TB to replace it)

Drive 5 8TB

Drive 6 512GB (I use this for temp files while I decide where their final home wil be)

The other day I noticed drive 1 was failing with sync errors. I upgraded it to an 8TB drive. As it was rebuilding the array, drive 4 started having massive sync failures.

(Drive 4) Seek_Error_Rate FLAGS ( PO-R--) VALUE (062) WORST (062) THRESH (067) FAIL (NOW) RAW_VALUE (8126568)

I stopped the rebuild as it said it was going to take a month to complete the rebuild.

I still have the Drive 1 that I took out but the reason I was doing the upgrade was that it had some of the same errors hapening.

Should I replace Drive 4 with a new drive and let that rebuild, then replace drive 1 with the new one and rebuild again?

I am trying to avoid a rebuild taking a month. Typically when I do a parity check, it takes 1½ to 2 days.

Attach Diagnostics ZIP to your NEXT post in this thread.

I was looking for a log file to post but was unsure how. Attached is the diagnostics file.

tower-diagnostics-20260109-1713.zip

17 minutes ago, Erik M said:

Drive 6 512GB (I use this for temp files while I decide where their final home wil be)

SSDs in the parity array cannot be trimmed, and can only be written at parity speed. Usually SSDs would be put in a pool separate from the array.

Do you have enough ports so you could plug in original disk1 so we can take a look at its SMART report? Don't assign it or anything, just plug it in and post new diagnostics.

New diagnostic

tower-diagnostics-20260109-1741.zip

Is this original disk1?

Serial Number: P4GA8S4C

Doesn't look bad, maybe just a bad connection. Do you have logs from when it was acting up?

I do not. If I reassign that to it's original Drive 1 slot and remove the new 8tb, do I need to rebuild it? Or can I just go ahead and after reassigning it, replace the drive 4 and then start a rebuild from there?

Over the next few months, my objective is to replace the 4TB drives 1 at a time as they are aging out. I think its been 4 to 5 years on a couple of them.

By the way, I really appreciate the help. I'm in over my head on this one for sure.

I'm sorry, yes Serial Number: P4GA8S4C is the original Disk 1.

While doing the rebuild, it only got to just under 3% if that makes any difference.

1 minute ago, Erik M said:

If I reassign that to it's original Drive 1 slot and remove the new 8tb, do I need to rebuild it? Or can I just go ahead and after reassigning it, replace the drive 4 and then start a rebuild from there?

Not quite that simple, but there is a way to get Unraid to accept original disk1 back into the array, and disable disk4 instead.

Have you written to the array since disk1 became disabled?

Honestly I can't remember but if I did it was very little and I am ok with losing whatever that was. I don't think anyone did write to it though. As soon as I noticed the errors building up on Disk 4, I pulled the array offline.

Let's see what happens.

Go to Tools - New Config, Retain All, Apply

Reassign original disk1 as disk1.

Check BOTH Parity Valid and Maintenance Mode boxes then Start the array. This will accept original disk1 back into the array without modifying any disk.

Stop the array, Unassign disk4, start the array in normal (not Maintenance) mode with nothing assigned as disk4. This will disable disk4.

Then post new diagnostics so we can see if emulated/missing disk4 is mountable.

Here is the diagnostic after disableing Disk 4

PAH9J6XT is the 4TB but in the unassigned pool

2EJ0H9VX  is the new 8TB in the unassigned pool - Future replacement for the bad Drive 4

tower-diagnostics-20260109-1842.zip

Not working as well as it might, array must be out-of-sync with original disk1.

Check filesystem on emulated disk4 and we'll see how bad it is. Post the output.

1 minute ago, trurl said:

array must be out-of-sync with original disk1

Assuming disk4 was mountable before, which we have no evidence of.

7 minutes ago, trurl said:

Check filesystem on emulated disk4

Note that I do mean emulated disk4, not the physical disk.

It is not emulating Disk 4 and is in an endless loop

Should I put it back into slot 4 and then start the array and check the file syatem again.

Phase 1 - find and verify superblock...
error reading superblock 4 -- seek to offset 4000786989056 failed
couldn't verify primary superblock - attempted to perform I/O beyond EOF !!!

attempting to find secondary superblock...
.found candidate secondary superblock...
error reading superblock 4 -- seek to offset 4000786989056 failed
unable to verify superblock, continuing...

No that would just make it rebuild the unmountable filesystem on disk4.

See if you can mount physical disk4 as an Unassigned Device.

I was able to mount it as an Unassigned Device

It will not allow me to start the array though

Just now, Erik M said:

It will not allow me to start the array though

Don't understand, you had already started the array when you posted those last diagnostics. What did you do after that besides mount the Unassigned disk?

I had started it in maintence mode and went to Disk 4 Check Filesystem Status and thats where it was in the endless loop.

Then I mounted the drive from slot 4 in the unassigned devices area

Post a screenshot of Main - Array Operation

Ok, I rebooted and now it came up allowing me to start the array.

Just to make sure. You were using the webUI to check filesystem and not the command line, correct? Easy to get the command line wrong.

Have you checked the contents of the Unassigned (failing) disk?

Other disks look OK and have their contents.

We could create a new array with the new disk assigned as disk4, rebuild parity, and format the new disk4. Then see what could be copied from the Unassigned disk (original failing disk4). Maybe ddrescue could be helpful with that. I've never had to use it. I will ask @JorgeB to visit this thread and see what he thinks. Way past bedtime in his timezone so may be a few hours.