ZPOOL-STATUS(8)

πŸ’– zpool-status πŸ’–

okay bestie, welcome to the ZPOOL-STATUS(8) glow-up ✨ this is the System Manager's Manual page for zpool status, and it's genuinely one of the most important commands in your whole ZFS life. it's giving "pool doctor", it's giving "am i okay? check", and we're gonna go through every single flag together. no skipping. periodt. πŸ©ΊπŸ’…


🌸 NAME 🌸

zpool-status β€” show detailed health status for ZFS storage pools 🫢


πŸŽ€ SYNOPSIS πŸŽ€

zpool status [-DdegiLPpstvx] [-c script1[,script2,…]] [-j|--json
      [--json-flat-vdevs] [--json-int] [--json-pool-key-guid]] [-T d|u]
      [--power] [pool] [interval [count]]

πŸ¦‹ DESCRIPTION πŸ¦‹

so basically: this command shows you the detailed health status of the pools you name. don't name a pool? then it just shows you the status of every pool on the system, because it loves you and wants you informed πŸ’–

if you wanna go deeper on pool health and device health, go read the "Device Failure and Recovery" section of zpoolconcepts(7). it's the loredump, iykyk πŸ“š

if a scrub or a resilver is currently running, this command tells you the percentage done and an estimated time to completion. now listen β€” both of those are only approximate, because the amount of data in the pool and the other workloads on the system can change out from under you. so don't come for the estimate when it moves. it's doing its best 🫠

  • -c script1[,script2,…] β€” run a script (or several scripts, bestie, go wild) on each vdev and shove the output in as a new column in the zpool status output. for the complete details, go check the -c option of zpool iostat. it's the same deal, no cap.
  • -D β€” show a histogram of deduplication statistics, showing the allocated (physically present on disk) and referenced (logically referenced in the pool) block counts and sizes, sorted by reference count. and if you repeat it, like -DD, it also shows you stats on how much of the DDT is resident in the ARC. double the D, double the drama πŸ’…
  • -d β€” show the number of Direct I/O read/write checksum verify errors that have happened on a top-level VDEV. for the deets on what conditions can cause Direct I/O write checksum verify failures, see zfs_vdev_direct_write_verify in zfs(4). Direct I/O read checksum verify errors can also happen if the contents of the buffer are being manipulated after the I/O has been issued and is in flight. and in the case of Direct I/O read checksum verify errors, the I/O will be reissued through the ARC. so it's not just lost, it gets a second chance 🌈
  • -e β€” only show the unhealthy vdevs. that means not-ONLINE, or ones with errors. the "we need to talk" filter 😭
  • -g β€” display vdev GUIDs instead of the normal device names. these GUIDs can be used in place of device names for the zpool detach / offline / remove / replace commands. so yes bestie, you can absolutely address your disk by its government name πŸͺͺ
  • -i β€” display vdev initialization status.
  • -j, --json [--json-flat-vdevs] [--json-int] [--json-pool-key-guid] β€” display the status for ZFS pools in JSON format 🧚
    • specify --json-flat-vdevs to display vdevs in a flat hierarchy instead of nested vdev objects.
    • specify --json-int to display numbers in integer format instead of strings.
    • specify --json-pool-key-guid to set the pool GUID as the key for pool objects instead of pool names.
  • -L β€” display real paths for vdevs, resolving all symbolic links. this is how you look up the current block device name regardless of the /dev/disk/ path that was used to open it. lowkey the sleuthing flag πŸ”
  • -P β€” display full paths for vdevs instead of only the last component of the path. this one plays so nice in conjunction with the -L flag. they're a duo 🫢
  • -p β€” display numbers in parsable (exact) values. no rounding, no vibes, just the truth.
  • --power β€” display vdev enclosure slot power status (on or off). yes bestie, you can check if the slot is literally powered ⚑
  • -s β€” display the number of leaf vdev slow I/O operations. this is the number of I/O operations that didn't complete within zio_slow_io_ms milliseconds (30000 by default). heads up: this does not necessarily mean the I/O operations failed to complete β€” it just means they took an unreasonably long amount of time. and that can be a lil hint of a problem with the underlying storage πŸ‘€
  • -T d|u β€” display a time stamp. specify d for standard date format (see date(1)). specify u for a printed representation of the internal representation of time (see time(1)). pick your era πŸ•°οΈ
  • -t β€” display vdev TRIM status.
  • -v β€” displays verbose data error information, printing out a complete list of all data errors since the last complete pool scrub. and if the head_errlog feature is enabled and files containing errors have been removed, then the respective filenames will not be reported in subsequent runs of this command. so don't be surprised when the ghost files stop haunting the list πŸ’€
  • -x β€” only display status for pools that are exhibiting errors or are otherwise unavailable. and warnings about pools not using the latest on-disk format will not be included. this is the "just show me the problem children" mode πŸ™ˆ
