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 方式

事情说清了就结束。真正容易被忽略的是：resize2fs 本身不碰分区表，也不管底层设备有没有变大——它只信 stat() 看到的设备大小。所以出问题，八成不是 resize2fs 的锅，而是前面某步没到位。