Hi all,

I want to sanity-check whether what I’m seeing is expected or if I made a mistake.

My original setup was:

• 1 parity disk: 5 TB

• 1 data disk in slot 1: 5 TB
  

The 5 TB data disk failed after a power loss (both are old already, was about to happen at some point).

Bought two new 8 TB disks to replace these disks (not at the same time, first the failed data disk).

Data disks cannot be larger than parity, so I did the parity swap procedure:

1. Assigned the new 8 TB disk to parity 1

2. Assigned the old parity drive to the data slot of the failed data drive (slot 1)

3. Copied the parity information over

4. The new 8 TB disk became parity

5. Started array and data was rebuilt on the old parity disk which became data disk

Completed without errors and the data is as expected.

After that, I wanted to add the second new 8 TB disk to the array. It will replace the old 5 TB drive for critical data, the 5 TB disk will still be there but for non critical data until failure.

For that reason, I wanted to rearrange the data disks: new 8 TB is slot 1, old 5 TB slot 2:

1. Created new config

2. Moved the 5 TB data disk from slot 1 to slot 2 (still the only data disk at this point)

3. Checked "parity is already valid"

4. Started the array.

5. Stopped the array.

6. Added the new 8 TB disk to slot 1 (disk had been precleared via unraid)

7. Started the array and formatted the new slot 1 disk as xfs-encrypted
   

Now I’m running a parity check and seeing this:

• First ~5 TB: no parity errors.

• After the 5 TB point: lots of parity errors/corrections (17553328 already at just 5.07 TB), increases rapidly.

• This started after the parity check hit the 5 TB mark (and thus passing / 'completing' the 5 TB data disk in slot 2)

• Both new disks are 8 TB.

• The old rebuilt data disk is 5 TB.

Remarks:

• The new 8 TB parity disk may not have been zeroed before use, I tested it with badblocks on another Linux machine before installing it.

• Data is still present and as expected

• I have not formatted or changed the rebuilt 5 TB data disk.

• Although the new 8 TB data disk has been added to the array, it is still empty. No data on it yet.

• All disks (especially the old one) seem healthy

• I'm running an older unRAID version (6.10.3), upgrading is next on the list

My current theory is that the 5–8 TB region of the new 8 TB parity disk may not have been initialized correctly during/after the parity swap, and only started mattering once I added the new 8 TB data disk.

Since the first 5 TB checks clean, I’m hoping the rebuilt 5 TB data is ok and the corrections are only for the expanded region.

Does this make sense? Should I let the correcting parity check finish, then run a second non-correcting parity check to confirm zero errors?

tower-diagnostics-20260528-0646.zip

Edited May 28May 28 by Rubene

You should be fine. There used to be an error where it was possible for the part of the parity drive beyond the largest data drive at the time was not always correctly zeroed, and as you are on such an old Unraid release I expect you encountered it.

Let the correcting check run to completion. A subsequent parity check should then return 0 errors.

Thanks, that matches what I was suspecting.

I'll let the current check finish and then run a second parity check which then should return 0 errors. I'll hold off with moving data around until that finished.

FYI: as it was the parity drive that failed there was a much quicker way to achieve what you wanted:

• Tools->New Config and assign all the drives as you wanted them to end up.

• Start the array without checking the parity is valid box. This would have made Unraid build parity based on the new data drive set.

However that is moot as what you did was a valid approach albeit a bit long-winded for your particular use case.

BTW this bug has been fixed some time ago, make sure you update.

10 minutes ago, itimpi said:

FYI: as it was the parity drive that failed there was a much quicker way to achieve what you wanted:

• Tools->New Config and assign all the drives as you wanted them to end up.

• Start the array without checking the parity is valid box. This would have made Unraid build parity based on the new data drive set.

However that is moot as what you did was a valid approach albeit a bit long-winded for your particular use case.

It was the data drive that failed, not the parity.

During the first replacement, I had:

• 5 TB parity drive (healthy)

• Failed 5 TB data disk

• New 8 TB disk available

That would make the replacement data disk larger than the existing parity, which cannot. So I started with the parity swap procedure: use the 8 TB as parity, rebuild the failed data disk onto the old parity disk.

And then I started rearranging the disks around to add another new 8TB disk. So quite a lot changed compared to original setup, that's why I needed a quick sanity check when I saw the parity errors...

Only a new config would not have worked in this case, correct?

1 minute ago, JorgeB said:

BTW this bug has been fixed some time ago, make sure you update.

I will! And thanks for confirming it's a known bug.

Upgrading it is long overdue already. I’ve had some hesitation around it, which made me procrastinate a bit, but since I’m changing quite a lot already, this seems like the right time :)

1 hour ago, Rubene said:

It was the data drive that failed, not the parity.

Actually it did not matter as in the special case of 1 data drive and one parity drive (parity1) the parity algorithm means they end up being mirrors of each other. This is not true as soon as you have more than 1 data drive.

Your procedure was the correct generic one that works regardless of the number of data drives in the main array.

29 minutes ago, itimpi said:

Actually it did not matter as in the special case of 1 data drive and one parity drive (parity1) the parity algorithm means they end up being mirrors of each other. This is not true as soon as you have more than 1 data drive.

Right, did not know that. Thanks!

First parity check finished with 732564000 errors, second did indeed finish with 0. All seems to be good now