Note · 2026-05-19 · shelf server, 6.6 kernel, schedutil

Letting the disks sleep

A solid-state disk advertises a short menu of power states and a set of latencies for getting in and out of them. Left on its shipped settings it stays near the top of that menu. The question is what the deeper states are worth once you are willing to pay the first read after a quiet gap.

The states a disk advertises

Each of the two disks on the shelf server lists five states: three active ones it uses while serving requests, and two low-power ones it drops into when idle. The numbers below come from the controller’s own table, per disk.

One disk. Power is what the controller reports for the state; the non-operational states cannot serve a request until the exit latency has passed.
State	Kind	Power	Exit, ms
ps0	active	6.3 W	-
ps1	active	4.6 W	-
ps2	active	3.2 W	-
ps3	idle	0.12 W	2.0
ps4	idle	0.012 W	7.5

As shipped, the autonomous transition is set to drop only as far as ps3 and no further. The drop to ps4 is ten times lower in power and nearly four times slower to leave, and whether that trade is worth taking is the whole of this note.

What the policy changes

I measured the shelf server idle, once with the shipped policy and once allowed to reach ps4, five ten-minute windows each, nobody logged in. The draw is read at the wall, not summed from the two controllers, because the wall figure is the one that includes the supply making the saving smaller than the disks promise.

Shelf server, idle. First-read latency is the 99th percentile of a read issued after a two-second quiet gap, which is the pause that lets the disk reach its deepest allowed state.
Policy	Idle draw	First read, p99
as shipped, ps3 floor	33.6 W	0.4 ms
allowed down to ps4	32.8 W	3.1 ms

Eight hundred milliwatts at the wall, across two disks, against an idle baseline that was 33.6 W before the wakeups work later that year took it lower. Per disk that is less than the controller’s own ps3-to-ps4 gap would suggest, and the difference is the supply: at this load it is giving back only part of what the disks stop drawing.

The catch is in the first column of reads

The 3.1 ms is not an average, it is the tail, and it only appears on the first read after the disk has had long enough to reach ps4. A busy disk never gets there; a disk that goes quiet between bursts pays the exit every time a burst starts. On a machine whose one service touches storage in a steady trickle, the disks almost never reach ps4 in the first place, so the saving I can actually bill against the real workload is closer to 0.3 W than 0.8.

That is the honest shape of it: the 0.8 W is real but it is an idle-bench figure, and the 0.3 W is what the live machine sees. Reporting the bench number as if it were the operational one is the same mistake as reading a residency counter once - a true number answering a question nobody asked.

What I left running

The conservative policy is on, on these two disks, because the service on this box tolerates a 3 ms hiccup on a cold read and will never notice it. I would not put it on a cache that goes idle between requests and is judged on its tail, nor on anything where a human is waiting for the first page after a pause. The watt is not worth a millisecond somebody can feel.

The two machines and the method are on the notes page. Reading the disk’s own counters has the same two traps as the idle-state counters in the idle-loop note: they are totals since the disk last reset them, and they say nothing about the last ten minutes until you read them twice.