Hardware health: know each machine, its spec sheet, and real wear against the ratings #10352

The owner runs real hardware under the forge (the vxrail: a Dell VxRail node with PERC H730P virtual disks and a Samsung 980 PRO 1TB NVMe). At work, NVMe wear warnings are showing up. He wants the forge to tell him plainly whether he is cooking his drives, with no false positives.

What the forge should know and show, per machine:

• Inventory: model, firmware and capacity of each disk (plus CPU and memory), read from the machine itself.
• Its spec sheet: the vendor's rated figures. For the 980 PRO 1TB that's 600 TBW endurance, a 5-year warranty, and composite temperature limits of 82 °C (warning) and 85 °C (critical). Keep a small checked-in catalog keyed by model; never guess when a model isn't in it.
• Real numbers against those ratings, from the NVMe SMART/health log:

- data units written vs rated TBW - percentage used - available spare vs its threshold - media errors - critical warning bits - temperature now and time spent above warning or critical - power-on hours and unsafe shutdowns

• A projection: at the last 30 days' write rate, when rated TBW is reached.

No false positives:

• Only alert on what the drive itself reports as bad: a critical-warning bit set, spare below threshold, percentage used ≥ 80, media errors rising, or time above the critical temperature rising.
• Everything else is a quiet number with its rating beside it.
• Don't count RAID-controller virtual disks (PERC) as SSDs. Show them as "behind a controller; SMART not visible".

Today's reading (11-09 20:45Z):

In short, it's healthy. The host has no smartctl; the reading above came from a temporary nix shell.

Done when:

• A machine page (under the forge's machines or ops view) shows this compactly, following the P9 Calm rules: one line per disk when healthy, with detail on open.
• A test covers the alert rules against recorded SMART logs (healthy, worn, hot, failing).

Parked by the crew: the check stayed red through 2 automatic tries (pull #10363 closed; its branch torque/10352-hardware-health-know-each-machine-its-sp at dc94ebfd01bb keeps the work so far). Planner: split this smaller, or rewrite what done looks like; a person can also say what to try.

Parked by the crew: the check stayed red through 2 automatic tries (pull #10400 closed; its branch torque/10352-hardware-health-know-each-machine-its-sp at 9cbe93983184 keeps the work so far).

Parked twice since a person last spoke here, so it is the planner's now. Every reason:

1. the check stayed red through 2 automatic tries (pull #10363 closed; its branch torque/10352-hardware-health-know-each-machine-its-sp at dc94ebfd01bb keeps the work so far)
2. the check stayed red through 2 automatic tries (pull #10400 closed; its branch torque/10352-hardware-health-know-each-machine-its-sp at 9cbe93983184 keeps the work so far)

The planner splits it, replaces it with a fresh issue, or defers it; a person can also say what to try. Nothing starts here until then, and the board lists it.

Split by the planner after two red parks: the whole ask in one pull was too much for one run. Now three small pulls in order: #10464 (spec catalog + alert rules, pure, with recorded SMART fixtures), #10465 (readings kept per machine, 30-day write rate, TBW projection), #10466 (one quiet line per disk on the machines page, detail on open). How a reading reaches the forge from a host without smartctl is the next increment once these land. The parked branch torque/10352-… holds the earlier attempt for reference.