xfs_growfs在线扩展XFS文件系统需先确保底层设备扩容并更新分区表或LVM逻辑卷，再执行xfs_growfs /mnt/data；它仅作用于已挂载的XFS文件系统，不修改分区表，依赖内核块层返回的设备大小。
能在线扩展，但必须确保底层分区或逻辑卷已先扩容，xfs_growfs 本身不改分区表，只管文件系统层。
确认 XFS 文件系统是否已挂载且底层有空闲空间
在线扩展的前提是：文件系统必须已挂载，且对应设备（如 /dev/vda1、/dev/mapper/vg-lv）的容量已变大。如果磁盘在云平台或虚拟机里扩容了，但系统还没识别新大小，xfs_growfs 会报错或无效果。
- 运行
df -hT /mnt/data确认挂载点和类型（输出中 Type 应为xfs） - 运行
lsblk对比设备大小和挂载点大小——若设备显示 100G 但df还是 50G，说明分区表没更新 - 对物理盘（如
/dev/vda）需先刷新识别：echo 1 > /sys/class/block/vda/device/rescan - 对 LVM 逻辑卷，确认
lvdisplay显示 LV 大小已更新；否则得先lvextend
用 growpart 扩展分区（非 LVM 场景下必做）
如果你用的是传统分区（比如 /dev/sdb1），而磁盘扩容后只是设备总大小变了，分区表仍指向旧边界，xfs_growfs 就扩不动——它读到的还是老分区大小。
- 安装工具：
yum install -y cloud-utils-growpart（CentOS/RHEL）或apt install -y cloud-guest-utils（Debian/Ubuntu） - 扩展分区（例如把
/dev/sdb的第 1 个分区拉满）：growpart /dev/sdb 1 - 注意：
growpart只支持 MBR/GPT 下的连续空闲空间；若分区后面紧挨着 swap 或其他分区，会失败 - 验证：
lsblk应看到sdb1的 SIZE 已增大，且与sdb一致
执行 xfs_growfs 扩容文件系统
xfs_growfs 接收的是挂载点（推荐）或设备路径，不是分区名。它自动读取底层设备当前大小并填充，无需指定目标容量（除非你要限制大小）。
- 扩到最大可用空间（最常用）：
xfs_growfs /mnt/data - 指定设备路径也可行（尤其挂载点异常时）：
xfs_growfs /dev/mapper/vg-lv_data - 想扩到精确大小（如 200G）：
xfs_growfs -D 200G /mnt/data（注意：单位 G 表示 GiB，且底层设备必须 ≥200G） - 试运行看计划：
xfs_growfs -t /mnt/data，不会修改任何数据 - 错误提示
cannot grow filesystem with mounted attr2 option？说明内核或 mkfs.xfs 版本太老，需升级或重建文件系统
验证结果与常见失效原因
执行完 xfs_growfs 后，df -h 应立刻反映新容量。如果没变，90% 是卡在前置步骤。
-
df不变但lsblk已变 → 分区没扩（漏了growpart或partprobe） -
lsblk和df都不变 → 磁盘根本没扩容（云平台控制台没操作，或虚拟机没关机+重启 SCSI 总线） - 报错
Invalid argument→ 设备路径写错，或文件系统损坏（先xfs_repair -n检查） - 根分区（
/）扩容失败？检查/dev下设备名是否匹配（如 NVMe 盘是/dev/nvme0n1p2，不是sda2）
真正容易被忽略的是：xfs_growfs 从不主动刷新设备容量视图，它完全信任 ioctl(BLKGETSIZE64) 返回的值。这个值由内核块层维护，而块层只在磁盘 rescan、分区表重读或设备重置后更新——所以别跳过 growpart 或 rescan 步骤。
