df -h 显示容量未更新，说明文件系统尚未扩展，需依次确认分区表更新、内核重读、lvm扩展（如适用）及执行resize2fs或xfs_growfs。

df -h 显示的容量没变，但扩容操作已执行

扩容后 df -h 仍显示旧容量，说明文件系统尚未实际扩展——分区表可能已更新，但内核未重读或文件系统未 resize。这不是“没生效”，而是卡在最后一步。

• 先确认挂载点是否被占用：lsof +D /mount/point 或 fuser -v /mount/point，有进程占用会导致 resize2fs 或 xfs_growfs 拒绝操作
• 检查文件系统类型：findmnt -T /mount/point -o SOURCE,FSTYPE，结果决定用哪个工具（ext4 → resize2fs；xfs → xfs_growfs）
• 若为 LVM 逻辑卷，需先确认 LV 是否已扩展：lvdisplay /dev/vgname/lvname，LV 容量没变就别急着跑 resize2fs

resize2fs 后 df -h 还是旧值？检查 ext 文件系统状态

resize2fs 执行成功但 df -h 不更新，常见于未卸载且文件系统处于“clean”状态但内核缓存未刷新。不需要重启，但必须确保操作对象正确。

PyCharm 2026.2.0.1 Linux版

PyCharm 2026.2.0.1 Linux版提供 JetBrains 官方 2026.2.0.1 版本安装包，适合需要指定 PyCharm 版本进行 Python 项目开发、运行和调试的用户。

下载

• 运行 resize2fs /dev/sdXN（不是挂载点路径，是设备文件，如 /dev/sdb1）
• 若提示 “The filesystem is mounted; resize forced running” —— 强制在线 resize 是允许的，但仅限 ext3/ext4，且要求内核支持（≥2.6.10）
• 执行后立即运行 sudo dumpe2fs -h /dev/sdXN | grep -i "block count\|block size"，对比扩容前后的 Block count，确认底层结构已变更
• 再跑一次 df -h；若仍不对，尝试 sudo sync && echo 3 > /proc/sys/vm/drop_caches 清缓存（仅临时生效，不影响数据）

xfs_growfs 报错 “data size unchanged”，但磁盘已扩容

xfs_growfs 要求底层块设备容量已更新，且挂载点必须可写。它不操作分区表，只调整文件系统元数据。报这个错，基本等于“设备没变大”。

• 确认设备容量真实增长：blockdev --getsize64 /dev/sdX（单位字节），对比扩容前数值
• 若值未变，说明 SCSI 设备未 rescan：echo 1 > /sys/class/scsi_device/*/device/rescan（先 ls /sys/class/scsi_device/ 找对路径）
• 若使用 LVM，检查 PV 是否已扩展：pvs 看 PSize 和 PFree，没变化就先 pvresize /dev/sdXN
• xfs_growfs 必须指定挂载点（如 /mnt/data），不能指定设备名，否则报错

fdisk -l 显示新容量，但 lsblk 不显示新分区

fdisk -l 看到磁盘总大小变大，但 lsblk 的输出里对应设备下没有新增分区或分区大小没变——说明分区表未写入或内核未重读。

• 执行 partprobe /dev/sdX（不是 partprobe 全局扫描，指定设备更安全）
• 若报错 “Device or resource busy”，说明分区正被使用（尤其是根分区或 swap），此时 partx -u /dev/sdX 更可靠
• 验证分区是否生效：cat /proc/partitions | grep sdX，看末尾数字（如 sdb1 对应行）的大小是否更新
• 某些云环境（如 AWS、华为云）扩容后必须先 growpart /dev/sdX 1 才能拉伸分区，否则 resize2fs 无可用空间可扩

扩容真正完成的标志不是“命令没报错”，而是 df -h 和 lsblk 两处数值一致且匹配预期。中间任何一环断开（SCSI rescan → 分区拉伸 → LV 扩展 → 文件系统 resize），都会卡在某个环节不动。最常被跳过的其实是 growpart 或 partprobe，而不是最后的 resize 命令。