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 核对过设备号——这些动作没有日志自动记录，全靠人盯住。
