$ guides / smartctl-disk-monitoring / smartctl-data-units-written-tbw ▌

Operations Guides

Data Units Written vs rated TBW: computing SSD endurance runway

SSD endurance is finite and specified in the datasheet as a TBW (Total Bytes Written) rating. The odometer is a SMART counter, but it uses non-obvious units and counts host writes, not NAND writes. This guide covers how to read the write-volume counter from smartctl, convert it to bytes correctly, compare it against rated TBW, and project when the drive reaches its endurance limit.

The counter has two names depending on the bus. NVMe drives report “Data Units Written” in units of 1000 x 512 bytes. ATA/SATA SSDs report attribute ID 241 (Total_LBAs_Written), typically in 512-byte sectors. Both measure host writes only. The drive’s NAND sees more writes due to write amplification, so this calculation produces an upper bound on remaining life, not a precise prediction.

What the signal reports

Data Units Written (NVMe) and Total_LBAs_Written (ATA ID 241) are cumulative counters of data the host has written to the drive since manufacture. They are odometer readings, not rate meters. The value only goes up. It resets only if the firmware is factory-reset or the drive is sanitized.

This is an INFO-level signal. It does not indicate failure or degradation. Its operational value is forward planning: combined with the drive’s rated TBW, it tells you how much endurance budget remains and when it will run out at the current write rate.

What it does not tell you:

Whether the drive is currently failing (use Available Spare, Media Errors, Critical Warning for that).
How much NAND wear has actually occurred (use Percentage Used).
Whether write amplification is burning endurance faster than the host-write rate suggests.

Reading the raw value correctly

The unit conversion is where most teams get this wrong. The two bus types use different units, and the NVMe unit is counterintuitive.

NVMe: Data Units Written

The NVMe SMART/Health Information Log reports Data Units Written in units of 1000 x 512 bytes. Each unit is 512,000 bytes. This is not 1024 x 512. It is not a power of two. The smartctl source confirms the multiplier in nvmeprint.cpp: le128_to_str(buf, smart_log.data_units_written, 1000*512).

# Read NVMe Data Units Written (human-readable output already converts)
smartctl -A /dev/nvme0n1 | grep "Data Units Written"

The human-readable output includes a bracketed value that already applies the conversion:

Data Units Written:  11,795,392 [6.03 TB]

That [6.03 TB] is the converted value. For manual calculation from the raw unit count:

bytes_written = data_units_written * 512000

ATA: Total_LBAs_Written (ID 241)

# Read ATA Total_LBAs_Written
smartctl -A /dev/sdX | grep -i "Total_LBAs_Written"

The standard interpretation is that each LBA is a 512-byte logical sector:

bytes_written = total_lbas_written * 512

Before relying on this, verify the drive’s logical sector size:

# Verify logical sector size
smartctl -a /dev/sdX | grep "Sector Size"

Most SATA SSDs report 512 bytes logical. If the drive uses 4096-byte logical sectors, the multiplier changes. Smartmontools vendor presets handle known conversions, but raw consumers must check.

JSON output

The smartctl JSON output (-j or -aj) exposes nvme_smart_health_information_log.data_units_written as a raw integer. The JSON value is not pre-converted to bytes. Apply the same 512,000 multiplier:

# Get raw NVMe data_units_written from JSON
smartctl -aj /dev/nvme0n1 | jq '.nvme_smart_health_information_log.data_units_written'

