# NVMe Percentage Used: SSD endurance and the metric boundary

What NVMe Percentage Used means, why 100 does not imply immediate failure, and how to interpret endurance estimates with an SSD history.

Author: Retrivium team
Updated: 2026-11-01
Canonical URL: https://retrivium.ai/journal/nvme-percentage-used/
Language: en

## Read the metric definition

Percentage Used is often incorrectly presented as a universal SSD health scale. The [libnvme SMART structure reference](https://github.com/linux-nvme/libnvme/blob/master/doc/rst/types.rst) defines it as a vendor specific estimate of consumed NVM endurance based on actual use. A value of 100 means estimated endurance has been consumed, but may not indicate failure; values above 100 are allowed. It is neither filesystem fullness nor the probability of data loss during the next hour. A colored application indicator should therefore not replace the definition. Preserve the exact field name, value, model and firmware so it cannot later be confused with another drive percentage.

## Establish the observation scope

The [nvme-cli SMART log documentation](https://github.com/linux-nvme/nvme-cli/blob/master/Documentation/nvme-log-smart.txt) describes log retrieval and notes that namespace requests depend on device capabilities. Before comparing observations, record controller, namespace scope, serial number and tool release. An operating system device path can change, so it is insufficient for a long term history. Preserve the original response and read errors. An unavailable field must not become zero and appear to describe an unworn drive. Do not sum or average values across namespaces without first establishing whether they refer to a shared controller resource or independently accounted areas in the supported configuration.

## Track trends without false precision

Observe estimate changes across successive snapshots and correlate them with workload. Device update rules govern the field, so frequent polling does not turn it into a continuous endurance sensor. A short test may show identical values before and after despite real writes. Preserve window duration, host write volume and workload changes for analysis. Extrapolating remaining life linearly from a short interval is risky: future write patterns and internal estimates may differ. A sound report shows the observed rate of change over a specified window and separates that observation from a forecast requiring additional assumptions about future operation.

## Investigate values around 100

If the estimate reaches or exceeds 100, examine manufacturer guidance, critical warnings, media errors and available spare capacity next. No current errors does not undo consumption of estimated endurance. Equally, immediately declaring the drive failed is incorrect. Decisions about its role should reflect data requirements, recovery needs and manufacturer recommendations. A model cache and the only copy of important state have different failure consequences despite an identical metric. The diagnostic record should explain the chosen action and supporting observations rather than presenting one threshold as a universal replacement policy for every SSD and server role.

## Preserve an operating record

The record contains SSD identity, firmware, SMART scope, Percentage Used history, additional warnings and workload changes. See [NVMe for model serving](/journal/nvme-for-model-serving/) and [GPU infrastructure lifecycle](/journal/gpu-asset-lifecycle/). Comparing drives requires consistent metric meanings and operating conditions; one number does not establish an objective reliability ranking across vendors. Limit the conclusion to the reported estimate and confirmed symptoms. This supports maintenance planning without inventing a failure date or turning a telemetry field into a guaranteed remaining lifespan. When data is incomplete, preserve the uncertainty instead of manufacturing precision in a polished health chart.