Proxmox shows high SSD wearout: is the drive dying, and what is writing to it?

1. 1.Print the drive's SMART/Health Information log. On NVMe the Wearout column equals Percentage Used: Proxmox stores 100 minus that value and the Disks panel displays 100 minus the stored value.

   nvme smart-log /dev/nvme0

   Readingpercentage_used is the vendor's estimate of life used, based on actual usage and the maker's prediction of NAND life, and the drive updates it once per power-on hour. It can pass 100 (values over 254 read 255). 100 means the estimated endurance is consumed, not that the drive has failed.
2. 2.In the same output, check the fields that do signal a drive in trouble.
   ReadingA non-zero critical_warning, or available_spare below available_spare_threshold, matters more than percentage_used. The Critical Warning bits cover spare below threshold, degraded reliability and read-only media. available_spare is a normalised 0-100 percentage of remaining spare capacity.
3. 3.Cross-check with smartctl, which is the tool Proxmox itself calls to fill the column.

   smartctl -A /dev/nvme0

   ReadingThe same SMART/Health Information log. Proxmox parses its 'Percentage Used' line for the Wearout column.

1. 1.Record Data Units Written now and again after N days of normal load. One unit is 512,000 bytes of host data: the field counts thousands of 512-byte units, rounded up, and excludes metadata. The pattern below matches the label whether your nvme-cli prints it with spaces (2.x) or with underscores (older builds).

   nvme smart-log /dev/nvme0 | grep -iE 'data.units.written'

   ReadingHost bytes per day = (second reading - first reading) x 512,000 / N. Example: a delta of 4,000,000 units over 7 days is 4,000,000 x 512,000 = 2.048 TB, about 0.29 TB a day. This counts what the host sent; writes the SSD makes internally are not in it.
2. 2.Cross-check from the host side. Field 7 of the block device's stat file counts sectors written since boot and resets at boot, reattachment or overflow, so take both samples within one boot.

   cat /sys/block/nvme0n1/stat

   ReadingThe difference between two samples of field 7 is a write rate from the host's side. The kernel page we read does not state the sector size, so compare its trend with the drive's own Data Units Written delta rather than converting it to bytes.

1. 1.Find which wear attribute the drive exposes. Proxmox walks an ordered list that begins Media_Wearout_Indicator, SSD_Life_Left, Wear_Leveling_Count (it also checks names such as Perc_Rated_Life_Used, Percent_Lifetime_Used and Lifetime_Left) and shows 100 minus the normalised VALUE of the first match.

   smartctl -A /dev/sdX

   ReadingVALUE is normalised by each vendor's own algorithm, so the same Wearout column can mean different things on two SATA models. Note which attribute matched before comparing two drives' figures.
2. 2.For a write rate, read the RAW value of Total_LBAs_Written in the same output today and again after N days. Do not convert it to bytes until you have the vendor's unit: one forum poster computed a Crucial MX500's lifetime writes as anything from 1.29TB to 250TB depending on the unit assumed.
   ReadingAttribute meanings and raw units are vendor-specific. The delta between readings still shows whether writes are steady or bursty, even before the unit is known.
3. 3.If the drive supports it, also print the ATA Device Statistics log.

   smartctl -l devstat /dev/sdX

   Readingsmartctl prints the values and descriptions of the log's pages. Only some recent devices support this log.

1. 1.Watch the pool per vdev at a fixed interval, first with guests idle, then across the window where the Wearout jump happened. Ignore the first block of output, which is the average since boot.

   zpool iostat -v rpool 60

   ReadingLater blocks show write bandwidth per vdev for each 60-second interval: the steady background rate the pool sends to the SSDs. In one forum thread an overnight jump traced to a nightly script calling the Proxmox REST API thousands of times; in another, a pfSense guest's logging was the writer.
2. 2.Check the ZFS settings that add writes.

   zfs get atime,relatime rpool; zpool get autotrim,ashift rpool

   Readingatime=on without relatime=on turns reads into access-time writes; OpenZFS recommends relatime=on or atime=off. autotrim=off is the default. An ashift smaller than the drive's sector size forces a read before every partial-sector write. Changing any of these is a configuration decision, not a diagnostic.
3. 3.Account for Proxmox's own background writers. pmxcfs keeps the cluster configuration in an SQLite database on disk at /var/lib/pve-cluster/config.db. rrdcached, which forum threads report Proxmox uses for its graphs, batches RRD updates and writes them to disk on a timer, every 300 seconds unless -w sets another interval. Forum threads name these two as the main PVE writers; we have not found a Proxmox document that states how much they write.

1. 1.Convert the drive's rating to total writes. TBW is the JEDEC JESD218 endurance rating: the terabytes a host can write to the SSD. DWPD is full-capacity writes per day for the vendor's stated lifetime, so rated total writes = capacity x DWPD x 365 x rated years.
   ReadingExample: 7.68TB at 1 DWPD over a stated 5 years is 7.68 x 1 x 365 x 5 = 14,016 TB; the same 1 DWPD on a 3-year basis is 8,409.6 TB. TBW figures stated on different lifetime bases are not comparable, so compare DWPD, or state the basis next to each TBW figure.
2. 2.Multiply the host writes per day from the previous paths by the days of service you still want from the drive, add what Data Units Written already shows, and compare the total with the rated figure.
   ReadingUnder the rating: the write rate does not call for a different drive; reducing the writers found in the previous path buys margin. Over the rating: a drive with a higher stated rating is the fix.

Yes. The field can exceed 100, and values over 254 are reported as 255. A reading of 100 means the vendor's estimated endurance is used up; it does not by itself indicate a failure, so check Critical Warning and Available Spare.

Percentage Used is not live: the drive updates its estimate once per power-on hour. Take Data Units Written readings either side of the next jump and run zpool iostat across the same window to see whether a burst of writes explains it.

No. It counts data the host sent, in thousands of 512-byte units, excluding metadata. Writes the SSD makes internally are not in it, so it cannot show amplification inside the drive.

In one document, yes. Proxmox's ZFS Benchmark paper (November 2020) answers "Can I use consumer or pro-sumer SSDs?" with "No. Never.", citing performance, reliability and endurance, and calls reliable enterprise-class SSDs with high endurance and power-loss protection essential for ZFS. The current admin guide is softer: its system requirements say "Using consumer SSDs is discouraged" and recommend SSDs with power-loss protection for good performance, and it recommends an enterprise-class SSD for ZFS cache and log devices, SSDs with power-loss protection for a ZIL log, and enterprise-class NVMe SSDs for storage replication. Corrected 2026-10-14: this answer used to say we had found no Proxmox document that ruled consumer SSDs out, because the 2020 paper had not been opened.