先把当时的情况摆出来。华为 RH2288 上挂的是 LSI 9361 阵列卡，业务跑 MySQL，某天开始写入延迟从 3ms 涨到 40ms，storcli 查 /c0/v0 的 write policy 已经从 WriteBack 变成 WriteThrough，日志里有一行 BBU 状态是 Failed。
真正麻烦的地方在于，几个原因的现象几乎一样。电池老化导致充放电失败，阵列卡出于保护直接把写缓存关掉。另一种情况是BBU 的学习周期没跑完，卡处在 transparent learn 状态时也会临时切成直写。
少数情况下是阵列卡的 CacheVault 超级电容掉电，掉电保护数据都没了自然不敢开缓存。不容易想到的是，有人在管理口点过一次 write policy 设置，把它固化成 WriteThrough 保存了。
第一件事是用 storcli 看清电池和缓存策略的当前状态
storcli /c0 show bbu && storcli /c0/v0 show all | grep -i policy然后把电池状态和策略一起存一份基线
storcli /c0 show all > /root/raid_before.txt接着换掉失效的电池或电容后重跑学习周期
storcli /c0/bbu start learn末了确认缓存策略回到 WriteBack 再压测一轮
fio --name=t --rw=randwrite --bs=4k --size=1G --direct=1怎么算真的好了，看的是同一批现象。storcli /c0 show bbu 里电池状态是 Optimal，/c0/v0 的写策略显示 WriteBack，fio 的 4k 随机写延迟回到 5ms 以内。
WriteBack 在没电池保护时打开，掉电会丢缓存里的数据，宁可先用 WriteThrough 顶几天也别硬开。这类问题最好一次改到位，反复小改反而容易把原因搅混。