bestie reminder: -e and -x are not the same thing, and neither one is "hide my problems". they're both filters, and they both have opinions. read the bullets again if you need to, no shame πŸ’–

✨ EXAMPLES ✨

bestie these are the real ones, the ones you actually screenshot and send to the group chat πŸ’…


πŸŽ€ Example 1: Adding output columns πŸŽ€

okay so you know how zpool status and zpool iostat give you the standard lil table and you're like "cool but what ARE these disks"? πŸ₯Ί well, you can add extra columns with -c. that's it. that's the whole trick. additional columns get added to the zpool status and zpool iostat output with -c. iconic.

# zpool status -c vendor,model,size
   NAME     STATE  READ WRITE CKSUM vendor  model        size
   tank     ONLINE 0    0     0
   mirror-0 ONLINE 0    0     0
   U1       ONLINE 0    0     0     SEAGATE ST8000NM0075 7.3T
   U10      ONLINE 0    0     0     SEAGATE ST8000NM0075 7.3T
   U11      ONLINE 0    0     0     SEAGATE ST8000NM0075 7.3T
   U12      ONLINE 0    0     0     SEAGATE ST8000NM0075 7.3T
   U13      ONLINE 0    0     0     SEAGATE ST8000NM0075 7.3T
   U14      ONLINE 0    0     0     SEAGATE ST8000NM0075 7.3T

look at her 😭 all the vendors and models just there. and yes zpool iostat does it too, she's not about to be left out:

# zpool iostat -vc size
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write  size
----------  -----  -----  -----  -----  -----  -----  ----
rpool       14.6G  54.9G      4     55   250K  2.69M
  sda1      14.6G  54.9G      4     55   250K  2.69M   70G
----------  -----  -----  -----  -----  -----  -----  ----

same flag, same energy, different command. we love consistency 🫢


πŸ’– Example 2: Display the status output in JSON format πŸ’–

now THIS is the main character moment. zpool status can output in JSON format if -j is specified β€” machine-readable, scriptable, absolutely gorgeous 🧚 and plot twist: you can also use -c to run a script on each VDEV. yes really. both at once.

