resize2fs 报错“filesystem is mounted”是因设计不允许直接扩容已挂载文件系统；须先扩大底层设备（如lvextend或growpart），再执行resize2fs，且需用partprobe刷新内核分区缓存。
resize2fs 报错 “The filesystem is mounted” 怎么办
直接运行 resize2fs 扩容已挂载的 ext4 文件系统会失败，这是设计使然——它不允许在读写状态下修改底层块组结构。必须先扩大底层块设备（如 LVM 逻辑卷、云盘分区），再让 resize2fs 识别新空间。
- 先确认文件系统是否挂载：
mount | grep /dev/vda1，如果输出中有对应行，说明已挂载 - 扩容前务必确保底层设备已变大：比如用
lvextend -L +10G /dev/vg0/lv_root拉伸逻辑卷，或云平台完成磁盘扩容后执行growpart /dev/vda 1 - 只有当
lsblk显示分区大小已更新，且df -h仍显示旧容量时，才轮到resize2fs出场
resize2fs 不加参数和加 -M 有什么区别
resize2fs 默认行为是“撑满整个底层设备”，也就是把文件系统扩展到分区/逻辑卷的全部可用空间；而加 -M 是反向操作：收缩到最小可能尺寸（仅容纳当前数据）。日常扩容几乎不用 -M，但它在备份前压缩镜像、或为后续缩小分区做准备时有用。
- 正常扩容：直接
resize2fs /dev/vda1（自动撑满） - 强制指定大小：如
resize2fs /dev/vda1 20G，注意单位必须是 K/M/G/T，且不能小于当前已用空间 -
-M后需配合e2fsck -f强制检查，否则可能报错 “filesystem has errors”
resize2fs 后 df -h 不变？是不是没生效
大概率是漏了关键一步：resize2fs 只改文件系统元数据，不刷新内核对块设备大小的认知。特别是用 growpart 扩展分区后，内核缓存的分区表可能未更新。
- 运行
partprobe /dev/vda或echo 1 > /sys/class/block/vda/device/rescan刷新分区信息 - 检查
cat /proc/partitions | grep vda1，看第二列数字（扇区数）是否已增大 - 若用 LVM，确认
pvs和lvs输出中 PV/LV 大小已同步，否则resize2fs看不到新空间
ext4 在线扩容安全吗？哪些情况必须 umount
ext4 支持在线扩容（即挂载状态下运行 resize2fs），但仅限“扩大”，不支持在线缩小。只要底层块设备已就位，且文件系统无损坏，过程是安全的。
- 必须 umount 的场景：要缩小文件系统（
resize2fs /dev/vda1 10G）、或文件系统报错（e2fsck提示需要修复） - 在线扩容期间可继续读写，但建议避开高 IO 时段，避免 resize 过程中因日志刷盘延迟引发短暂卡顿
- 某些旧内核（如 2.6.32）对在线 resize 支持不稳，遇到
Operation not supported错误时，先升级 kernel 或改用 offline 方式
stat() 看到的设备大小。所以出问题，八成不是 resize2fs 的锅，而是前面某步没到位。 
