Hi all, I’m looking for some help with my first drive replacement in Unraid.

I had a drive start failing, so I wanted to replace it. My array consists of 5 x 12 TB drives total: 1 parity drive and 4 data drives. Disk 4 was the failing drive, and I bought an exact replacement.

I tried following the Unraid docs for “Replacing disks in an array”, but I’m not sure where I went wrong. What I did was:

1. Powered the server down.

2. Physically replaced the failing drive with the new one.

3. Powered the server back up.

4. Started the pre-clear process on the new drive.

5. Started the array in the meantime so disk 4 would be emulated through parity.

Ater the pre-clear finished, I tried assigning the new drive to disk 4, but I can’t start the array to begin the rebuild. The error I get is: “Stopped. Disk in parity slot is not biggest." “If this is a new array, move the largest disk into the parity slot. If you are adding a new disk or replacing a disabled disk, try Parity-Swap.”

All of my drives are 12 TB and the same make/model, so I assumed they would all be the same size. I’m wondering if Unraid is seeing a small size difference between the drives and treating parity as smaller somehow.

At this point, would I be better off using the parity-swap process? Reading through the docs, it seems like that may solve the issue if I assign the new drive to parity and move the old parity drive to disk 4. The new drive has 0 reallocated sectors, so I’m wondering if it’s being seen as slightly “bigger” and causing the error.

Is there any way to bypass this, or should I just go ahead with parity-swap?

Thanks!

Attach Diagnostics ZIP to your NEXT post in this thread.

Also, what do you get from command line with this?

lsblk

root@Tower:~# lsblk

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS

loop0 7:0 0 579.8M 1 loop /usr

loop1 7:1 0 169.8M 1 loop /lib

loop2 7:2 0 60G 0 loop /var/lib/docker/btrfs

/var/lib/docker

sda 8:0 1 14.5G 0 disk

└─sda1 8:1 1 14.5G 0 part /boot

sdb 8:16 0 10.9T 0 disk

└─sdb1 8:17 0 2T 0 part

sdc 8:32 0 10.9T 0 disk

└─sdc1 8:33 0 10.9T 0 part

sdd 8:48 0 10.9T 0 disk

└─sdd1 8:49 0 10.9T 0 part

sde 8:64 0 10.9T 0 disk

└─sde1 8:65 0 10.9T 0 part

sdf 8:80 0 10.9T 0 disk

└─sdf1 8:81 0 10.9T 0 part

md1p1 9:1 0 10.9T 0 md /mnt/disk1

md2p1 9:2 0 10.9T 0 md /mnt/disk2

md3p1 9:3 0 10.9T 0 md /mnt/disk3

md4p1 9:4 0 10.9T 0 md /mnt/disk4

nvme0n1 259:0 0 465.8G 0 disk

└─nvme0n1p1 259:1 0 465.8G 0 part /mnt/cache

tower-diagnostics-20260328-2234.zip

Strange. Usually when this happens, it is because you are trying to replace parity with a disk that is smaller in some way. But in this case, it is the replacement data disk that is larger in some way and all the other data disks are the same size as parity. All disks seem to be the same model, only a single partition on each. And they are all on the same controller.

Probably parity swap is going to be the way out of this as you suggest, but it might be educational if @JorgeB could take a look. Shouldn't be too many more hours before daylight in his timezone.

alright, thanks! I'll sleep on it tonight, if no solution arises by tomorrow, I'll go ahead and start the parity swap procedure.

This is not common, but the new disk really is physically larger than the other ones:

Mar 26 18:05:57 Tower emhttpd: online: ST12000NM0127_ZJV39V5B (sdd) 512 23437770752

Mar 26 18:05:57 Tower emhttpd: online: ST12000NM0127_ZJV5L00J (sde) 512 23437770752

Mar 26 18:05:57 Tower emhttpd: online: ST12000NM0127_ZJV2974K (sdb) 512 23440115664

Mar 26 18:05:57 Tower emhttpd: online: ST12000NM0127_ZJV53E25 (sdf) 512 23437770752

Mar 26 18:05:57 Tower emhttpd: online: ST12000NM0127_ZJV2HZ5C (sdc) 512 23437770752

So the only option is a parity swap.

I didn't have a SMART report for a typical 12TB handy for comparison. Are those other disks the typical size? Or is the new disk the typical size and the others are small for some reason? Is HPA still a thing?

Thanks guys, I appreciate you digging into this for me. The only difference I could think between the drives is the first 5 I bought were "refurbished" and the newer one I bought was "renewed".

Since I've already pre-cleared the new drive, I'll go ahead and start the party swap asap. Thanks!

Just now, mufasa510 said:

first 5 I bought were "refurbished" and the newer one I bought was "renewed"

I wonder if this is the reason for the different sizes. And I wonder if we won't begin to see more of this with the higher drive prices these days.

I went looking for other diagnostics with a 12TB drive. Those smaller drives seem to be typical, really odd the new one reports as being larger. I wonder if it really is?

And why?

I have 7 of these Seagate Ironwolf Drives (ST12000-VN0008) which I purchased new and they all are this size:

I suspect that some one has overwritten the data in the NAND on the drive during the 'renewed' process. I understand that there is a lot of this type of activity going on as drive prices have recently increased and some overseas vendors are recycling drives removed from servers with high numbers of power-on hours, reflashed the NAND to make them look like they are virtually new.

See this article:

www.forbes.com/sites/tomcoughlin/2025/02/08/seagate-responds-to-misrepresented-used-hard-disk-drive-sales/

So I went digging, and found that firmware versions could be causing the difference in sector counts, but all drives are on the same version (G006). I then read through the Seagate product manual, only thing interesting is section 2.2, where it states GUARANTEED sectors would be 23,437,770,752, implying that the sector counts could be greater. The product manual also states that "Accessible capacity may vary depending on operating environment and formatting." so it's possible I just got lucky with an extra 1.2GB of storage Woo Hoo!

But I'm doubtful that it's a drive with only ~60 power-on hours, with 55 of those hours from the pre-clear. I'll just keep an eye out for health degradation signals.

20 minutes ago, mufasa510 said:

"Accessible capacity may vary depending on operating environment and formatting."

Parity has no format so that isn't a consideration in this case. This is the only time I have ever seen a drive with more than the typical size, and less than typical isn't seen much anymore since everyone decided HPA was an unwelcome surprise.