A RAID controller’s onboard cache looks like a free performance win \u2014 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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\nWorkload<\/th> IOPS<\/th> Avg block<\/th> Burst duration<\/th> Battery cache benefit<\/th><\/tr><\/thead> Steady position updates<\/td> 800-2,000<\/td> 4-16KB<\/td> continuous<\/td> Low<\/td><\/tr> Synchronized world save<\/td> 15,000-40,000<\/td> 8-32KB<\/td> 0.5-2s<\/td> Very high<\/td><\/tr> Player inventory flush<\/td> 5,000-12,000<\/td> 4KB<\/td> 0.2-1s<\/td> High<\/td><\/tr> Plugin log append<\/td> 500-3,000<\/td> 1-4KB<\/td> continuous<\/td> Medium<\/td><\/tr> Backup snapshot<\/td> 2,000-6,000<\/td> 128KB+<\/td> 30-120s<\/td> Low<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n What Actually Happens When the Battery Fails<\/h2>\n\n\n\n
# Check controller cache policy and battery state\nstorcli \/c0\/vall show all | grep -iE \"Write Cache|Disk Cache\"\nstorcli \/c0\/cv show all | grep -iE \"State|Capacitance|Temperature\"\n\n# Alert on degraded cache policy (run hourly)\nif storcli \/c0\/v0 show all | grep -qi \"Write Cache.*WT\"; then\n logger -p daemon.err \"ALERT: RAID write cache demoted to write-through\"\nfi<\/code><\/pre>\n\n\n\nBattery vs Supercapacitor vs No Cache<\/h2>\n\n\n\n
Cache type<\/th> Write burst performance<\/th> Service life<\/th> Replacement<\/th> Best fit<\/th><\/tr><\/thead> No cache \/ HBA only<\/td> Baseline<\/td> N\/A<\/td> N\/A<\/td> ZFS hosts, software RAID<\/td><\/tr> Li-ion battery cache<\/td> Very high<\/td> 2-3 years<\/td> $60-150, hot-swap<\/td> Legacy enterprise controllers<\/td><\/tr> Supercapacitor + NAND flash<\/td> Very high<\/td> 5-7 years<\/td> Rarely needed<\/td> Modern controllers (H740P, PERC 11+)<\/td><\/tr> Software (ZFS ARC\/SLOG)<\/td> High<\/td> N\/A<\/td> N\/A<\/td> Linux-native game hosts<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Configuring Cache Policy for Game Saves<\/h2>\n\n\n\n
# Set write-back policy, no read-ahead for random game DB access\nstorcli \/c0\/v0 set wrcache=WB ra=No\nstorcli \/c0\/v0 set direct=On\n\n# Verify with fio before and after (realistic game-save burst)\nfio --name=saveburst --rw=randwrite --bs=8k --iodepth=64 \\\n --numjobs=8 --runtime=30 --group_reporting \\\n --filename=\/dev\/mapper\/gamedata<\/code><\/pre>\n\n\n\n