Rocky 9: SMART detection and making smartd alerts real
Test scope
Section titled “Test scope”Executed in a Rocky 9.8 environment (privileged container, host kernel 5.14.0-687.54.1.el9_8) and on the same host: lsblk -d, smartctl --scan, smartctl -i /dev/vda, -d sat, -d nvme, systemctl is-active smartd, and the default smartd.conf. Log: plans/content-expansion/evidence/logs/rocky-disk-health.log.
The virtual disk here exposes no SMART, so the “when it works” part follows the default configuration; no output from a real SATA/NVMe disk was produced here.
Order of checks
Section titled “Order of checks”lsblk -d -o NAME,TYPEto see what kind of disk it is;smartctl --scanto see whether it enumerates;smartctl -i /dev/<disk>for model and SMART support;- if it cannot be read, move monitoring to the cloud platform, array controller or host.
What this machine shows
Section titled “What this machine shows”sudo smartctl --scansudo smartctl -i /dev/vda(no output)
/dev/vda: Unable to detect device typePlease specify device type with the -d option.Explicit types fail too:
Read Device Identity failed: Inappropriate ioctl for deviceRead NVMe Identify Controller failed: NVME_IOCTL_ADMIN_CMD: Inappropriate ioctl for deviceThe virtio disk does not pass SMART through, so no configuration on the guest can read it.
What the default smartd configuration looks like
Section titled “What the default smartd configuration looks like”grep -vE "^#|^$" /etc/smartmontools/smartd.conf | head -2systemctl is-active smartdDEVICESCAN -H -m root -M exec /usr/libexec/smartmontools/smartdnotify -n standby,10,qinactiveDEVICESCAN scans every supported disk and mails root on a failed health check. With no scannable devices it raises nothing — exactly the “we think we have monitoring” trap in virtual environments.
What to watch when SMART is unavailable
Section titled “What to watch when SMART is unavailable”dmesg -T | grep -iE "i/o error|medium error|link reset" | tail -5sudo mdadm --detail /dev/md0 2>/dev/null | grep -E "State|Faulty"- Kernel log: I/O and medium errors are the most direct hardware-layer symptom;
- Software RAID:
Stateturns degraded andFaulty Devicesnames the disk; - Hardware RAID: vendor CLI (storcli/perccli/ssacli);
- Cloud disks: console health checks and events.
Common traps
Section titled “Common traps”- Treating
-d satas a universal flag: a wrong type only yields ioctl errors; - Configuring smartd without devices: it looks like monitoring but reports nothing;
- Watching SMART only: behind a RAID controller SMART is usually swallowed.
Practice: define a monitoring plan for one host
Section titled “Practice: define a monitoring plan for one host”sudo dnf install -y smartmontools mdadmsudo smartctl --scansudo smartctl -i /dev/<disk> || echo "SMART unavailable"dmesg -T | grep -icE "i/o error|medium error"sudo mdadm --detail /dev/md0 2>/dev/null | grep StateChecks:
- You can state whether this host can read SMART
- If not, you can name where monitoring belongs
- You can list at least two substitute signals
常见问题
Why can a virtio disk not expose SMART?
SMART commands use ATA/NVMe-specific channels that virtual disks usually do not pass through; only the cloud platform or host sees physical disk state.
Is the default smartd configuration enough?
On physical hosts DEVICESCAN with -m root is a reasonable start, provided mail delivery and recipients are configured; do not rely on it in virtual environments.
How do I monitor disks behind a RAID controller?
Use the vendor CLI for array and physical disk state and enable controller event alerts; SMART is often intercepted by the controller and smartctl cannot see it.
Next steps
Section titled “Next steps”- XFS repair: Judging and repairing a damaged XFS
- LVM growth: LVM growth and XFS
- Network triage: Triage network problems by symptom