Hello,
some days ago I have upgraded from a previous version to 25.10.6. Before doing this, my system hat a mirror vdev containing two drives with different size. I do not remember, which size the vdev had, but after upgrading TrueNas the drive sda of about 5TB is not attached to the mirror and the mirror is degraded.
Trying to add the devise sdb again fails with error telling the drive is to small. So this is bad. It seem that the vdev now has 7 TB which is the size of drive sdb, is automatic resized and is degraded. So how comes and what to do for repairing? Shrinking is not possible.
But on the other hand, I see this in shell:
admin@truenas[~/Dokumentation]$ lsblk /dev/sda /dev/sdb
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 5.5T 0 disk
sdb 8:16 0 7.3T 0 disk
└─sdb1 8:17 0 7.3T 0 part
admin@truenas[~/Dokumentation]$ zpool list Storagepool
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
Storagepool 5.45T 2.16T 3.29T - 1.81T 15% 39% 1.00x DEGRADED /mnt
admin@truenas[~/Dokumentation]$
So good news: The pool itself has size of 5.45T, so it can fit into the drive sda. But where is the partition of sda.
Provide the outputs of these. Please use preformatted text as separate boxes for each output.
zpool list -v Storagepool
zpool status -v Storagepool
zpool history Storagepool | grep 'zpool remove\|zpool detach\|zpool offline\|zpool online'
lsblk -o NAME,PARTUUID,SIZE,MODEL,PTTYPE,TYPE,PARTTYPENAME
Here it is (lsblk reduced to the two drives, history as sudo):
zpool list -v Storagepool
admin@truenas[~]$ zpool list -v Storagepool
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
Storagepool 5.45T 2.16T 3.29T - 1.81T 15% 39% 1.00x DEGRADED /mnt
mirror-0 5.45T 2.16T 3.29T - 1.81T 15% 39.7% - DEGRADED
16671667498307053037 - - - - - - - - UNAVAIL
5e20d6d2-6b7b-49be-9e12-0ee358e0b0eb 7.28T - - - - - - - ONLINE
admin@truenas[~]$
zpool status -v Storagepool
admin@truenas[~]$ zpool list -v Storagepool
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
Storagepool 5.45T 2.16T 3.29T - 1.81T 15% 39% 1.00x DEGRADED /mnt
mirror-0 5.45T 2.16T 3.29T - 1.81T 15% 39.7% - DEGRADED
16671667498307053037 - - - - - - - - UNAVAIL
5e20d6d2-6b7b-49be-9e12-0ee358e0b0eb 7.28T - - - - - - - ONLINE
admin@truenas[~]$ zpool status -v Storagepool
pool: Storagepool
state: DEGRADED
status: One or more devices could not be used because the label is missing or
invalid. Sufficient replicas exist for the pool to continue
functioning in a degraded state.
action: Replace the device using 'zpool replace'.
see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-4J
scan: scrub repaired 0B in 08:10:40 with 0 errors on Sun Aug 2 08:10:45 2026
config:
NAME STATE READ WRITE CKSUM
Storagepool DEGRADED 0 0 0
mirror-0 DEGRADED 0 0 0
16671667498307053037 UNAVAIL 0 0 0 was /dev/disk/by-partuuid/04b8a2ed-a4e6-48ea-b54d-8512d44d51c0
5e20d6d2-6b7b-49be-9e12-0ee358e0b0eb ONLINE 0 0 0
errors: No known data errors
admin@truenas[~]$
zpool history Storagepool | grep ‘zpool remove|zpool detach|zpool offline|zpool online’
admin@truenas[~]$ sudo zpool history Storagepool | grep 'zpool remove\|zpool detach\|zpool offline\|zpool online'
[sudo] password for admin:
2025-08-18.20:16:44 py-libzfs: zpool offline Storagepool /dev/disk/by-partuuid/90bd491a-5e31-48d0-8436-46708299111f
2025-08-18.20:17:11 py-libzfs: zpool offline Storagepool /dev/disk/by-partuuid/90bd491a-5e31-48d0-8436-46708299111f
2025-08-19.16:02:25 py-libzfs: zpool online Storagepool /dev/disk/by-partuuid/90bd491a-5e31-48d0-8436-46708299111f
2025-08-24.15:43:14 py-libzfs: zpool offline Storagepool /dev/disk/by-partuuid/90bd491a-5e31-48d0-8436-46708299111f
2025-08-24.16:06:17 py-libzfs: zpool online Storagepool /dev/disk/by-partuuid/90bd491a-5e31-48d0-8436-46708299111f
2025-08-24.16:06:47 py-libzfs: zpool detach Storagepool /dev/disk/by-partuuid/90bd491a-5e31-48d0-8436-46708299111f
admin@truenas[~]$
lsblk (I changed a bit so that only the two drives are listed)
admin@truenas[~]$ lsblk -o NAME,PARTUUID,SIZE,MODEL,PTTYPE,TYPE,PARTTYPENAME /dev/sda /dev/sdb
NAME PARTUUID SIZE MODEL PTTYPE TYPE PARTTYPENAME
sda 5.5T WDC WD60EFRX-68MYMN1 disk
sdb 7.3T ST8000VN002-2ZM188 gpt disk
└─sdb1 5e20d6d2-6b7b-49be-9e12-0ee358e0b0eb 7.3T gpt part Solaris /usr & Apple ZFS
admin@truenas[~]$
“Add”? Do you mean “replace”? How are you trying to do this?
Sorry for not making it clear: Under “Storagepool VDEVs” menu “Disk Info” I tried replace. In the opening modal dialog I could choose the 5.46TiB Disk, “Force” not checked and clicked “Replace Disk”
How was it in the vdev in the first place?
Add -b to the lsblk command and -p to the zpool list command.
zpool list -p -v Storagepool
lsblk -b -o NAME,PARTUUID,SIZE,MODEL,PTTYPE,TYPE,PARTTYPENAME
What do you mean with this? Don’t understand. And: wait a bit, I just startet the replace again to post the error message again. But it will not show up at the moment, the system is busy doing a backup in background 
But I will post the result of the new commands in the next post, so wait.
In your OP you said you tried using the same disk that was previously in the vdev. This means it was large enough for the mirror vdev before. If it is the same disk, it should technically be large enough, since you did not “expand” your pool. It’s possible that TrueNAS is now trying to leave a 2-GiB “buffer” on the disk, which makes it too small to add to the vdev.
How did the disk get ejected from the vdev? Errors? Failure? This is important to know.
Here it is
admin@truenas[~]$ zpool list -p -v Storagepool
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
Storagepool 5995774345216 2378358177792 3617416167424 - 1992864825344 15 39 1.00 DEGRADED /mnt
mirror-0 5995774345216 2378358177792 3617416167424 - 1992864825344 15 39 - DEGRADED
16671667498307053037 - - - - - - - - UNAVAIL
5e20d6d2-6b7b-49be-9e12-0ee358e0b0eb 8001560772608 - - - - - - - ONLINE
admin@truenas[~]$
admin@truenas[~]$ lsblk -b -o NAME,PARTUUID,SIZE,MODEL,PTTYPE,TYPE,PARTTYPENAME /dev/sda /dev/sdb
NAME PARTUUID SIZE MODEL PTTYPE TYPE PARTTYPENAME
sda 6001175126016 WDC WD60EFRX-68MYMN1 disk
sdb 8001563222016 ST8000VN002-2ZM188 gpt disk
└─sdb1 5e20d6d2-6b7b-49be-9e12-0ee358e0b0eb 8001560772608 gpt part Solaris /usr & Apple ZFS
admin@truenas[~]$
Yes, that is really interesting. zpool history lists an detach. But why. No one did it. I am the only one who is administering the machine and has the password. I am not sure with the date. Could have been the update.
And now here ist the error message from the replace command:
[EFAULT] Could not create a partition of 8001560772608 bytes on disk sda because the disk is too small. If you are replacing a disk in a pool, please ensure that the new disk is not smaller than the disk being replaced. Could not create partition 1 from 2048 to 15628050431 Could not change partition 1's type code to BF01! Error encountered; not saving changes.
I am sure that the mirror was not degraded when I started the TrueNAS upgrade. How to found out exactly when I had done the upgrade?
So this is interesting.
Replace does not try to create a partition of size 5995774345216 but of 8001560772608 which is the size of drive sdb. So what do you think about precreating partiton sda1 with parted?
That appears to be specific to TrueNAS. It seems that it is reading the size of the existing partition to calculate how large to create the new partition to be used as the replacement for the missing member. (I doubt they test use-cases for disks of different sizes for creating a new vdev, since that is discouraged.)
You can possibly do this manually (partitioning and zpool replace) with the command-line, but I would be more concerned that the drive might have issues, which is why it was ejected from the vdev.
It’s up to you how you want to proceed. Manually partitioning and using zpool is risky.
Is this important data?
Hallo @winnielinnie , thanks for your reply. Because data is important, i am doing a fresh backup to an external drive at the moment.
So if I remember right, i had set up this mirror by previously manually creating the partitions. But I am not sure about that. Why do you thing it is risky to do so?
Before I will look deeper into the s.m.a.r.t data of the disk and switch of the NAS and double check the cables.
So again: Why do you think it is risky to partition manually. What could happen?
Anything destructive involving the command-line that doesn’t have safeguards and checks is always a risk. Typing “b” instead “a” could wipe your data.
As long as you feel comfortable and you are sure the drive is without errors, you can manually create a GPT label on it and a single partition that takes up all the available space. You would then use this partition’s PARTUUID to manually replace the missing member with zpool replace.
Thanks again. It will take some days to do all that is needed, because there is only a few minutes each day to play around with TrueNAS. By the way: To build an mirror was not supported by the TrueNAS GUI at the time I set it up. I had to do this at CLI also.
I will tell in a few days, how this all ends up.
