SATA SSD wear-out: Wear_Leveling_Count and Media_Wearout_Indicator declining

SATA SSDs report remaining NAND endurance through vendor-specific SMART attributes, not the standardized NVMe Percentage Used field. Samsung exposes Wear_Leveling_Count at attribute ID 177. Intel and Solidigm expose Media_Wearout_Indicator at ID 233. Some vendors use ID 173 (also labeled Wear_Leveling_Count) or ID 231 (SSD_Life_Left). All express the same concept: firmware estimating how much rated program/erase cycle budget remains.

The problem for operators: these attributes are not standardized across vendors. The same attribute ID can carry different semantics on different drives. The THRESH column is almost always zero, so smartctl will never flag these attributes as failing regardless of how low the normalized value drops. The raw value encoding is vendor-defined and frequently misleading. A fleet with mixed SSD vendors cannot be monitored with a single threshold rule.

What the normalized value means

The normalized VALUE column is normally the useful indicator. For these wear attributes it commonly starts at 100 for a new drive and counts down as program/erase cycles accumulate; always verify the vendor scale. The THRESH column is typically 0, which means smartctl’s WHEN_FAILED column will never show FAILING_NOW or In_the_past for these attributes. A drive at 2% remaining life can still report SMART overall health as PASSED. Vendors set the threshold to zero so the wear indicator never triggers the PASSED/FAILED assessment.

The wear indicator is a capacity-planning signal, not a real-time failure indicator. The drive will continue to operate past its endurance limit, but manufacturer reliability guarantees no longer apply. The transition from “endurance consumed” to “drive dead” can be abrupt, especially once the spare block pool starts running low.

For Samsung and generic attributes, the normalized value counts from 100 toward 0. For Intel, it counts from 100 toward 1 and floors at 1, meaning the indicator stops reporting additional wear even though the drive may still be accumulating it.

The rate of decline is driven by write workload and write amplification. Two identical drives with the same host write volume can show different normalized values if their workloads produce different write amplification factors. Random small writes produce higher amplification than sequential writes. A drive in a database WAL role will consume endurance faster than the same drive in a read-heavy role, even if the host write volume looks similar.

flowchart TD
    A["SATA SSD wear attribute"] --> B["Read normalized VALUE column"]
    B --> C["Ignore RAW_VALUE for wear percentage"]
    C --> D{"Identify vendor"}
    D --> E["Samsung: ID 177, counts 100 to 0"]
    D --> F["Intel: ID 233, counts 100 to 1"]
    D --> G["Generic: ID 173, counts 100 to 0"]
    E --> H["Track decline rate per week or month"]
    F --> H
    G --> H
    H --> I["Cross-ref Total_LBAs_Written vs rated TBW"]
    I --> J["Project replacement date"]

Vendor-specific attribute mapping

Samsung’s raw value for ID 177 reports the average number of program/erase cycles per block. This is useful as a diagnostic cross-check but is not a wear percentage. Intel’s raw value for ID 233 can appear alarmingly large (tens of thousands) while the normalized value remains at 100. The raw value is not directly interpretable as a wear percentage on either vendor.

One caveat: smartmontools uses a heuristic vendor database to assign attribute names to IDs. On non-Intel drives, it can apply Intel-specific labels to the wrong attribute. If you see Media_Wearout_Indicator labeled on a Samsung drive, verify the attribute ID and drive model before trusting the label. Always confirm the vendor via smartctl -i.

Common misinterpretations

Panicking at the raw value. The most common false alarm. A Media_Wearout_Indicator raw value of 95966 looks catastrophic until you realize the normalized VALUE is 100 and the raw value counts cumulative erase cycles. Samsung’s raw value for Wear_Leveling_Count can be in the thousands on a healthy drive. Always read the VALUE column.

Expecting smartctl to flag the wear attribute as failing. Because THRESH is almost always 0, the WHEN_FAILED column will always show “-”. A drive at 3% remaining life will still report SMART health as PASSED. Do not rely on WHEN_FAILED or the overall PASSED/FAILED assessment for wear monitoring. Track the normalized value trend directly.

Anomalous values and tool encoding. smartctl reads the ATA normalized VALUE as an unsigned 0-255 byte. A negative result such as -92 for byte 192 indicates signed-byte misinterpretation by another tool, not standard smartctl output. If a vendor or firmware uses an unusual scale, validate the reading with smartctl -A and the vendor tool rather than forcing it into a 0-100 rule.

Intel flooring at 1. When Intel’s Media_Wearout_Indicator reaches 1, it stops decreasing. The drive may continue to accumulate significant wear, but the indicator will not reflect it. A drive sitting at ID 233 VALUE = 1 for months is still degrading. Switch to tracking Total_LBAs_Written and Reallocated_Sector_Ct for ongoing monitoring once the indicator floors.

