Spare VDEV issue - GUI shows unavailable, CLI shows available

[Jorsher]

TrueNAS SCALE GUI -> Storage -> Devices
Shows the spare as a number instead of sd* like the others and "Unavailable" without an option to detach/offline.

CLI -> zpool status pool
Shows the spare as sda2 instead of the disk ID like the others and "Available"

I would like to make sure the pool will use it in the event of a disk failure, without triggering a rebuild. Is there any way to do this?

I forget how I got here since troubleshooting was interrupted by a long vacation. A disk faulted, started rebuilding with the spare, and I believe the spare faulted as well. I tried reboots and different drives, etc, but the spare has never displayed "normally." What are some things I can try?

 

[Arwen]

The output of the following command in CODE tags would be helpful;
zpool status

 

[Jorsher]

Sure,

Code:

 state: ONLINE
  scan: scrub in progress since Thu Nov 30 12:17:12 2023
        82.0T / 174T scanned at 3.52G/s, 56.2T / 174T issued at 2.41G/s
        0B repaired, 32.34% done, 13:51:27 to go
config:

        NAME                                      STATE     READ WRITE CKSUM
        games                                     ONLINE       0     0     0
          raidz1-0                                ONLINE       0     0     0
            3b72bb44-b4dc-47da-ac5a-8146dd25fa1d  ONLINE       0     0     0
            357620ad-6760-44d6-9e37-a81c8fe5e04f  ONLINE       0     0     0
            c2702da7-9f28-4cd6-9bf9-5af48d33c03d  ONLINE       0     0     0
            e5779db5-c6d1-4fd6-801b-cf88a82acde4  ONLINE       0     0     0
            b6aec7da-3a49-489a-aaed-d92c3dc75a5a  ONLINE       0     0     0
            d42d1497-7d96-400e-965c-04e9ef92651a  ONLINE       0     0     0
          raidz1-1                                ONLINE       0     0     0
            10c94e50-8b2b-4480-82f7-93a7cb0636f5  ONLINE       0     0     0
            d5ca3e18-c857-4cf5-9ca5-b0a3e09780a9  ONLINE       0     0     0
            19bde2af-ef0b-4b1a-9e61-4e8af555577e  ONLINE       0     0     0
            b8c8bcdf-1913-4213-ad4e-2c33156c80c9  ONLINE       0     0     0
            1c55438f-25d6-4fd9-8a34-8745f45c5fbe  ONLINE       0     0     0
            2b92009e-876a-46d8-84fc-229868515c0f  ONLINE       0     0     0
          raidz1-2                                ONLINE       0     0     0
            30ae854e-5bd8-4f43-94f5-049547079c75  ONLINE       0     0     0
            c9c0a339-6c1c-4170-adbc-81c4ab47a0c0  ONLINE       0     0     0
            307bb75c-79be-43d9-98ee-bb5d89e7deac  ONLINE       0     0     0
            e8cfaf4d-a1b6-4343-81ec-eebf16ebe115  ONLINE       0     0     0
            fef8882a-08d5-4964-92e1-6e5aee591306  ONLINE       0     0     0
            7198ea33-0bcd-4d00-b6ef-f4868ab90622  ONLINE       0     0     0
          raidz1-3                                ONLINE       0     0     0
            807c35d8-76d4-4081-a052-2620631692fa  ONLINE       0     0     0
            20ab7ad8-cb6a-4667-96fb-b4abd19a4dc0  ONLINE       0     0     0
            e235a096-db88-44a0-b161-2e8c932efd7e  ONLINE       0     0     0
            61ff5b16-6161-4d93-8b5a-5522911d103c  ONLINE       0     0     0
            3d72a7d9-fb5b-4d2b-bfd6-3c729f75558a  ONLINE       0     0     0
            bb130a9d-9437-4c79-9ca2-9777b1a4a0be  ONLINE       0     0     0
        spares
          sda2                                    AVAIL

 

[Arwen]

Hmm, looks like no real problem. However, it does appear to be a reporting problem in the GUI.

I can't help with that. Perhaps someone else can follow up.

 

[Jorsher]

Thanks for taking a look. It's still unusual that the disk is "sda2" in the pool status. The other three pools display the spare with the disk ID like the others. I wonder if I can remove the spare vdev and add it back to start fresh.

 

[Arwen]

Sure, you can remove the hot spare and re-add it. Seems like a good idea to see if the reporting is broke, or just an odd state that will be fixed with the remove / add.

 

[Patrick M. Hausen]

That's most probably exactly the problem. Middleware and UI don't like it at all if disks are configured by anything but UUID.

 

[ABain]

The UI bug has previously been reported and a fix is planned in 23.10.1.

 

[Jorsher]

That's most probably exactly the problem. Middleware and UI don't like it at all if disks are configured by anything but UUID.

Strange thing is I didn't configure it this way. Pool and vdevs were created from gui like all others, just seems to have forgotten at some point. It was fine prior to the disk fault and spare being used. Will play with it some more and look for the bug report.

 

[Jorsher]

Another spare randomly started displaying this way after a reboot. Not really sure why, but have them at least displaying properly now until the fix is implemented:

1. zfs pool remove sdd2
2. go back and assign the unassigned disk as a spare for the pool

Now to figure out why the GUI is showing mixed capacity devs when they are all the same model disks...

lsblk showed in one of the pools that for some reason one of the drives was partitioned incorrectly. I added it just like I added all the others in that pool, so no clue how that happened, but a detach and then extend fixed it...

Second though... I replaced 1tb drives with these, one at a time, letting it rebuild each drive swap. I guess it sized it like the drive it replaced since they're mirrors?

 

[Patrick M. Hausen]

I guess it sized it like the drive it replaced since they're mirrors?

Not quite if you changed the global "swap size" setting in between.

 

[Etorix]

Second though... I replaced 1tb drives with these, one at a time, letting it rebuild each drive swap. I guess it sized it like the drive it replaced since they're mirrors?

Well, you have (current) sdf which is a 2 TB drive with a 1 TB partition first followed by a 2 GB swap partition, so you're another victim of the middleware creating partitions in the wrong order and this drive has effectivly been castrated to 1 TB, meaning you do have heterogenous vdevs.

 

[Jorsher]

Not quite if you changed the global "swap size" setting in between.

Nah, definitely not. It's 2GB like every other drive.

Well, you have (current) sdf which is a 2 TB drive with a 1 TB partition first followed by a 2 GB swap partition, so you're another victim of the middleware creating partitions in the wrong order and this drive has effectivly been castrated to 1 TB, meaning you do have heterogenous vdevs.

Put the 2GB swap at the same 'location' as the drive it replaced, and afterwards filled the space from the start of the disk to the swap partition?

I detached the drive, physically removed and re-slotted, from GUI click the lonely non-mirrored drive, chose Extend, and selected the drive I detached. Resilvered in a few minutes and now I magically have 600gb more usable capacity in that pool. Heh.