Reading zpool status (contains multiple spare sections)

[stor]

Hi folks,

I run a RAIDZ2 setup with 6 active 6TB drives and a single 6TB hot spare. One of the disks (ada7 / 4c392d04-x-x-x-x.eli) has begun showing S.M.A.R.T. read and spin-up errors, so I would like to replace it and resilver asap and keep the array safe.
Looking at the results of `zpool status` I don’t quite understand why there there is a section called “spare-4” and why it contains both my intended hot spare drive and another drive, when there is already a section called “spares” below that contains the correct hot spare. Could you shed some light on this?

Note: originally ADA1 was the hot spare, but after a hardware dust cleaning the SATA cables were reconnected to the drives in the pool at random, so I am not sure the ADA numbers are consistent with the original setup, which should not degrade the array, but could be misleading given the array name. The current ADA1 may not be the original intended hot spare.

Code:

zpool status

returns

Code:

  pool: RAIDZ2-6TBx6-ADA1SPARE
 state: ONLINE
  scan: scrub repaired 0B in 19:59:56 with 0 errors on Sun Oct  1 19:59:58 2023
config:

    NAME                                                  STATE     READ WRITE CKSUM
    RAIDZ2-6TBx6-ADA1SPARE                                ONLINE       0     0     0
      raidz2-0                                            ONLINE       0     0     0
        gptid/4c392d04-x-x-x-x.eli    ONLINE       0     0     0
        gptid/53742de0-x-x-x-x.eli    ONLINE       0     0     0
        gptid/5ab4c66c-x-x-x-x.eli    ONLINE       0     0     0
        gptid/625c1285-x-x-x-x.eli    ONLINE       0     0     0
        spare-4                                           ONLINE       0     0     0
          gptid/699bedc1-x-x-x-x.eli  ONLINE       0     0     0
          gptid/78775887-x-x-x-x.eli  ONLINE       0     0     0
        gptid/70da6716-x-x-x-x.eli    ONLINE       0     0     0
    spares
      gptid/78775887-x-x-x-x.eli      INUSE     currently in use

Code:

glabel status

returns (showing only devices pertinent to this RAIDZ2 array):

Code:

gptid/699bedc1-x-x-x-x     N/A  ada1p2
gptid/78775887-x-x-x-x     N/A  ada2p2
gptid/625c1285-x-x-x-x     N/A  ada3p2
gptid/5ab4c66c-x-x-x-x     N/A  ada4p2
gptid/53742de0-x-x-x-x     N/A  ada5p2
gptid/70da6716-x-x-x-x     N/A  ada6p2
gptid/4c392d04-x-x-x-x     N/A  ada7p2
gptid/698bbd3f-x-x-x-x     N/A  ada1p1

From

Code:

zpool history RAIDZ2-6TBx6-ADA1SPARE

see that the array was created from the following drives:

Code:

2019-12-08.18:06:17 zpool create -o cachefile=/data/zfs/zpool.cache -o failmode=continue -o autoexpand=on -O compression=lz4 -O aclmode=passthrough -O aclinherit=passthrough -f -m /RAIDZ2-6TBx6-ADA1SPARE -o altroot=/mnt RAIDZ2-6TBx6-ADA1SPARE 
raidz2 
/dev/gptid/4c392d04-x-x-x-x.eli 
/dev/gptid/53742de0-x-x-x-x.eli 
/dev/gptid/5ab4c66c-x-x-x-x.eli 
/dev/gptid/625c1285-x-x-x-x.eli 
/dev/gptid/699bedc1-x-x-x-x.eli 
/dev/gptid/70da6716-x-x-x-x.eli 
spare 
/dev/gptid/78775887-x-x-x-x.eli

Thank you for your help, and I apologize if my search of the forum came up short.

 

[stor]

I identified ADA1 and ADA2 and swapped the SATA cables, so now the ADA:gptid mapping is as it was at the time of pool creation. From now on ADAx numbers will refer to this, not the config in post #1.

Code:

gptid/78775887-1a28-11ea-85bd-0cc47a86a2ba     N/A  ada1p2
gptid/699bedc1-1a28-11ea-85bd-0cc47a86a2ba     N/A  ada2p2
gptid/625c1285-1a28-11ea-85bd-0cc47a86a2ba     N/A  ada3p2
gptid/5ab4c66c-1a28-11ea-85bd-0cc47a86a2ba     N/A  ada4p2
gptid/53742de0-1a28-11ea-85bd-0cc47a86a2ba     N/A  ada5p2
gptid/70da6716-1a28-11ea-85bd-0cc47a86a2ba     N/A  ada6p2
gptid/4c392d04-1a28-11ea-85bd-0cc47a86a2ba     N/A  ada7p2
gptid/7869ed90-1a28-11ea-85bd-0cc47a86a2ba     N/A  ada1p1

However, there are no changes to `zpool status` output.

What throws me off is the INUSE status of the hot spare 78775887 in the `spares` section, and its presence in the `spare-4` section. Would the presence of the `spares-4` section indicate that ADA1/78775887/was once, presumably automatically, added as a spare for a failing ADA2, gptid/699bedc1?

 

[stor]

Solved https://github.com/openzfs/zfs/discussions/12910

It looks like `spare-4` was indeed created when my spare drive 78775887 was added as a spare for 699bedc1 for some reason.
The spare drive is now detached and status is AVAILABLE.