RAID Controller Cache Battery Failure: Silent Game Database Write Penalties

A RAID controller’s onboard cache looks like a free performance win — and it is, right up until the moment the battery dies and the controller silently flips to write-through mode. We have seen this exact failure on a 400-player ARK cluster: after about three years of service, the cache battery on a PERC H730 hit end of life, the controller demoted itself without alerting any configured monitoring, and random world-save latency jumped from 1.8ms to 47ms while aggregate write throughput dropped by 60%. The server stayed online. The database stayed consistent. But every player save stalled for a frame, and nobody knew why for six days.

Why Game Databases Are a Worst-Case Write Pattern

Game server persistence is hostile to disk in a specific way: it is bursty, small-block, and latency-critical. A typical MMORPG or survival game produces a steady trickle of position and state writes, punctuated by synchronized save events that dump thousands of small records in under a second.

Workload	IOPS	Avg block	Burst duration	Battery cache benefit
Steady position updates	800-2,000	4-16KB	continuous	Low
Synchronized world save	15,000-40,000	8-32KB	0.5-2s	Very high
Player inventory flush	5,000-12,000	4KB	0.2-1s	High
Plugin log append	500-3,000	1-4KB	continuous	Medium
Backup snapshot	2,000-6,000	128KB+	30-120s	Low

The battery-backed cache matters almost entirely for those burst rows. Without it, a RAID 10 array must complete its writes before acknowledging them, and every write on a 4KB random pattern costs multiple physical I/O operations. With a write-back cache, the burst lands in DRAM and the controller drains it to disk at its own pace. That is the difference between a 2-second save that players never notice and a 40-second save that causes a mass disconnect.

What Actually Happens When the Battery Fails

• Silent write-through demotion. Most controllers switch policy automatically and keep serving. Alerting is often off by default.
• Latency, not throughput, degrades first. Your bandwidth monitoring stays green while tail latency explodes.
• Rebuild risk rises. With degraded write performance, a subsequent drive failure makes rebuilds take far longer, extending your vulnerability window.
• No data loss on its own. A failed battery is a performance incident, not a corruption incident — unless a power loss occurs mid-write.

# Check controller cache policy and battery state
storcli /c0/vall show all | grep -iE "Write Cache|Disk Cache"
storcli /c0/cv show all | grep -iE "State|Capacitance|Temperature"

# Alert on degraded cache policy (run hourly)
if storcli /c0/v0 show all | grep -qi "Write Cache.*WT"; then
  logger -p daemon.err "ALERT: RAID write cache demoted to write-through"
fi

That four-line check is the entire mitigation for the six-day mystery above. Battery-backed cache policy should be a monitored metric, exactly like CPU temperature.

Battery vs Supercapacitor vs No Cache

Cache type	Write burst performance	Service life	Replacement	Best fit
No cache / HBA only	Baseline	N/A	N/A	ZFS hosts, software RAID
Li-ion battery cache	Very high	2-3 years	$60-150, hot-swap	Legacy enterprise controllers
Supercapacitor + NAND flash	Very high	5-7 years	Rarely needed	Modern controllers (H740P, PERC 11+)
Software (ZFS ARC/SLOG)	High	N/A	N/A	Linux-native game hosts

If you are buying hardware today, insist on supercapacitor-backed cache with NAND flash for the write journal. It removes battery replacement from your maintenance calendar entirely, and it survives the power-loss window that a battery-only design handles less gracefully on modern high-capacity drives.

Configuring Cache Policy for Game Saves

# Set write-back policy, no read-ahead for random game DB access
storcli /c0/v0 set wrcache=WB ra=No
storcli /c0/v0 set direct=On

# Verify with fio before and after (realistic game-save burst)
fio --name=saveburst --rw=randwrite --bs=8k --iodepth=64 \
    --numjobs=8 --runtime=30 --group_reporting \
    --filename=/dev/mapper/gamedata

• Use write-back with the battery present, and validate the policy after every controller firmware update.
• Disable read-ahead for game database volumes — game access is random, and read-ahead wastes controller cache on speculative fetches.
• Keep direct I/O enabled; it bypasses controller cache for reads and keeps behavior predictable.
• Re-run the fio baseline quarterly. A quiet drop in IOPS with unchanged workload is your early warning that cache policy has changed.

Verdict

A RAID cache battery is not a spec sheet line item you can ignore after purchase. It is a consumable with a known service life, and its failure mode is invisible in every standard monitoring dashboard. Do three things: buy controllers with supercapacitor-backed cache instead of older battery designs, monitor for write-through demotion as a first-class alert, and re-baseline your IOPS quarterly so silent degradation never gets six days of free rein. If your current host cannot tell you what cache policy your controller is running, that is a strong signal to compare dedicated server specs on our comparison table and look for hosts that document their RAID controller configuration openly.