Fit the two SSDs in Saruman, and re-derive what the spindles decided

[Gerrrt]

Two SSDs for Saruman were bought on 2026-09-09. This is the tracker for
fitting them, because a drive in a box on the shelf changes nothing that the
documents say, and every sizing decision on this host starts from the disks
it does not yet have.

What was bought

Two Samsung SM863a 960 GB, part MZ-7KM960N — 2.5" SATA 6 Gb/s enterprise
SSDs with power-loss protection, rated for roughly three full drive writes a
day over their warranty term. Listed at
https://www.ebay.com/itm/800210578217. SATA on a SAS backplane is fine for
the DL360 Gen9's SFF bays and the Smart Array knows what to do with them; the
power-loss protection matters for the write-cache question below, because
the drives' own caches are safe to leave on.

Why they were bought

ADR-0007: "The constraint on Saruman is storage, not compute: 128 GB and 48
threads against a single mirrored pair of 7.2K disks. The fleet is sized
against spindles, not RAM." ADR-0029 turned that into a number — ~80–100
random write IOPS for the whole machine — and sized the lab domain to it:
four servers continuous, two endpoints per session, because six idle Windows
guests would be most of the budget. #266 sizes the Wazuh indexer from the
same spindles. The SSDs are bought to raise that ceiling.

To decide at the fit, not before

• Replace the mirror, or sit beside it. The array today is 2× 1 TB SAS
  HDD, RAID 1, holding Proxmox and every guest. Either the SSDs become the
  array and the HDDs leave, or they become a second logical drive for guest
  disks and the HDDs keep the OS, ISOs and backups. The second is the smaller
  change and keeps a spindle for the things that do not need IOPS.
• Whether the controller manages them. The drive rules —
  IloDrivePredictiveFailure, IloDriveSmartUnreadable, and the
  replaceDriveSSDWearOut(4) state they already know about — read the Smart
  Array's view through cpqida.mib. A layout the controller does not manage
  (HBA mode, ZFS on raw disks) falls out of every one of them, and SMART is watched on Saruman's array only — oracle, prometheus and morpheus have none #351's
  SMART path would have to be re-checked against it. Decide with that cost
  named.
• The write cache. IloBatteryCondition has been firing on shiva with no silence and no owner #76 is still open: the Smart Storage Battery fitted on
  2026-09-02 re-enabled the cache, and cpqDaAccelWriteCachePercent still
  reads 0. Whatever logical drive the SSDs form, decide whether the cache
  applies to it, and whether the ratio question is answered or made moot.
• Guests down or not. The SFF bays are hot-plug, so fitting needs no
  window. Migrating guest disks does. schedule-maintenance.md is the
  shape, and ADR-0028's guest-liveness alerts page for real — silence first.

Documents that go stale the day they are fitted

• hardware.md — the Compute table's Storage column, and its copy in
  network.md that check_docs.py compares it against. Model, capacity and
  serials into the accessories entry (Add HomeBox to the sensitive tier, and give docs/hardware.md a place to keep serials #148 wants the serials somewhere).
• ADR-0029 — the IOPS derivation and "The duty cycle is a spindle
  decision" both rest on ~90 write IOPS. Once that is not the number, the
  endpoints running per session is a choice rather than a constraint. Either
  a dated note on the ADR or a superseding one; not a silent edit.
• ADR-0007's constraint sentence, quoted in Run Wazuh on Saruman — the heaviest component in ADR-0007 #266 and Build the lab Windows domain on Saruman (ADR-0029) #414. Same treatment.
• roadmap.md's Build the lab Windows domain on Saruman (ADR-0029) #414 paragraph, which repeats the ninety-IOPS reasoning.

Not decided here

Whether the range in ADR-0017 still needs NVMe for its own reasons. It does —
the argument there was a separate fault domain, not only IOPS — so this
purchase does not reopen it.

[Gerrrt]

Fitted 2026-09-18, and stopped at the bays. Both drives went into bays 3 and 4 and the iLO reported them in the 20:11 UTC scrape, absent at 20:10: cpqDaPhyDrv indexes 2 and 3, Port 1I Box 1 Bay 3 / Bay 4, solid-state, SATA at 6 Gb/s, 915715 MB each, SMART ok, notConfigured. Serials S3F3NX0K601487 (Bay 3) and S3F3NX0K806107 (Bay 4), firmware GXM5304Q. Nothing alerted and nothing was silenced; nothing needed to be.

That is step 4 of fit-the-saruman-ssds.md and no other step: no ssacli on the host, no logical drive (cpqDaLogDrv still index 1 only), no thin pool, alexander still on the HDD mirror, no fio, no cache reading for #76. Recorded in #521 — the runbook's status block and step 11's Observed column, the Compute table's Storage column (which the accessories entry said moves on this day), the serials in the accessories entry (where #148 asked for them), and the roadmap.

Three of the runbook's predictions were wrong, corrected there:

• the iLO names the drive SAMSUNG, not MZ7KM960... — vendor only for a third-party SATA drive, where the HPE disks get a part number;
• the walk did not get slower — scrape_duration_seconds is 11.4 s either side, not the 13–17 s estimated;
• the serials were read back through the iLO, not off the labels first. While both drives are Unassigned that can still be put right by pulling one and reading it; after step 5 it cannot.

Settled from the "does not know" list: 2 (trays arrived, both, carrier firmware 11/6 matches bays 1–2), 3 (bays 3 and 4 are cabled), 5 (an unconfigured third-party SATA SSD reads SMART ok immediately; IloDriveSmartUnreadable never went pending).

Two readings worth having. The wear columns are blank on both SSDs (SSDWearStatus 1, endurance and power-on hours 4294967295), as on the HDDs. cpqDaPhyDrvHasMonInfo reads false on all four and an unconfigured drive may simply not be polled, so step 11 re-reads them after step 5 — if still blank then, the smartctl -d cciss issue the runbook's closing paragraph describes gets opened. And cpqDaPhyDrvMaximumTemperature is a lifetime figure: 62 °C on Bay 3 against a 60 threshold, 51 on Bay 4, both at 30–32 °C now — the previous owner's number, and the kind only direct SMART would have shown at purchase.

No ADR changes. ADR-0029's ninety goes stale when step 8's measurement lands, not today.

Next, in order: step 2 and step 3 from the Mac (capture the Cache Ratio and Interface Type lines verbatim — those are the #76 and item-12 readings), the optional label check, then step 1's two silences from prometheus immediately before step 5, steps 5–9 on the Mac, steps 10–11 from prometheus.