The SSD lost forty percent in a year: why Proxmox wears a disk faster

You built the server, a year passed, and the SSD's life indicator has dropped to sixty percent. The first thought is a fault. Usually it is not.

The disk is not broken, the workload is different.

What wear is

The cells of an SSD survive a limited number of writes. The disk reports this as a percentage: how much is left. As the percentage falls the disk does not slow down, does not break, gives no sign at all. Only the number goes down.

That is what makes wear an insidious measure: by the time you notice, you are already near the end of the road.

A server disk does not idle like a desktop disk

On a desktop computer the disk sits idle most of the time. On a virtualisation server it never does.

It is not only your virtual machines that write. The server's own logs, the cluster state file, metric records, the guests' own journals, all of them produce constant small writes. On their own they are insignificant; together they are a continuous stream.

The multiplier nobody expects

This is where the real issue lies: a small write made from inside a virtual machine lands on the physical disk much larger.

Because the path is long. The guest's filesystem rounds the write up to its own block size. The virtual disk layer rounds it again. The server's filesystem rounds it once more. The SSD's own internal management rounds it again. Every layer says "at least this much" and none of them rounds down.

The result: a four kilobyte write can grow several times over at the physical layer. This is not a fault, it is the natural price of layers. But if it is not accounted for, disk life comes out far below expectation.

This multiplier grows further in two places: filesystems that write while copying (the same data is written to a new place and the old one is left behind), and work that wants to be sure every write has reached the disk, typically databases.

The real difference between a consumer disk and a server disk

The difference is not speed. It is two things.

The write budget. Disks sold for servers are made to survive far more writes. Between two disks of the same size, the endurance difference can be several times over.

Behaviour under sustained load. Consumer disks use a fast buffer and slow down considerably once that buffer fills. On a desktop this stays invisible, because the buffer finds time to drain. On a server it does not.

There is also a quiet but important distinction: server disks are designed so that they can still write out what is in their buffer even if power is cut. That lets them safely answer "written" early. A consumer disk without that guarantee either answers slowly or takes a risk.

What you can do without buying new hardware

Separate heavy-writing work from the boot disk. If a machine collects logs, runs a database or keeps constant records, put its disk somewhere else.

Review the swap area. On a server with enough memory, constant swapping means both slowness and wear.

Turn off unnecessary detailed logging. A debug level set once and forgotten keeps writing for years.

The number to watch is not the percentage but the slope

"Eighty five percent left" says nothing on its own. The same percentage means ten years on one disk and eight months on another.

The right question is this: how many points did it drop in the last month? If it drops one point a month, you have years. If it drops five points a month, you have about a year and a half and should already be planning.

What Atlas does

Atlas reads the remaining life percentage the disk reports and produces an estimate of days left by looking at the slope of the last thirty days. So it tells you not a percentage but "at this rate, this many days".

For the subject of this article, what really matters is when the product refuses to estimate:

If it has only a single measurement, it does not estimate, it says there is not enough data for a trend. If the percentage has stayed flat or risen, it says it will not run out any time soon rather than inventing a number of days. If the drop is below a thousandth of a point per day, it again gives no number, because an estimate from that slope would be meaningless.

This is the hardest part of any estimating tool: knowing to stay quiet when the data does not carry the estimate. A wrong number of days is worse than no number at all, because plans get made on it.