When you run smartctl -a /dev/sda on a server with a hardware RAID controller, the query returns information about the controller’s virtual device, not the physical drive. Or it fails entirely. The RAID controller presents only virtual devices to the OS, so standard SMART queries never reach the physical hardware.

Without the correct controller-specific passthrough flag, you have no visibility into individual drive health. Monitoring may report success because it queried a device node and got a response, but the response contains no real drive data. Drives can fail silently while monitoring appears healthy.

The fix is the -d device type flag. LSI/Broadcom MegaRAID controllers (including Dell PERC, which are rebranded LSI) use -d megaraid,N for SAS drives and -d sat+megaraid,N for SATA drives. HP Smart Array controllers use -d cciss,N. N is the controller’s internal device ID for the physical drive, not the /dev/sdX letter or the enclosure slot number.

Prerequisites

  • smartmontools installed: smartctl version 7.0 or later recommended. Some passthrough features and bug fixes depend on recent versions.
  • Root or sudo access: SMART queries require raw device access.
  • Controller identification: Know your controller family before choosing the -d flag.
  • MegaRAID management tools: StorCLI (storcli) or legacy MegaCli to enumerate physical drive device IDs.
  • HP Smart Array: the hpsa kernel driver (modern) or legacy cciss driver loaded.

How RAID controllers mask SMART data

Hardware RAID controllers abstract physical drives into virtual devices. The OS sees /dev/sda, /dev/sdb, and so on, but these are logical volumes, not physical disks. When you send a SMART query to /dev/sda, the controller intercepts it.

The controller’s response depends on its firmware:

  • Some controllers return basic information about the virtual device with no SMART attributes at all.
  • Some return an error indicating the device does not support SMART.
  • Some return partial or cached data that does not reflect the current state of any individual physical drive.

The -d flag tells smartctl to use the controller’s management interface to address a specific physical drive directly. The controller forwards the SMART command to the target drive and relays the response back.

flowchart TD
    OS["smartctl"] --> CTRL["RAID Controller"]
    CTRL -- "/dev/sda default" --> VD["Virtual Device"]
    VD --> R1["No SMART data"]
    CTRL -- "-d megaraid,N" --> PD1["Physical SAS/SATA Drive N"]
    PD1 --> R2["SMART accessible"]
    CTRL -- "-d cciss,N" --> PD2["Physical Drive N"]
    PD2 --> R3["SMART accessible"]

Identifying your controller and drive IDs

Step 1: Identify the controller type

# Check PCI devices for RAID controllers
lspci | grep -iE "raid|sata|sas"

Look for LSI/Broadcom MegaRAID, Dell PERC, HP Smart Array, or Adaptec entries. The controller family determines which -d flag to use.

Step 2: Enumerate physical drives

For MegaRAID controllers using StorCLI:

# List all physical drives on controller 0
storcli /c0 /eall /sall show

The DID column contains the device ID. This is the N in -d megaraid,N.

For MegaRAID controllers using MegaCli:

# List all physical drives on adapter 0
MegaCli -pdlist -a0

Look for the Device Id line in the output for each drive.

For HP Smart Array controllers:

# List SCSI generic devices with controller mapping
lsscsi -g

The /dev/sgN device paired with each physical drive is the target for -d cciss,N.

Step 3: Map drive IDs to physical slots

The device ID N is assigned by the controller firmware. It may not correspond to the physical slot or bay number. Keep a mapping table of device ID to enclosure and slot for operational reference. This matters during drive replacement: you need to know which physical drive corresponds to which device ID.

Procedure

MegaRAID and Dell PERC controllers

For SAS drives behind a MegaRAID controller:

# Read full SMART data from physical drive with device ID 2
smartctl -a -d megaraid,2 /dev/sda

The /dev/sda device node serves as the communication path to the controller. The actual target drive is specified by the device ID in the -d flag. N ranges from 0 to 127.

For SATA drives behind a MegaRAID controller, you must use the sat+megaraid device type:

# SATA drives require the sat+ prefix for SAT translation
smartctl -a -d sat+megaraid,2 /dev/sda

The sat+ prefix routes the command through the SCSI-ATA Translation layer. Using -d megaraid,N alone for SATA drives typically returns no useful SMART data or fails silently. This is the most common operator mistake with MegaRAID passthrough.

HP Smart Array controllers

For HP Smart Array controllers using the legacy cciss driver:

# Access physical drive 0 through cciss device node
smartctl -a -d cciss,0 /dev/cciss/c0d0

For HP Smart Array controllers using the modern hpsa driver:

# Access physical drive 0 through SCSI generic device
smartctl -a -d cciss,0 /dev/sg2

The device node changes from /dev/cciss/c0d0 (legacy driver) to /dev/sgN (modern hpsa driver), but the -d cciss,N flag syntax remains the same.

