Raw_Read_Error_Rate looks enormous: the Seagate false alarm explained

You see SMART attribute ID 1 with a raw value of 200,450,784. Or 60,000,000,000. Your monitoring system pages you at 3 a.m. because “raw read error rate is enormous.” You check the drive: smartctl -H says PASSED. Reallocated sectors: zero. Pending sectors: zero. Offline uncorrectable: zero. The raw value is enormous by design.

Seagate packs error counts and total operation counts together into the 48-bit raw value field for attribute ID 1 (Raw_Read_Error_Rate). The raw value will always be large on a healthy Seagate drive because it includes every read operation the drive has ever performed, not just errors. Alerting on raw > 0 for this attribute generates constant noise for every Seagate drive in your fleet.

The fix is not to suppress the alert. Shift your alerting to the normalized VALUE column, which is the manufacturer’s own health assessment on a vendor-defined scale. Only the normalized VALUE trending toward THRESH indicates an actual problem.

What it is and why it matters

Every ATA SMART attribute has five fields in its smartctl -A output:

The normalized VALUE column is the only column that matters for failure prediction on attributes where the raw value is vendor-encoded. A drive is failing for a given attribute only when VALUE drops to or below THRESH. The raw field on Seagate drives does not represent a simple error count. It encodes multiple sub-fields packed together.

Most monitoring tools, dashboards, and alerting rules treat the raw value as a literal count. For Seagate drives, that assumption is wrong. The result is alert storms on healthy drives, followed by operators learning to ignore SMART alerts entirely.

How it works

Seagate uses a proprietary 48-bit encoding for several attributes, including ID 1 (Raw_Read_Error_Rate), ID 7 (Seek_Error_Rate), and ID 195 (ECC_On_the_Fly_Count). Instead of storing a simple error count, the raw field packs two values together:

flowchart LR
    A["48-bit Raw Field"] --> B["Upper 16 bits
Read errors"]
    A --> C["Lower 32 bits
Total sectors read"]
    C --> D["Read as single integer:
appears enormous"]
    B --> D
    D --> E["Normalized VALUE
0-253 scale"]
    E --> F["Compare to THRESH
Only meaningful signal"]

The lower 32 bits track the total number of sector reads. The upper 16 bits track the number of read errors. When smartctl displays this as a single decimal integer, the combined value is dominated by the total reads count. A healthy Seagate drive that has performed 200 million reads with zero errors shows a raw value of approximately 200,000,000.

Seagate’s firmware computes the normalized VALUE from these components using a logarithmic formula based on the ratio of total bits transferred to sectors requiring retries. When the error rate relative to total operations increases, the normalized VALUE decreases. When it drops to THRESH, the drive considers itself failing for this attribute.

smartctl does not decode vendor-specific raw encodings by default. It reports the raw value exactly as the drive firmware provides it. The smartmontools project maintains a vendor preset database (drivedb.h) that handles some known models, but the raw value still requires vendor-aware interpretation in your alerting logic.

You can display the packed value in hexadecimal for manual splitting:

# Show attributes 1 and 7 as 12-digit 48-bit hex values
smartctl -A -v 1,hex48 -v 7,hex48 /dev/sdX

For the 2011 Seagate layout, the first eight hex digits are the 32-bit total-operation count and the last four hex digits are the 16-bit error count. smartmontools does not provide a generic raw32/raw16 display format for this encoding.

The normalized VALUE is always available without any special flags and is the correct basis for monitoring.

Where it shows up in production

Fleet-wide SMART deployment. When you first deploy SMART monitoring across an existing fleet, every Seagate drive with significant power-on hours will show a large raw value for ID 1. If your alerting checks raw > 0 or raw > threshold, you get a page for every Seagate drive simultaneously.

Mixed-vendor fleets. Seagate and Western Digital encode attribute ID 1 completely differently. On WD, HGST, and Toshiba drives, a non-zero raw value for Raw_Read_Error_Rate can be a genuine warning signal. On Seagate, a raw value in the billions is normal. A single alerting rule applied across both vendors produces false positives on Seagate and may miss real issues on WD if tuned to accommodate Seagate’s scale.

Monitoring tool defaults. Nagios check scripts, Zabbix templates, and generic Prometheus SMART exporters commonly expose raw values without vendor-specific decoding. Without vendor-aware logic in your alerting rules, every Seagate drive triggers.

Scrutiny and similar tools. Tools that collect SMART data may display the raw value prominently in their UI, even when their internal failure detection logic uses the normalized value. The visual presentation causes operators to panic even when the tool itself is not alerting.

Common misuses

Alerting on raw ID 1 or raw ID 7 greater than zero on Seagate drives. The raw value includes total operations, not just errors. It will always be large.

Treating the raw value as a literal error count. On non-Seagate drives, the raw value for ID 1 may indeed be an error count. On Seagate, it is not. Applying the same interpretation across vendors is incorrect.

Disabling monitoring of ID 1 entirely. Teams burned by false alarms often disable the attribute. The normalized VALUE does carry real information. A declining normalized VALUE on any drive, including Seagate, indicates increasing read instability that may precede reallocated sectors.

Assuming all attributes use the same encoding. The same Seagate encoding trap applies to ID 7 (Seek_Error_Rate) and ID 195 (ECC_On_the_Fly_Count). These attributes also pack operation counts and error counts into the raw field. The same rule applies: monitor the normalized VALUE, not the raw value.

What to monitor instead

Stop alerting on the raw value of ID 1 and ID 7 for Seagate drives. Monitor these signals instead:

The normalized VALUE for ID 1 starts high (typically 100, 200, or 253 depending on the vendor) and stays there on a healthy drive. A slow decline over weeks or months warrants investigation. A sharp drop toward THRESH indicates active degradation. Cross-reference with reallocated sectors, pending sectors, and the error log to confirm.

How to check a specific drive

# Check overall health
smartctl -H /dev/sdX

# Check all attributes with normalized values
smartctl -A /dev/sdX

# Check error log for specific error types
smartctl -l error /dev/sdX

# Show packed values in hex for manual investigation
smartctl -A -v 1,hex48 -v 7,hex48 /dev/sdX

When reviewing the output, look at the VALUE and THRESH columns for ID 1. If VALUE is well above THRESH, the drive’s read error rate is within manufacturer spec regardless of what the raw value says. If VALUE is approaching THRESH, investigate further using the error log and reallocated sector count.

How Netdata helps

Netdata’s SMART monitoring surfaces the signals that matter for disk health:

• Normalized VALUE tracking: Netdata tracks the normalized VALUE column for SMART attributes, not just raw values, so Seagate’s packed encoding does not produce false alarms.
• Rate-of-change correlation: Netdata shows whether reallocated sectors, pending sectors, and offline uncorrectable counts are growing over time, which is the strongest predictor of active media failure.
• Multi-signal dashboards: Correlating ID 5, ID 197, and ID 198 alongside the normalized VALUE for ID 1 lets you distinguish a healthy Seagate drive (large raw, stable normalized, zero media errors) from a failing one (normalized declining, media errors growing).
• ML anomaly detection: Netdata’s anomaly detection flags unusual changes in the normalized VALUE trend, catching gradual degradation before the drive crosses its THRESH.
• Host-level I/O metrics: Correlating I/O latency with SMART data distinguishes drive-level read errors from cable or controller problems.

Related guides

• How S.M.A.R.T. actually works: a mental model for operators
• smartctl disk monitoring checklist: the SMART signals every server needs
• SMART monitoring maturity model: from survival to expert
• Reallocated_Sector_Ct rising: the drive is burning through its spare pool