flowchart LR
    HW[Host writes] --> DUW["Data Units Written
or Total LBAs Written"]
    DUW -->|"x 512,000 bytes"| Bytes[Bytes written]
    Bytes -->|"vs rated TBW"| Pct["Percent endurance
consumed"]
    Pct -->|"remaining / daily rate"| Days[Days remaining]
    HW -.->|"x WAF 1.1 to 10+"| NAND[Actual NAND writes]
    NAND -.->|drives| Used[Percentage Used]

Computing endurance runway

Once you have bytes written, the calculation is straightforward. You need the drive’s rated TBW from its datasheet. For enterprise drives rated in DWPD (Drive Writes Per Day) instead of TBW:

rated_tbw = dwpd * capacity_in_tb * warranty_years * 365

Endurance consumed

percent_consumed = (bytes_written / (rated_tbw * 1e12)) * 100

Days remaining

Establish the daily write rate by taking two snapshots separated by a known interval (at least a week for a stable estimate):

# Snapshot 1
smartctl -A /dev/nvme0n1 | grep "Data Units Written"

# ... wait N days ...

# Snapshot 2
smartctl -A /dev/nvme0n1 | grep "Data Units Written"

daily_write_tb = (units_snapshot2 - units_snapshot1) * 512000 / 1e12 / days_between
days_remaining = (rated_tbw - current_tbw) / daily_write_tb

Worked example

A 2 TB NVMe drive with a 1200 TBW rating reports 11,795,392 Data Units Written.

bytes_written = 11,795,392 * 512,000 = 6,039,240,704,000 bytes = ~6.04 TB
percent_consumed = (6.04 / 1200) * 100 = 0.50%

If the drive has been in service for 200 days, the daily write rate is:

daily_rate = 6.04 / 200 = 0.0302 TB/day
days_remaining = (1200 - 6.04) / 0.0302 = 39,534 days (~108 years)

This is a lightly used drive. Contrast with a database WAL drive writing 2 TB/day on the same model:

days_remaining = (1200 - 6.04) / 2.0 = 597 days (~1.6 years)

That drive needs a replacement schedule.

Safety margin

Apply a 20-30% discount to the computed runway. Write amplification varies with workload (a switch from sequential to random writes can double WAF overnight), and the rated TBW is a warranty figure, not a cliff edge. If the raw calculation says 365 days, plan replacement within 250-290 days.

Write amplification: why host writes understate actual wear

Data Units Written and Total_LBAs_Written count host writes. The NAND flash receives more writes because of write amplification. The write amplification factor (WAF) is the ratio of NAND writes to host writes. It is always greater than or equal to 1.

WAF depends on workload pattern and drive state:

Workload	Typical WAF
Sequential writes, TRIM enabled, drive below 70% full	1.1 - 1.5
Mixed random/sequential, typical database	2 - 4
Small random writes, drive near full, no TRIM	5 - 10+

A WAF of 3 means the NAND sees three times more writes than the host counter reports. This does not change the Data Units Written reading (that counter is always host writes), but it means physical wear advances faster than the runway calculation predicts.

This is why NVMe Percentage Used can disagree with the Data Units Written / TBW calculation. Percentage Used is a vendor-specific estimate that incorporates actual NAND writes, including write amplification. Some vendors compute it from NAND-level program/erase counts rather than host write volume. A drive can report 100% Percentage Used while Data Units Written is only 30% of rated TBW, because the workload had high write amplification.

Use Data Units Written for the trend (write rate over time) and Percentage Used for the absolute position (how close to the wall). When they disagree significantly, investigate write amplification.

Vendor and tooling quirks

Non-standard ATA units

Most SATA SSDs report ID 241 in 512-byte sectors. Some Toshiba drives have been observed using 32 MiB (33,554,432 bytes) units for attribute 241 instead. If your bytes-written calculation produces absurdly large numbers, verify by writing a known amount of data and checking the counter increment.

JSON missing logical_block_size

Some smartctl NVMe queries omit logical_block_size (observed for a Samsung enterprise drive queried at the controller path). This caused the Prometheus smartctl_exporter to report zero bytes written for affected outputs until version 0.13.0 (released 2024-12-21), which multiplied NVMe Data Units by 512,000 bytes without requiring logical_block_size.

If you are consuming JSON directly, always multiply data_units_written by 512,000 for NVMe drives. Do not depend on logical_block_size being present.

Namespace vs bare device paths

Querying /dev/nvme0 (the controller device) may omit fields in JSON output that /dev/nvme0n1 (the namespace) includes. Always query the namespace device for SMART/Health data.

Percentage Used above 100%

The NVMe specification allows Percentage Used to report values above 100%, up to a maximum of 255%. A drive at 100% has consumed its rated endurance but may continue operating. Values above 100% mean the drive is operating beyond warranty parameters. The spec notes that 100% “may not indicate an NVM subsystem failure.” Drives have been observed operating at 150%, 200%, and higher without immediate failure. Treat 100% as “schedule replacement,” not “drive is dead.”

Signals to watch alongside write volume

Signal	Why it matters	Warning sign
Data Units Written / Total_LBAs_Written	Raw write workload driving all wear	Sustained increase in daily write rate without workload change
NVMe Percentage Used	Vendor estimate of endurance consumed (includes WAF)	Disagrees significantly with Data Units Written / TBW calculation
NVMe Available Spare	Remaining spare block pool for remapping failed blocks	Declining while Percentage Used is still below 100%
Media and Data Integrity Errors	Confirmed NAND data corruption	Any nonzero value, especially if increasing
Reallocated Sector Count (ID 5)	Growing count means blocks are failing faster than expected	Increasing alongside high Percentage Used
NVMe Critical Warning bits	Drive-level escalation of health conditions	Bit 0 (spare below threshold) or bit 3 (read-only mode) set

The pattern that signals active SSD wear-out: Percentage Used approaching 100%, Available Spare declining, and Media Errors or Reallocated Sectors beginning to appear. Data Units Written tells you how fast you are approaching that pattern.

How Netdata helps

The Netdata smartctl collector scrapes Data Units Written (NVMe) and Total_LBAs_Written (ATA) at per-second resolution, eliminating manual snapshot intervals for write-rate trending. Percentage Used and Available Spare appear alongside write volume on the same chart, making divergence between the three signals immediately visible. ML anomaly detection flags sudden changes in daily write rate, which often indicate a misconfigured application or runaway logging process burning SSD endurance. Per-disk dashboards let you compare write rates across drives in the same role, where a single drive writing far more than its peers suggests a software issue rather than a hardware one.