Skip to main content
RunBook Academy

CephLXIX · Disk PerformanceDisk Performance

Reading device health data

Intermediate⏱ ~18 minsmartctlnvmeceph

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

Not yet marked complete on this device.

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
AttributeIDActionable value
Reallocated_Sector_Ct5any increase from baseline
Current_Pending_Sector197any non-zero
Offline_Uncorrectable198any non-zero
Reported_Uncorrect187any non-zero
Command_Timeout188rising trend
UDMA_CRC_Error_Count199rising — 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
FieldActionable value
critical_warningany non-zero
media_errorsany increase
percentage_usedabove 90
available_sparebelow available_spare_threshold
unsafe_shutdownsinformational, but a rising count suggests power issues
temperatureabove the drive’s specification
nvme smart-log /dev/nvme0n1 | grep -iE 'critical_warning|media_errors|percentage_used|available_spare'

Informational rather than actionable

AttributeWhy 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

  1. Q1. A drive shows a rising UDMA_CRC_Error_Count. What does this implicate?

  2. Q2. A non-zero reallocated sector count means a drive should be replaced immediately.

  3. 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.

  4. 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