磁盘写缓存被关会导致Seq写入速度断崖下跌、单次写延迟飙升（从微秒级升至毫秒级）、AS SSD Benchmark中Seq Q32T1 Write异常偏低而读取正常，且4K随机写入未同步暴跌。

磁盘写缓存被关会导致什么现象

物理磁盘（尤其是企业级 SAS/SATA SSD 或 HDD）的写缓存（Write Cache）一旦被禁用，sync 类写入会直接落盘，绕过设备内部缓存加速，导致：单次写延迟飙升（从 。数据库场景下最典型的表现是：INSERT/UPDATE 响应变慢、事务提交卡顿、WAL 日志刷盘延迟高、innodb_log_waits 或 pg_stat_bgwriter 中 checkpoints_timed 骤增。

如何快速确认写缓存是否被关

别猜，直接查硬件层状态。不同设备命令略有差异，但核心逻辑一致：

• smartctl -a /dev/sdX（X 替换为实际盘符），重点看输出中 Write Cache 行 —— 若显示 Disabled 或 Unavailable，基本坐实
• 对 RAID 卡后端盘，需先查卡：如 MegaRAID 用 megacli -AdpCacheRead -aALL，LSI/Avago 用 storcli /c0 show，确认 WriteBack 是否启用；再查物理盘是否被强制设为 WriteThrough
• 某些 NVMe 盘需用 nvme get-feature -f 0x05 /dev/nvme0n1 查 Volatile Write Cache 状态
• 注意：hdparm -I /dev/sdX 的输出里 *Write cache 带星号才表示支持且启用；无星号 ≠ 一定关闭，但结合 smartctl 结果可交叉验证

iostat 和 iotop 看到的现象和关键指标

写缓存关闭后，iostat -xm 1 会出现非常“干净但可怕”的特征：

Linux Security Scanner

Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...

下载

• %util 长期 95–100%，但 r/s 和 w/s 数值不高（比如只有 200–500 IOPS），说明不是吞吐压满，而是每次 IO 都在等物理响应
• await 显著高于 svctm（例如 await=85ms，svctm=1.2ms），差值就是排队+设备响应耗时，指向设备级延迟瓶颈
• aqu-sz（平均队列深度）可能不高（
• iotop -oPa 会明确显示 mysqld 或 postgres 进程的 WRITE 列持续处于高 B/s，但线程常卡在 D 状态（不可中断睡眠），strace -p PID -e trace=write,fsync 可见 fsync 耗时极长

临时恢复与长期规避要点

写缓存关闭通常是运维误操作（如 RAID 卡固件升级后默认策略变更）或厂商为“数据安全”一刀切禁用所致。恢复不能只靠系统参数：

• 立即生效：对直连盘，用 hdparm -W1 /dev/sdX 尝试开启（需设备支持且未被 RAID 卡锁定）；对 RAID 卡后端盘，必须进卡管理界面或用命令行工具（如 storcli /c0/v0 set wrcache=on）打开 WriteBack 缓存，并确保电池/电容模块健康（storcli /c0 show 查 BBU Status）
• 禁止盲目依赖 vm.dirty_ratio 调大来“缓解”——这只会让脏页堆积更久，最终爆发更猛烈的 I/O 风暴
• 数据库配置要配合：MySQL 开启 innodb_flush_method=O_DIRECT（绕过 pagecache，避免双重缓存）；PostgreSQL 确保 fsync=on 且 synchronous_commit=on，此时写缓存是否开启直接影响事务延迟天花板
• 监控必须覆盖硬件层：仅看 iostat 不够，需定期采集 smartctl -a 输出、RAID 卡状态、/proc/diskstats 中 io_ticks 和 time_in_queue，写缓存异常往往比业务告警早数小时暴露

真正难的不是发现它被关了，而是在混合存储架构（比如 NVMe 做 WAL、SAS 做数据盘）里，只有一块盘的写缓存被关，其余正常，这种局部异常最容易被忽略。