# zpool status -j -c vendor,model,size | jq
{
  "output_version": {
    "command": "zpool status",
    "vers_major": 0,
    "vers_minor": 1
  },
  "pools": {
    "tank": {
      "name": "tank",
      "state": "ONLINE",
      "guid": "3920273586464696295",
      "txg": "16597",
      "spa_version": "5000",
      "zpl_version": "5",
      "status": "OK",
      "vdevs": {
        "tank": {
          "name": "tank",
          "alloc_space": "62.6G",
          "total_space": "15.0T",
          "def_space": "11.3T",
          "read_errors": "0",
          "write_errors": "0",
          "checksum_errors": "0",
          "vdevs": {
            "raidz1-0": {
              "name": "raidz1-0",
              "vdev_type": "raidz",
              "guid": "763132626387621737",
              "state": "HEALTHY",
              "alloc_space": "62.5G",
              "total_space": "10.9T",
              "def_space": "7.26T",
              "rep_dev_size": "10.9T",
              "read_errors": "0",
              "write_errors": "0",
              "checksum_errors": "0",
              "vdevs": {
                "ca1eb824-c371-491d-ac13-37637e35c683": {
                  "name": "ca1eb824-c371-491d-ac13-37637e35c683",
                  "vdev_type": "disk",
                  "guid": "12841765308123764671",
                  "path": "/dev/disk/by-partuuid/ca1eb824-c371-491d-ac13-37637e35c683",
                  "state": "HEALTHY",
                  "rep_dev_size": "3.64T",
                  "phys_space": "3.64T",
                  "read_errors": "0",
                  "write_errors": "0",
                  "checksum_errors": "0",
                  "vendor": "ATA",
                  "model": "WDC WD40EFZX-68AWUN0",
                  "size": "3.6T"
                },
                "97cd98fb-8fb8-4ac4-bc84-bd8950a7ace7": {
                  "name": "97cd98fb-8fb8-4ac4-bc84-bd8950a7ace7",
                  "vdev_type": "disk",
                  "guid": "1527839927278881561",
                  "path": "/dev/disk/by-partuuid/97cd98fb-8fb8-4ac4-bc84-bd8950a7ace7",
                  "state": "HEALTHY",
                  "rep_dev_size": "3.64T",
                  "phys_space": "3.64T",
                  "read_errors": "0",
                  "write_errors": "0",
                  "checksum_errors": "0",
                  "vendor": "ATA",
                  "model": "WDC WD40EFZX-68AWUN0",
                  "size": "3.6T"
                },
                "e9ddba5f-f948-4734-a472-cb8aa5f0ff65": {
                  "name": "e9ddba5f-f948-4734-a472-cb8aa5f0ff65",
                  "vdev_type": "disk",
                  "guid": "6982750226085199860",
                  "path": "/dev/disk/by-partuuid/e9ddba5f-f948-4734-a472-cb8aa5f0ff65",
                  "state": "HEALTHY",
                  "rep_dev_size": "3.64T",
                  "phys_space": "3.64T",
                  "read_errors": "0",
                  "write_errors": "0",
                  "checksum_errors": "0",
                  "vendor": "ATA",
                  "model": "WDC WD40EFZX-68AWUN0",
                  "size": "3.6T"
                }
              }
            }
          }
        }
      },
      "dedup": {
        "mirror-2": {
          "name": "mirror-2",
          "vdev_type": "mirror",
          "guid": "2227766268377771003",
          "state": "HEALTHY",
          "alloc_space": "89.1M",
          "total_space": "3.62T",
          "def_space": "3.62T",
          "rep_dev_size": "3.62T",
          "read_errors": "0",
          "write_errors": "0",
          "checksum_errors": "0",
          "vdevs": {
            "db017360-d8e9-4163-961b-144ca75293a3": {
              "name": "db017360-d8e9-4163-961b-144ca75293a3",
              "vdev_type": "disk",
              "guid": "17880913061695450307",
              "path": "/dev/disk/by-partuuid/db017360-d8e9-4163-961b-144ca75293a3",
              "state": "HEALTHY",
              "rep_dev_size": "3.63T",
              "phys_space": "3.64T",
              "read_errors": "0",
              "write_errors": "0",
              "checksum_errors": "0",
              "vendor": "ATA",
              "model": "WDC WD40EFZX-68AWUN0",
              "size": "3.6T"
            },
            "952c3baf-b08a-4a8c-b7fa-33a07af5fe6f": {
              "name": "952c3baf-b08a-4a8c-b7fa-33a07af5fe6f",
              "vdev_type": "disk",
              "guid": "10276374011610020557",
              "path": "/dev/disk/by-partuuid/952c3baf-b08a-4a8c-b7fa-33a07af5fe6f",
              "state": "HEALTHY",
              "rep_dev_size": "3.63T",
              "phys_space": "3.64T",
              "read_errors": "0",
              "write_errors": "0",
              "checksum_errors": "0",
              "vendor": "ATA",
              "model": "WDC WD40EFZX-68AWUN0",
              "size": "3.6T"
            }
          }
        }
      },
      "special": {
        "25d418f8-92bd-4327-b59f-7ef5d5f50d81": {
          "name": "25d418f8-92bd-4327-b59f-7ef5d5f50d81",
          "vdev_type": "disk",
          "guid": "3935742873387713123",
          "path": "/dev/disk/by-partuuid/25d418f8-92bd-4327-b59f-7ef5d5f50d81",
          "state": "HEALTHY",
          "alloc_space": "37.4M",
          "total_space": "444G",
          "def_space": "444G",
          "rep_dev_size": "444G",
          "phys_space": "447G",
          "read_errors": "0",
          "write_errors": "0",
          "checksum_errors": "0",
          "vendor": "ATA",
          "model": "Micron_5300_MTFDDAK480TDS",
          "size": "447.1G"
        }
      },
      "error_count": "0"
    }
  }
}
ngl piping that straight into jq and watching it format itself is a whole vibe. every vdev, every guid, every path, every error_count just sitting there ready for your script to devour πŸ˜ŒπŸ“

🌈 SEE ALSO 🌈

go read these next bestie, they're the rest of the family and they all ate πŸ’œ


and that's the whole page, bestie πŸŽ€βœ¨ this one came from OpenZFS, dated May 20, 2025, and its proper lil name is ZPOOL-STATUS(8). go check your pool status. she's probably fine. she's probably slaying. πŸ’…πŸ‘‘πŸ¦‹

πŸ“¦ where this page comes from