When smartctl -A /dev/nvme0n1 reports Available Spare below the Available Spare Threshold, the drive’s internal spare block pool is running low. The controller is reporting less reserved NAND capacity than it considers safe for continued reliable operation.

Available Spare is the percentage of reserved NAND blocks remaining for replacing worn or failed blocks. It starts at 100% and decreases monotonically as the drive consumes spares. When it reaches 0%, the next bad block causes permanent data loss for that block’s data: the drive has no spare to remap to.

Alerting logic:

  • Below vendor-set threshold: TICKET. Plan replacement urgently.
  • 0% with corroborating signals (Media and Data Integrity Errors rising, Critical Warning bit 3 active, or SMART Overall Health FAILED): PAGE. The drive is in active failure. A drive may sit at 0% spare and still function, but the next bad block starts data loss.

What this means

NVMe drives reserve a portion of their total NAND capacity as spare blocks. When a NAND block fails or wears out, the controller retires it and maps a spare block in its place. This remapping is transparent to the host OS. Available Spare reports what percentage of that reserve remains.

Key properties:

  • Monotonically decreasing. Available Spare never goes back up. Spares consumed are consumed permanently. A secure erase resets the FTL mapping table but does not bring retired NAND blocks back into the spare pool.
  • Independent of Percentage Used. A drive can report 50% Percentage Used but only 5% Available Spare if bad blocks consumed the spare pool faster than normal wear would predict. Do not assume that moderate Percentage Used means Available Spare is fine.
  • Vendor-set threshold varies widely. The Available Spare Threshold is set by the manufacturer and is not standardized at 10%. Always read the actual threshold value for your specific drive.

The degradation curve is cliff-edged. The drive operates normally while spares are available. When the last spare is consumed, the next defect becomes an uncorrectable read or write error. There is no graceful degradation: the transition from functional to data loss can happen quickly.

When Available Spare drops below the threshold, the NVMe controller sets bit 0 (0x01) of the Critical Warning byte. This is the hardware-level signal that the drive itself considers its spare situation critical.

flowchart TD
    A["Available Spare below threshold"] --> B{"Spare at 0%?"}
    B -->|No| C["TICKET: plan replacement"]
    B -->|Yes| D{"Media Errors rising?"}
    D -->|Yes| E["PAGE: active data loss"]
    D -->|No| F{"Read-only bit 3 set?"}
    F -->|Yes| E
    F -->|No| G{"Overall health FAILED?"}
    G -->|Yes| E
    G -->|No| C

Common causes

CauseWhat it looks likeFirst thing to check
Normal NAND endurance exhaustionPercentage Used approaching or above 100%, Data Units Written approaching rated TBW, Available Spare declining graduallyCompare Data Units Written against the drive datasheet rated TBW
Defective NAND consuming spares faster than wearPercentage Used moderate (30-60%) but Available Spare already low, no corresponding high write volumeCheck Media and Data Integrity Errors count for growth
High write amplificationPercentage Used climbing faster than expected from host writes, Available Spare declining rapidlyInvestigate workload pattern: small random writes, TRIM not enabled, drive near full
Manufacturing defect on a new driveAvailable Spare below 100% or below threshold from first observation, low power-on hoursCheck whether the value was below 100% at deployment baseline

Quick checks

# Read Available Spare and threshold together
smartctl -A /dev/nvme0n1 | grep "Available Spare"

# Check Critical Warning byte (bit 0 = spare below threshold, bit 3 = read-only)
smartctl -A /dev/nvme0n1 | grep "Critical Warning"

# Check Media and Data Integrity Errors
smartctl -A /dev/nvme0n1 | grep "Media and Data Integrity Errors"

# Check Percentage Used (endurance consumed)
smartctl -A /dev/nvme0n1 | grep "Percentage Used"

# Check Data Units Written (host write volume)
smartctl -A /dev/nvme0n1 | grep "Data Units Written"

# Check overall health assessment
smartctl -H /dev/nvme0n1

# Check kernel logs for I/O errors or read-only transitions
dmesg | grep -iE "nvme|I/O error|read-only" | tail -20

If your NVMe drive is behind a USB-to-NVMe bridge, you may need bridge-specific device types to read the SMART/Health log:

# JMicron, ASMedia, or Realtek USB-to-NVMe bridges
smartctl -d sntjmicron -A /dev/sdX | grep "Available Spare"
smartctl -d sntasmedia -A /dev/sdX | grep "Available Spare"
smartctl -d sntrealtek -A /dev/sdX | grep "Available Spare"

The nvme-cli tool provides the same fields with slightly different names. Note it targets the controller device, not the namespace:

nvme smart-log /dev/nvme0 | grep -iE "available_spare|percentage_used"

