先确认文件系统类型和挂载点：用df -ht看类型（ext4/xfs）与挂载路径，用lsblk -f查设备树、fstype及是否lvm；ext4需先扩分区再resize2fs，xfs必须用xfs_growfs且参数为挂载点而非设备路径。
先看清楚你面对的是哪种扩容场景，再选对应命令——不是所有“扩容”都叫 resize2fs 或 xfs_growfs，错用会卡住甚至报错。
怎么快速确认文件系统类型和挂载点
别猜，直接查。两个命令够用：
-
df -hT：看挂载点、类型（ext4/xfs）、容量，重点关注你目标目录那一行 -
lsblk -f：看设备树、FSTYPE列、MOUNTPOINT，还能顺带发现有没有 LVM 层（TYPE显示lvm）
如果 df -hT 显示某挂载点是 xfs，但 lsblk -f 里对应设备是 /dev/mapper/vg00-lv_root，说明它走 LVM，后面要先扩 LV 再扩 FS；如果是 /dev/sda1 直接挂载，就属于基础分区扩容路径。
ext4 分区扩容必须分两步：先扩分区，再跑 resize2fs
resize2fs 只管文件系统，不管底层分区大小。如果你跳过分区扩容直接跑它，它只会告诉你 “The filesystem is already xx blocks long. Nothing to do!” —— 看似成功，实则没加任何空间。
- 非 LVM 场景（如
/dev/sda1）：先用fdisk或parted删除重建分区（起始扇区必须严格一致），再执行partprobe /dev/sda或重启内核识别新布局 - 云环境（如 AWS/阿里云）：控制台扩容磁盘后，必须用
growpart /dev/sda 1扩分区，再resize2fs /dev/sda1 - LVM 场景：跳过分区步骤，直接
lvextend -L +5G /dev/vg00/lv_root，然后resize2fs /dev/vg00/lv_root
注意：resize2fs 在 ext4 上支持在线扩容（不用 umount），但前提是内核已识别到新分区大小——这点常被忽略。
xfs 文件系统只能用 xfs_growfs，且必须指定挂载点
xfs_growfs 不接受设备路径（比如 /dev/sda1），只认挂载点路径（比如 / 或 /data）。输错直接报 invalid argument。
- 正确写法：
xfs_growfs /（根目录）或xfs_growfs /mnt/data - 错误写法：
xfs_growfs /dev/sda1（报错）、xfs_growfs /dev/mapper/vg00-lv_data（也报错） - 它不关心底层是物理分区还是 LVM，只要内核已识别新容量、文件系统已挂载，就能在线扩展
如果扩容后 df -h 没变，大概率是忘了先用 growpart 或 lvextend 把底层块设备撑开。
扩容失败时最该检查的三件事
90% 的“扩容无效”问题出在这三个地方：
- 没在云控制台真正扩容磁盘——
lsblk显示的 SIZE 没变，后面全白忙 - 扩容后没刷新内核对分区表的认知：物理机需
partprobe，云服务器常用echo 1 > /sys/class/block/vda/device/rescan - 误把 LVM 逻辑卷当普通分区处理：看到
/dev/vda2就去fdisk /dev/vda，其实该查lvdisplay然后lvextend
真正麻烦的永远不是命令本身，而是你没看清当前存储栈到底有几层：裸盘 → 分区 → LVM → 逻辑卷 → 文件系统 → 挂载点。漏掉任意一层，命令就只是在原地打转。