Consumer SSDs not exposing the attribute. Many consumer SSDs do not expose a wear indicator at all. If smartctl -A does not show any of IDs 173, 177, 231, or 233, the drive may simply not report wear. In that case, Total_LBAs_Written against rated TBW is your only runway estimation tool.

Rare non-zero THRESH. In rare cases, a Samsung drive will have a non-zero THRESH (for example, VALUE = 003, THRESH = 005, WHEN_FAILED = FAILING_NOW). When this happens, treat it as urgent: the drive firmware itself considers it failing. This is uncommon but does occur on some models.

Cross-referencing against write volume and rated TBW

The wear indicator is the vendor’s internal estimate. You can build an independent estimate from host write volume and the drive’s rated TBW from the datasheet.

# Check Total_LBAs_Written (ID 241) and identify the drive
smartctl -A /dev/sdX | grep -iE "Total_LBAs_Written"
smartctl -i /dev/sdX | grep -iE "Model|Firmware"

The calculation:

1. Read the decoded ID 241 name and use the correct unit. Total_LBAs_Written is in 512-byte sectors, but drivedb.h also maps ID 241 on some drives to Host_Writes_32MiB or Lifetime_Writes_GiB.
2. Convert the decoded unit to bytes (sectors by 512, 32MiB units by 33,554,432 bytes, GiB units by 1,073,741,824 bytes).
3. Divide by the rated TBW from the drive datasheet.
4. Multiply by 100 to get percentage endurance consumed.

This gives you host-write-based endurance consumption. The wear indicator (normalized VALUE) includes the effect of write amplification internally, so it will typically show more wear than the host-write math predicts. If the discrepancy is large, write amplification is high. Common causes: random small writes, misaligned partitions, full-drive conditions that force inefficient garbage collection, or workloads that defeat controller compression.

Runway estimation:

days_remaining = (rated_TBW - current_TBW) / daily_write_rate_TB

Apply a 20-30% safety margin because write amplification varies with workload changes and the drive datasheet TBW is a warranty figure, not a cliff edge.

Cross-check the two estimates. If the wear indicator says 20% remaining but the TBW math says 50% remaining, the drive is experiencing high write amplification. Investigate workload alignment, TRIM status, and drive fullness.

The wear-out cliff

SSD wear-out is a distinct failure pattern: the drive degrades gradually but can fail suddenly. Once the spare block pool is exhausted or the controller’s internal error correction can no longer compensate, the drive may go read-only or die completely. The transition from “slightly degraded” to “dead” can happen within hours.

This is why the wear indicator matters. It gives you lead time to replace the drive before the cliff. Signals that the cliff is approaching:

• Wear indicator normalized value in single digits (Samsung ID 177 below ~10, Intel ID 233 at 1)
• Reallocated_Sector_Ct (ID 5) starting to increase alongside the declining wear indicator
• Performance degradation from increased garbage collection overhead
• The drive approaching or exceeding its rated TBW

When the wear indicator is declining alongside rising reallocated sectors, the drive is in active wear-out. The spare block pool is being consumed as worn blocks fail. Schedule replacement immediately.

# Check for active wear-out: declining wear indicator plus rising reallocations
smartctl -A /dev/sdX | grep -iE "Wear_Leveling|Wearout|Reallocated"
# Check error log for media errors correlating with wear
smartctl -l error /dev/sdX

Signals to watch in production

Monitoring with Netdata

Netdata collects SMART attributes on each disk and trends them over time. The useful signal for wear-out is the rate of decline, not a point-in-time threshold.

• Wear indicator trending. The normalized value declines slowly over months. Trending it lets you see acceleration and project replacement dates rather than discovering the wear only when you happen to check.
• Correlation with write volume. Overlaying Total_LBAs_Written against the wear indicator reveals write amplification. If the wear indicator drops faster than the TBW math predicts, the workload is burning endurance inefficiently.
• Reallocated_Sector_Ct correlation. Rising reallocated sectors alongside a declining wear indicator is the active wear-out signal. Alerting on both signals together reduces false positives and catches real failures earlier.
• Per-vendor attribute selection. Mixed fleets need correct attribute ID mapping per drive model to avoid the smartmontools mislabeling problem.

Related guides

• How S.M.A.R.T. actually works: a mental model for operators
• SMART says PASSED but the drive is failing: why the health check lies
• Reallocated_Sector_Ct rising: the drive is burning through its spare pool
• NVMe Percentage Used at or above 100%: rated endurance consumed
• NVMe Available Spare below threshold: the spare block pool is running out
• smartctl disk monitoring checklist: the SMART signals every server needs
• SMART monitoring maturity model: from survival to expert
• Reallocated_Event_Count vs Reallocated_Sector_Ct: reading both together