df -Th 显示容量与 lvextend 不一致是因为 LVM 仅更新逻辑卷大小，而 XFS 需用 xfs_growfs / 挂载点、ext4 需用 resize2fs / 设备路径显式扩展文件系统，否则文件系统无法识别新增空间。

df -Th 显示容量为何与 lvextend 中断

执行 lvextend 后，df -Th 仍然显示旧容量，不是扩容失败，但是文件系统没同步扩展。LVM只改了逻辑卷大小，XFS或ext4都不知道“出来多的空间归我管”。必须显式调用扩容命令，不然磁盘空间就卡那儿不动。XFS文件系统必须用xfs_growfs /（挂载点路径），不能对设备如/dev/mapper/centos-root操作ext4必须用resize2fs /dev/mapper/centos-root，且该设备必须已挂载（在线调整大小支持）如果 xfs_growfs 报“cannot Growth filesystem with proto version 5”，说明内核或 xfsprogs 版本太低，需升级 lsblk 和 lvs 输出怎么看哪个是“真实空间”

lsblk块结构：物理卷 → 卷组 → 逻辑卷 → 挂载点，它反映 LVM 的当前分配状态；lvs 则只聚焦逻辑卷的 LV Size 字段，这个值才是 lvextend 真正生效后的逻辑卷大小——相当于“磁盘层容量”。但注意：它并不等于可用空间，因为文件系统尚未认领。lsblk 中 centos-root 行的 SIZE 列 = lvs 输出的 LV Size = 逻辑卷实际大小（LVM 层）df -Th 中 / 行的 Avail 列 = 文件系统真正能写入的空间（用户可视层）三者数值不同很正常，关键看 df -Th 是否已更新——这就是最终“真实详情”扩容后验证是否彻底生效的三个必查项

别只信 df，要交叉确认三层状态是否全部一致，否则可能存在漏掉某步导致空间“但不可用”。 PyCharm 2026.2.0.1 Linux 版

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

下载运行 pvs && vgs && lvs：确认新 PV 已加入 VG，LV Size 已增大，且没有“Alloc PE”异常过剩运行 df -Th /：挂载点容量必须与 lvs 的 LV Size 一致（XFS 下允许气压 ≤1MB；ext4 通常完全是）运行 xfs_info /（XFS）或une2fs -l /dev/mapper/centos-root | grep "Block count"（ext4）：直接读取文件系统元数据中的块总数，这是最底层的真实容量证明为什么df显示容量变大了，但du统计总并没有增加

du -sh /* 总和远小于df可用空间，不是扩容错误，而是正常现象。原因包括：已删除但未释放的文件（进程仍打开）、.snapshots、journal日志、保留块（ext4默认保留） 5%）、以及XFS的实时损耗或reflink共享块附着度计入。检查大文件残留：lsof +L1查看被但删除仍被进程占用的文件清理日志：journalctl --disk-usage → Journalctl --vacuum-size=500MXFS用户注意：xfs_db -r -c "freesp -s" /dev/mapper/centos-root才能查真正空闲块数，比 df 更准文件系统层和LVM层的容量是两套独立状态，中间差着一次手动同步命令。很多人卡在“明明lvextend了却看不到成功空间”，问题几乎全出在忘记跑xfs_growfs或resize2fs——这步不做，扩容就只完成了一半。