在 gparted live 中调整分区大小时，内核遇到了 GPF，迫使我重新启动机器。（dmesg 在这里https://pastebin.com/LGqXA3p9）。碰巧的是，被移动的分区位于 md RAID5 阵列上，与系统启动完全无关，这意味着我可以重新启动并继续运行，并能够进行更多的探索。
运行 dumpef2s 会产生“dumpe2fs：读取日志超级块时范围头损坏”，并且 fsck.ext4 会显示“超级块有一个无效日志（inode 8）”。我还没有清除它。testdisk 只看到新分区，看不到任何文件；Photorec 带来的麻烦比它本身的价值更大。Testdisk 只显示一个移动了一半的文件，没有其他内容。
resize2fs 工具发出的最后一条消息是“节点 279256 / 593596231”，我不确定该如何解释。有没有办法利用未移动的文件系统数据？
答案1
在深入挖掘之后，我很幸运——一个名为 r-studio 的（专有）工具找到了文件系统超级块——e2image 尚未覆盖原始文件系统。有了扇区号，我能够简单地重新创建旧分区，发现根本没有数据丢失。我正试图通过 grep 查找卷中我仍有的 UUID，这与上述工具大致相同，但手动完成。不用说，我已经对文件系统元数据进行了 e2image 备份，并将调查 gparted 失败的原因。