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 π«
-cscript1[,script2,β¦]β run a script (or several scripts, bestie, go wild) on each vdev and shove the output in as a new column in thezpool statusoutput. for the complete details, go check the-coption ofzpool 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, seezfs_vdev_direct_write_verifyinzfs(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 thezpool detach/offline/remove/replacecommands. 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-vdevsto display vdevs in a flat hierarchy instead of nested vdev objects. - specify
--json-intto display numbers in integer format instead of strings. - specify
--json-pool-key-guidto set the pool GUID as the key for pool objects instead of pool names.
- specify
-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-Lflag. 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 (onoroff). 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 withinzio_slow_io_msmilliseconds (30000by 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 π-Td|uβ display a time stamp. specifydfor standard date format (seedate(1)). specifyufor a printed representation of the internal representation of time (seetime(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 thehead_errlogfeature 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:-eand-xare 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 intojqand watching it format itself is a whole vibe. everyvdev, everyguid, everypath, everyerror_countjust 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 π
zpool-events(8)zpool-history(8)zpool-iostat(8)zpool-list(8)zpool-resilver(8)zpool-scrub(8)zpool-wait(8)
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
- alpine 3.23: zfs-doc 2.4.4-r0 Β· CDDL-1.0
- alpine 3.24: zfs-doc 2.4.4-r0 Β· CDDL-1.0
- nixos 26.05: zfs-user 2.4.4
- nixpkgs unstable: zfs-user 2.4.4
- ubuntu resolute: zfsutils-linux 2.4.1-1ubuntu5 Β· CDDL-1.0
- ubuntu resolute: zfsutils-linux 2.4.1-1ubuntu5.1 Β· CDDL-1.0
- ubuntu stonking: zfsutils-linux 2.4.4-1ubuntu4 Β· CDDL-1.0
- π the page's license: CDDL-1.0
- Copyright (c) 2007, Sun Microsystems, Inc. All Rights Reserved
- Copyright (c) 2012, 2018 by Delphix. All rights reserved
- Copyright (c) 2012 Cyril Plisko. All Rights Reserved
- Copyright (c) 2017 Datto Inc
- Copyright (c) 2018 George Melikov. All Rights Reserved
- Copyright 2017 Nexenta Systems, Inc
- Copyright (c) 2017 Open-E, Inc. All Rights Reserved
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms