判断 SSD 对齐需用 blockdev 命令获取物理/逻辑扇区大小，并验证分区起始 LBA 是否为 2048（1MiB 对齐）；ext4 应挂载 noatime（禁用 atime 更新）和定期 fstrim（非实时 discard）；LVM cache 必须用 wt 模式且元数据设备独立；RAID1 替换成员盘需依次执行 fail、remove、add、同步、zero-superblock、复制分区表及 partprobe。
如何判断 /dev/sdX 设备是否已正确对齐（尤其是 SSD）
未对齐的分区会导致 SSD 随机写放大、IOPS 下降，尤其在数据库或日志类负载下表现明显。关键不是看设备型号，而是验证实际扇区边界。
- 用
sudo fdisk -l /dev/sdX查看Start列：若数值不能被4096整除（常见于旧版 fdisk 创建的分区），大概率未对齐 - 更可靠方式是用
sudo blockdev --getss /dev/sdX（物理扇区大小）和sudo blockdev --getpbsz /dev/sdX（逻辑扇区大小），再结合cat /sys/block/sdX/queue/logical_block_size交叉比对 - 对齐起点应为 LBA 2048（即 1MiB 对齐），现代
parted默认启用，但fdisk在交互模式下需手动输入2048作为 first sector
为什么 ext4 挂载时一定要加 noatime,discard（SSD 场景）
noatime 不仅减少元数据写入，还能避免因频繁更新 atime 导致的 journal 扩大；discard 则让文件系统在 unlink 或 truncate 时主动通知 SSD TRIM，防止后续写入性能衰减。但要注意：
-
discard是同步操作，高并发删除小文件时可能造成延迟毛刺；生产环境建议改用定期fstrim -v /mount/point（例如每周 cron） -
noatime已隐含relatime行为，无需额外写relatime - 若使用 LVM + ext4，确保
lvcreate时指定--discards y，否则底层 thin pool 可能忽略 TRIM 传递
lvmcache 在缓存元数据与热点数据时的配置陷阱
lvmcache 不是“开箱即用”的加速器，错误配置反而导致 I/O 延迟升高。重点不在 cache size，而在策略与一致性保障：
- 务必使用
cache_mode=wt（write-through），禁用wb（write-back）——后者在断电后无法保证 cache device 与 origin device 一致，且 RHEL/CentOS 8+ 已默认移除wb支持 - metadata device 必须独立于 cache device（哪怕只是同一 SSD 的不同分区），否则元数据损坏将导致整个 LV 不可读
- 监控关键指标：
lvs -o +cache_read_hits,cache_write_hits,cache_dirty_blocks；若cache_dirty_blocks长期 >5%，说明 write-through 写压力过大，应考虑增大 cache device 或换用 faster storage
长期运行中如何安全替换 /dev/md0 RAID1 成员盘
RAID1 替换不是“拔掉旧盘插新盘”就完事。内核不会自动识别新盘为替代者，必须显式标记并等待同步完成：
- 先确认当前状态：
cat /proc/mdstat确保md0处于clean, degraded或active状态，无recovery进程正在运行 - 移除故障盘：
sudo mdadm --fail /dev/md0 /dev/sdb1→sudo mdadm --remove /dev/md0 /dev/sdb1 - 新盘分区后（保持相同
start和type），用sudo mdadm --add /dev/md0 /dev/sdc1加入；此时/proc/mdstat会显示recovery进程，勿中断 - 同步完成后运行
sudo mdadm --detail /dev/md0，确认所有 devices 状态为U（Up），且State :行不含spare或faulty
sudo mdadm --zero-superblock /dev/sdb1 sudo sgdisk -R /dev/sdc /dev/sdb # 复制分区表（含 GPT UUID） sudo partprobe /dev/sdb
最后一步常被跳过：若新盘未重置 superblock 或复制 UUID，下次重启可能被误识别为原盘镜像，引发启动失败。
