OpenWrt 扩容实战：NVMe 分区已经扩大，但 df 显示空间不变
内容提要
OpenWrt扩容后df仍显示根目录仅122MB，原因是分区已扩容但ext4文件系统未扩容。resize2fs报错“reserved block 8 not at offset 7”，dmesg显示与resize_inode特性及保留GDT布局冲突。安装tune2fs后执行tune2fs -O^resize_inode移除该特性，再检查文件系统并重启，最后resize2fs成功扩容。经验：分区扩容不等于文件系统扩容，排错应结合dmesg内核日志。
延伸解读
分区与文件系统：扩容的两个独立步骤
文章清晰展示了扩容的两个层面：用 parted 调整分区边界，用 resize2fs 扩展 ext4 文件系统。只做前者，df 仍显示原容量。这提醒我们，在 Linux 中分区和文件系统是分开管理的，扩容后必须分别确认两者状态，避免误判。
dmesg 日志：定位扩容失败的关键
resize2fs 报错“Invalid argument”信息有限，但 dmesg 中的“reserved block 8 not at offset 7”直接指向 ext4 的 resize_inode 特性与保留 GDT 布局冲突。这说明内核日志能提供比用户态工具更底层的线索，排错时应优先查看。
移除 resize_inode 特性的风险与操作
解决方案是使用 tune2fs 移除 resize_inode 特性，再执行 e2fsck 和重启。文章特别指出，将根分区重新挂载为只读再检查，并不等同于从 Live USB 完全卸载后检查，生产设备更推荐离线检查并提前备份。这提示操作需谨慎。
OpenWrt 根文件系统的多样性
文章强调 OpenWrt 根目录不一定是 SquashFS，也可能直接使用 ext4。排查前应通过 /proc/mounts 和 /proc/cmdline 确认实际挂载情况，避免因预设错误而走弯路。此外，根分区满载时可利用 /tmp（tmpfs）暂存文件，但重启后丢失。
Q&A
OpenWrt 用 parted 扩容 NVMe 分区后，df 还是显示根目录只有 122MB，是什么原因？
因为 parted 只扩大了分区边界，但分区内的 ext4 文件系统并没有扩容。df 查看的是文件系统容量，所以仍显示原来的 122MB。需要再用 resize2fs 扩大文件系统。
resize2fs 扩容 ext4 时报错 'reserved block 8 not at offset 7' 怎么解决？
这是 ext4 的 resize_inode 特性与保留 GDT 布局冲突导致的。先安装 tune2fs，执行 tune2fs -O^resize_inode /dev/nvme0n1p2 移除该特性，然后 remount,ro 并运行 e2fsck -f -y 检查文件系统，重启后再执行 resize2fs 即可成功。
OpenWrt 根分区满了，无法安装 tune2fs，有什么临时办法？
可以先腾出一些根分区空间再安装。另外 OpenWrt 的 /tmp 通常挂载为 tmpfs（使用内存），可以把临时下载文件、备份文件放在 /tmp 下，但注意重启后内容会丢失。
如何确认 OpenWrt 的根文件系统是 ext4 而不是 SquashFS？
检查 cat /proc/mounts 看根挂载点类型，以及 cat /proc/cmdline 看 root= 参数。还可以用 awk '$5=="/"{print $3}' /proc/self/mountinfo 确认根设备。本文中根目录直接挂载在 /dev/nvme0n1p2 上，类型为 ext4。
parted print 显示分区有 14.4GB，但 df -h 显示很小，是磁盘故障吗？
不是。parted print 查看的是分区容量，df -h 查看的是文件系统容量，两者显示不同是正常的。分区扩大后文件系统不会自动扩大，需要用 resize2fs 扩展文件系统。
OpenWrt 扩容失败时，除了看 resize2fs 报错，还应该查什么？
应该结合 dmesg 查看 ext4 内核日志，例如 dmesg | grep -iE 'ext4|resize|nvme'。本文中正是通过 dmesg 发现 'reserved block 8 not at offset 7' 这一关键线索，才定位到 resize_inode 特性冲突。