As of smartmontools 7.3, -d cciss,N is no longer required for HP Smart Array controllers operating in HBA (non-RAID) mode. In HBA mode, smartctl can auto-detect the drives. If the controller is in RAID mode, the flag is still required.

To disable SAT auto-detection on cciss devices (added in smartmontools 7.0):

# Bypass SAT layer for cciss devices
smartctl -a -d scsi+cciss,0 /dev/sg2

Verifying it works

# Verify SMART is accessible on the target physical drive
smartctl -i -d megaraid,2 /dev/sda

Check the output for:

  • Device model, serial number, firmware version: These should identify the physical drive (for example, “ST4000NM0035”), not the RAID controller. If you see the controller name or generic virtual device info, passthrough is not working.
  • “SMART support is: Available”: Confirms the drive supports SMART.
  • “SMART support is: Enabled”: Confirms SMART monitoring is active on the drive.

Run a full attribute read to confirm data quality:

# Full SMART attribute table
smartctl -A -d megaraid,2 /dev/sda

If the attribute table is populated with real values (IDs 5, 9, 194, 197, 198, 199, and others), passthrough is working correctly. An empty or missing attribute table indicates the command reached the wrong target.

Common pitfalls

PitfallWhat it looks likeHow to fix
Using -d megaraid,N for SATA drivesReturns no SMART data or partial SCSI inquiry onlyUse -d sat+megaraid,N instead
Wrong device ID (N)SMART data from an unexpected drive, or “No such device” errorRe-enumerate with StorCLI or MegaCli; N is the DID, not the slot number
Controller in HBA/IT mode-d megaraid,N fails; drives appear as direct /dev/sdX devicesIn passthrough mode, query /dev/sdX directly without -d flags
Firmware update changed behaviorPassthrough worked before update, fails afterRe-test all drives after controller firmware upgrades; syntax can change
Stale cached SMART dataValues do not change between polls despite known drive activitySome controllers cache SMART responses; compare with direct queries during maintenance windows
smartd not using passthrough flagssmartctl works manually but smartd reports no dataAdd the -d flag to the drive entry in the smartd configuration file
Deprecated SCSI ioctl warnings in dmesgKernel messages about deprecated SCSI ioctl from smartctlUpgrade to smartmontools 7.4 or later, which defaults to SG_IO_V3

Monitoring the controller itself

The RAID controller has its own health state separate from individual drive SMART data. A failing controller, degraded cache battery (BBU/CV), or degraded array can cause data loss that per-drive SMART will never detect.

# MegaRAID controller health (StorCLI)
storcli /c0 show

# MegaRAID virtual drive and array status
storcli /c0 /vall show

# MegaRAID controller health (MegaCli)
MegaCli -AdpAllInfo -a0

Key signals to watch:

  • Controller status: Online, degraded, or failed.
  • Array state: Optimal versus degraded. A degraded array means at least one drive has failed or is rebuilding.
  • BBU/CV status: Battery-backed cache health. A failed battery forces write-through cache mode, degrading performance.
  • Patrol read / consistency check progress: Background scans that surface latent media errors.

The controller’s own event log often contains early warnings (predictive failure, link errors) before SMART attributes change. Check it regularly.

Signals to monitor

SignalWhy it mattersWarning sign
SMART accessible for every physical driveIf passthrough fails for any drive, you have a blind spotMonitored drive count less than expected physical drive count
Reallocated Sector Count (ID 5)Active media degradation consuming spare poolAny growth from baseline
Current Pending Sector (ID 197)Unreadable sectors causing I/O latency spikesAny non-zero value
Offline Uncorrectable (ID 198)Permanent data loss at sector levelAny growth from baseline
UDMA CRC Error Count (ID 199)Cable or backplane transport errorsAny growth from baseline
Drive temperatureThermal damage riskSustained operation above drive-rated maximum
Controller healthController failure can cause total data lossDegraded array, failed BBU, controller warnings in event log

How Netdata helps

  • Telemetry blind spot detection: Netdata compares the expected physical drive count against drives successfully reporting SMART data, flagging gaps where passthrough is misconfigured.
  • SMART attribute collection: When passthrough is working, Netdata collects SMART attributes at its configured interval, giving you visibility into rate-of-change rather than point-in-time snapshots.
  • Cross-signal correlation: Correlating SMART attribute changes (reallocated sectors, pending sectors) with I/O latency metrics from the host helps distinguish drive failures from controller or cable problems.
  • Controller health monitoring: Netdata surfaces RAID controller status alongside per-drive SMART data, so a degraded array or failing BBU does not go unnoticed.
  • Anomaly detection: Netdata can flag unusual patterns in SMART attribute rates, catching gradual degradation that static thresholds miss.