扩容前须先定位真实瓶颈，区分日志堆积、临时文件或业务增长；按文件系统类型选择安全扩法：ext4需先扩底层设备并检查一致性，xfs仅支持在线扩且不可缩，btrfs平衡操作i/o压力大；所有操作必须备份、验证并准备回滚，避开lvm+xfs+root分区高危组合。
明确扩展前提：先确认是否真需要扩容
不是所有空间告警都该立刻扩容。先用 df -h 和 du -sh * 定位真实瓶颈——是日志堆积、临时文件未清理，还是业务数据持续增长？若 /var/log 占满 90%，清日志或轮转配置可能比扩盘更安全高效。盲目扩容反而掩盖运维疏漏。
文件系统类型决定扩展方式与风险等级
不同文件系统对在线扩容支持差异大：
- ext4：支持在线扩容（resize2fs），但需确保底层块设备（如LVM逻辑卷或云盘）已先扩大，且内核支持；扩容前建议 e2fsck -f 检查一致性
- XFS：仅支持在线扩容（xfs_growfs），不支持缩容；必须确保挂载时未启用 inode64 且元数据无损坏，否则 grow 可能失败甚至导致只读挂载
- Btrfs：支持在线增删设备和平衡（balance），但 balance 过程中 I/O 压力高，且遇坏块可能中断；不建议在生产环境直接对单设备 btrfs 扩容
关键操作必须做三件事：备份、验证、回滚预案
任何容量扩展都涉及元数据修改，风险不可逆：
- 执行前对关键数据做快照（LVM lvcreate --snapshot 或云平台磁盘快照），非快照备份至少保留一份离线副本
- 扩容后立即运行 df -h、lsblk、mount | grep 设备名 验证大小、挂载点、读写状态；对数据库等应用，还需检查服务日志有无 “filesystem full” 类报错残留
- 准备回滚步骤——例如 LVM 场景下记录原始 LV 大小（lvs 输出），XFS 场景下确认未执行过 xfs_info 异常输出；若扩容失败，能快速切到备用实例或恢复快照
避开高危组合：LVM + XFS + root 分区在线扩
该组合看似灵活，实则风险集中：
- root 分区无法卸载，XFS 不允许 offline resize，全依赖在线流程；一旦 resize 过程中发生断电或 OOM，可能造成根文件系统只读锁定，机器无法重启
- LVM 的 PV 扩展需同步更新内核设备映射（kpartx 或 partprobe），部分旧内核版本存在识别延迟，导致 resize2fs 报 “device is busy”
- 建议策略：root 分区避免在线扩；优先用独立 /data 或 /home 分区承载增长型数据，并在部署初期预留 20%~30% 空间余量
