底层存储阵列升级后性能不达标，需先验证是否真存在性能瓶颈，再检查链路各层是否适配、对齐、无隐性阻塞；运行 iostat -xz 1 60 观察 %util、await 等指标判断设备层是否饱和。
底层存储阵列升级后性能不达标，不能直接归因于“新设备更慢”，而要验证是否真正发挥了新硬件能力。关键在于确认升级后的链路各层是否适配、对齐、无隐性阻塞——很多问题其实出在系统层配置未同步更新，而非阵列本身。
先验证是否真存在性能瓶颈
别跳过这步。运行 iostat -xz 1 60 观察持续负载下的核心指标：
- %util 接近或长期达 100%，且 await > 1ms（SSD）或 > 10ms（HDD），说明设备层已饱和；
- %util 很低（如
- r_await 和 w_await 显著分离（比如 w_await 高但 r_await 正常），提示写路径有特殊阻塞（如 sync 强制刷盘、journal 延迟、RAID write-back 缓存被禁用）。
检查阵列与物理盘的真实健康与配置状态
/proc/mdstat 只显示逻辑状态，必须组合验证：
- 执行 mdadm --detail /dev/mdX，重点看：State 是否为 clean（异常断电后可能残留 dirty 状态）、Active Devices 数量是否匹配预期、Array Size 与 Used Dev Size 是否一致（不一致说明某盘容量被截断）；
- 对每个成员盘（如 /dev/sdb1）运行 smartctl -a -d ata /dev/sdb（SATA）或 smartctl -a /dev/nvme0n1（NVMe），关注 RAW_VALUE：ID 5（重映射扇区）、ID 197（待重映射扇区）、ID 199（UDMA CRC 错误计数） 是否突增；
- 若用 RAID 卡（如 MegaRAID），需用 MegaCli64 -PDList -aAll 查物理盘 State（是否为 Online 或 Predictive Failure），不能只信操作系统层面的 /dev/sdX 可见性。
确认 I/O 路径关键参数是否适配新阵列
旧配置在新硬件上常成为性能枷锁：
- 检查调度器：cat /sys/block/mdX/queue/scheduler，SSD/NVMe 阵列应设为 none（NVMe）或 kyber（现代 SSD），避免使用 deadline/cfq 等机械盘调度器；
- 确认队列深度：cat /sys/block/mdX/queue/nr_requests，建议调至 1024 或更高（尤其对高并发随机 I/O）；
- 验证 write-back 模式：megacli -AdpCachePolicy -Get -aALL | grep "Write Cache"（MegaRAID）或 storcli /c0 show（LSI），确保 Write Cache 已启用且 Battery/Capacitor OK；
- 检查文件系统挂载选项：ext4/xfs 应含 noatime,nodiratime,barrier=0（仅限有 UPS/BBU 的阵列），避免元数据刷盘拖慢写入。
排查分区与块层对齐是否失效
阵列升级后若重建了逻辑卷或重刷了分区表，极易丢失对齐：
- 用 lsblk -o NAME,START,SIZE 快速查看各分区 START 值，是否为 2048（1MiB）整数倍；
- 执行 sudo parted /dev/mdX align-check optimal 1，返回 “1 aligned” 才算过关——仅看 fdisk 显示 Start=2048 不作数；
- 查底层约束：cat /sys/block/mdX/queue/optimal_io_size 和 /sys/block/mdX/alignment_offset，若后者非零（如 2048），则起始偏移需满足 (optimal_io_size + alignment_offset) / logical_block_size 的整数倍；
- 若未对齐，必须重新分区：parted /dev/mdX mkpart primary 1MiB 100%，再格式化，不可仅调整起始扇区。