How to diagnose it

  1. Confirm the Available Spare value and the threshold. Read both values from smartctl -A. If Available Spare is 8% and the threshold is 10%, the drive is below threshold but not at zero. If Available Spare is 8% and the threshold is 50% , the situation is far more urgent than the raw percentage suggests.

  2. Check the Critical Warning byte. If bit 0 (0x01) is set, the controller is confirming the spare situation is critical. If bit 3 (0x08) is also set, the drive has gone read-only. If bit 2 (0x04) is set, the controller considers NVM subsystem reliability degraded.

  3. Check Media and Data Integrity Errors. If this counter is increasing alongside declining Available Spare, the drive is actively losing blocks and encountering data errors simultaneously. This confirms active failure, not just aged capacity.

  4. Compare Available Spare against Percentage Used. If Percentage Used is 60% but Available Spare is 3%, the spare pool is being consumed much faster than normal wear predicts. This points to defective NAND or high write amplification rather than simple endurance exhaustion.

  5. Calculate actual endurance consumed from Data Units Written. Each NVMe Data Units Written unit equals 512,000 bytes (1000 x 512). Multiply the reported value by 512,000 to get total bytes written, then compare against the drive datasheet’s rated TBW. If you have consumed only 40% of rated TBW but Available Spare is critically low, the drive is failing prematurely.

  6. Check kernel logs for I/O errors or read-only transitions. A drive at 0% spare that starts producing write errors or goes read-only is in terminal failure. Evacuate data immediately.

  7. Estimate runway. Track Available Spare over time to project when it will reach 0%: (Current Available Spare) / (Rate of decline per week) = weeks remaining. This requires at least two data points separated by enough time to measure the trend reliably.

Metrics and signals to monitor

SignalWhy it mattersWarning sign
Available SpareDirect measure of remaining spare NAND capacity. The primary health indicator for spare pool status.Below vendor threshold, or rate of decline accelerating
Available Spare ThresholdVendor-set floor below which the controller flags critical. Not all drives use 10%.Must be read per-drive, never hardcoded in alert logic
Critical Warning byteHardware-level escalation from the controller. Bit 0 fires when spare drops below threshold.Any non-zero value requires investigation
Media and Data Integrity ErrorsConfirms data loss at the NAND level. Corroborates that the drive is actively failing, not just aged.Increasing from baseline
Percentage UsedVendor estimate of endurance consumed. Contextualizes whether low spare is from normal wear or premature failure.Disproportionately high relative to Available Spare
Data Units WrittenRaw host write volume. Enables runway calculation against rated TBW.Write rate increasing, accelerating endurance consumption
Composite TemperatureHigh temperature accelerates NAND wear and data retention loss, which can accelerate spare consumption.Sustained above WCTEMP (vendor-defined warning threshold)

Fixes

Replacement planning (primary action)

Available Spare never increases. Once below threshold, the only real fix is replacing the drive. The question is how urgently.

  • Below threshold but above 0%: Order a replacement. Schedule migration during a maintenance window. The drive may continue operating for weeks or months, but reliability is no longer guaranteed.
  • At 0% with corroborating signals (Media Errors rising, read-only bit 3 active, or health FAILED): treat as active failure. Begin data evacuation immediately if the drive is still readable.

Reduce write volume (buying time)

If replacement hardware is not immediately available, reducing write load extends the time before the spare pool fully exhausts:

  • Move write-heavy workloads (database WAL, application logs, swap) to another drive.
  • Enable TRIM if not already active (fstrim -v /mountpoint). This helps the controller reclaim invalidated pages, reducing write amplification.
  • Reduce the drive’s capacity utilization if it is above 80%. Nearly-full SSDs have higher write amplification because garbage collection has less free space to work with.

This does not reverse the damage. It slows the rate of spare consumption while you procure a replacement.

Do not attempt to repair the spare pool

There is no SMART command, firmware utility, or secure erase that restores Available Spare. The consumed spare blocks are permanently retired NAND. A secure erase or format operation resets the FTL mapping table but does not revive dead blocks.

Prevention

Baseline at deployment. Capture a full SMART snapshot when each drive is first deployed. Record the initial Available Spare value. If a new drive shows Available Spare below 100% at deployment, that may indicate factory defects already consumed some spares. Establish the baseline so you can distinguish “shipped that way” from “developed in production.”

Track rate of change, not just absolute value. A drive at 15% Available Spare that has been stable for 6 months is less urgent than a drive at 20% that dropped from 30% in the last month. Alerting on absolute values alone misses the acceleration signal that distinguishes stable historical damage from active decline.

Monitor Available Spare from day one. This is a Level 2 (Operational) signal in the SMART monitoring maturity model. Teams that only check Available Spare when drives start failing miss the runway they need for orderly replacement.

Use smartd automated checks. The -H directive checks the SMART health status, including the Critical Warning byte for NVMe devices. .

Schedule extended self-tests. Extended self-tests force reads across the entire media surface, surfacing latent bad blocks before production I/O hits them. Weekly short tests and monthly extended tests are common practice.

How Netdata helps

  • SMART attribute collection detects Available Spare decline promptly rather than waiting for the next manual check.
  • Rate-of-change tracking on Available Spare catches acceleration: a drive dropping from 20% to 15% over two weeks is flagged differently from one sitting stable at 15% for months.
  • Correlation with Media and Data Integrity Errors, Critical Warning bits, and Percentage Used in a single timeline confirms whether low Available Spare is normal wear or active failure without running multiple commands and comparing outputs manually.
  • Anomaly detection on write volume (Data Units Written) can flag unexpected write amplification burning spare capacity faster than the workload alone would predict.
  • Host-side I/O metrics (latency, errors) alongside SMART data catches failure modes where the drive’s own reporting lags behind what the kernel is experiencing.