Linux存储运维稳定关键在变更可追溯、容量有余量、故障能自察；需排查df/du差异、合理配置挂载选项、优化rsync、用WWID绑定设备、监控LVM快照并规范操作。

Linux存储运维没有银弹，长期稳定运行的关键不在“配置多炫酷”，而在“变更可追溯、容量有余量、故障能自察”。以下是从百台生产服务器、五年无重大存储事故中沉淀出的实操要点。

df 和 du 差异大到报警？先查 noatime 和挂载选项

常见现象：df -h 显示根分区 98% 满，但 du -sh /* 2>/dev/null | sort -hr | head -5 加起来才 60GB——差值不是小数点误差，而是真实磁盘空间被“吃掉”了。

• 最常被忽略的是已删除但进程仍打开的文件：用 lsof +L1 查找处于 deleted 状态的句柄，重启对应服务或 kill 进程释放空间
• noatime 虽能减少 IO，但某些监控脚本依赖 atime 判断文件活跃度，误判会导致归档逻辑失效；生产环境建议用 relatime 替代
• XFS 文件系统启用 inode64 挂载选项后，xfs_info 显示的 agcount 可能影响大目录 ls 性能，不升级内核前勿在老硬件上盲目开启

rsync 同步大量小文件时卡在 “building file list”？别只加 -a

这个阶段本质是客户端扫描源目录生成文件列表，卡住说明 I/O 或内存受限，而非网络慢。

• 加 --files-from= 预先生成路径列表（用 find /src -type f -print0 | sort -z > list.txt），跳过递归扫描，提速 3–5 倍
• 禁用 -a 中的 -o（属主）和 -g（属组）：若目标端 UID/GID 映射不一致，会反复 stat 失败并重试，改用 -rltDv --chmod=Du=rwx,Dgo=rx,Fu=rw,Fgo=r
• 对超过 100 万文件的同步任务，务必加 --max-alloc=1G 限制 rsync 自身内存用量，否则可能触发 OOM Killer 杀掉其他关键进程

udev 规则写错导致 /dev/sd* 顺序乱？用 WWID 绑定才是正解

依赖 /dev/sdb 这类内核分配名做 LVM PV 或数据库裸设备，机器重启后设备名漂移是高频事故源头。

• 永远不用 SUBSYSTEM=="block", KERNEL=="sd*", PROGRAM="/bin/bash -c 'echo $kernel'" 这类不可靠匹配；应查 scsi_id --whitelisted --replace-whitespace --device=/dev/sda 得到 WWID（如 360050763008000000000000000000001）
• udev 规则中必须用 SYMLINK+="disk-db-primary" 而非 NAME="disk-db-primary"（后者已被废弃且无效）
• 规则生效后，检查 /dev/disk/by-id/wwn-0x 是否存在，并在 /etc/fstab 中直接引用该路径，避免任何中间层解析

LVM 快照撑爆 VG？监控不能只看 lv_size

快照逻辑卷（snapshot LV）本身不存数据，但其 COW（copy-on-write）元数据区会随原 LV 修改增长。一旦耗尽所在 VG 的剩余 PE，整个 VG 冻结，连 lvremove 都执行不了。

• 监控指标必须包含：lvs -o lv_name,origin,snap_percent,vg_free，尤其关注 snap_percent 超过 70% 的快照
• 创建快照时强制指定大小：lvcreate -s -L 5G -n snap_web /dev/vg0/www，绝不依赖默认（通常是原 LV 的 100%，极易误判）
• 快照仅用于短时备份或测试，上线系统严禁用快照替代备份；lvconvert --merge 要求原 LV 未激活，合并前需停服务或卸载文件系统

真正难的不是命令怎么敲，而是每次 lvextend 前是否确认过文件系统支持在线扩容，每次 umount 前是否验证过 NFS 客户端已全部断开，每次 dd if=/dev/zero 清盘前是否 blkid 核对过设备号——这些动作没有日志自动记录，全靠人盯住。