CephLXIX · Disk PerformanceDisk Performance
Reading device health data
What you'll learn
- Read SMART and NVMe health output
- Identify the attributes that predict failure
- Distinguish informational from actionable values
- Automate the collection
Prerequisites
None — start here.
Verified against Ceph Tentacle 20.2.x · Ceph Squid 19.2.x (supported previous) · cephadm matches the verified Ceph release · podman 4.x · csi-rbd and csi-cephfs current · RBD / CephFS / RGW current (matches Ceph release) · Linux kernel 5.15+ (5.10 minimum) · Ubuntu 24.04 LTS (Ceph host baseline) · Debian 12 (Bookworm) (Ceph host baseline) · Rocky Linux / RHEL / AlmaLinux 9.x (Ceph host baseline) · Proxmox VE 9.x (cross-course integration) · Kubernetes 1.31+ (cross-course integration) · 2026-08-18
Why this matters in production
SMART output is long and most of it is noise. A handful of attributes predict failure and the rest are informational, and knowing which is which is what makes the data usable.
The attributes that matter — HDD
smartctl -a /dev/sdX
| Attribute | ID | Actionable value |
|---|---|---|
| Reallocated_Sector_Ct | 5 | any increase from baseline |
| Current_Pending_Sector | 197 | any non-zero |
| Offline_Uncorrectable | 198 | any non-zero |
| Reported_Uncorrect | 187 | any non-zero |
| Command_Timeout | 188 | rising trend |
| UDMA_CRC_Error_Count | 199 | rising — cable or controller, not the disk |
smartctl -A /dev/sdX | awk '$1 ~ /^(5|187|188|197|198|199)$/ {print $1, $2, $10}'
Current_Pending_Sector is the most directly actionable: it is a block
the drive cannot read now, so the read error it will produce is already
determined.
The attributes that matter — NVMe
nvme smart-log /dev/nvme0n1
| Field | Actionable value |
|---|---|
critical_warning | any non-zero |
media_errors | any increase |
percentage_used | above 90 |
available_spare | below available_spare_threshold |
unsafe_shutdowns | informational, but a rising count suggests power issues |
temperature | above the drive’s specification |
nvme smart-log /dev/nvme0n1 | grep -iE 'critical_warning|media_errors|percentage_used|available_spare'
Informational rather than actionable
| Attribute | Why not actionable |
|---|---|
| Raw_Read_Error_Rate (1) | vendor-encoded; large raw values are normal on some drives |
| Seek_Error_Rate (7) | same |
| Power_On_Hours (9) | useful context, not a failure predictor |
| Temperature (194) | actionable only against the specification |
| Load_Cycle_Count (193) | relevant on laptop drives, rarely in servers |
Alerting on attribute 1 produces constant false positives on Seagate drives, whose raw value encodes several fields.
Ceph’s own collection
DEVICE_ID=12
ceph config set mgr mgr/devicehealth/enable_monitoring true
ceph device ls
ceph device get-health-metrics ${DEVICE_ID}
ceph device predict-life-expectancy ${DEVICE_ID}
ceph health detail | grep -i DEVICE_HEALTH
This collects SMART daily across the cluster and stores it, which is more
useful than running smartctl by hand because it gives a trend rather
than a point reading.
DEVICE_ID=12
ceph device get-health-metrics ${DEVICE_ID} | python3 -c '
import sys,json; d=json.load(sys.stdin)
for ts, rec in sorted(d.items()):
a = rec.get("ata_smart_attributes",{}).get("table",[])
p = [x["raw"]["value"] for x in a if x["id"]==197]
print(ts, "pending:", p)'
Quiz
Knowledge check · 4 questions
Q1. A drive shows a rising UDMA_CRC_Error_Count. What does this implicate?
Q2. A non-zero reallocated sector count means a drive should be replaced immediately.
Q3. Set up device health alerting.
A 200-OSD cluster runs smartctl manually when a problem is suspected. There is no baseline, no trend data, and no alerting.
Q4. Why is Current_Pending_Sector the most directly actionable SMART attribute?
Passing score: 75%. Answers are checked in this browser.
Production discipline
Record a per-device SMART baseline at deployment and alert on any
increase rather than on absolute thresholds; drives differ enough that
fixed thresholds are both noisy and insensitive. Recognise
UDMA_CRC_Error_Count as a link fault — replacing the drive leaves the
cable or HBA in place.
Cross-course references
- Kubernetes: node problem detector distinguishes signal attributes the same way
- Linux: smartd configuration faces the identical signal-versus-noise problem