gparted live内でパーティションのサイズを変更しているときに、カーネルがGPFに遭遇し、マシンを再起動する必要がありました。(dmesgはこちらhttps://pastebin.com/LGqXA3p9) 偶然にも、移動されたパーティションは md RAID5 アレイ上にあり、システムの起動にはまったく関係がありませんでした。つまり、私は元に戻って稼働しており、さらにいろいろと調べることができるのです。
dumpef2s を実行すると、「dumpe2fs: ジャーナル スーパー ブロックの読み取り中にエクステント ヘッダーが破損しました」というメッセージが表示され、fsck.ext4 では「スーパーブロックに無効なジャーナル (inode 8) があります」と表示されます。まだこのメッセージはクリアしていません。testdisk では新しいパーティションのみが表示され、ファイルは表示されません。Photorec は手間がかかるので、価値がありません。testdisk では、移動途中のファイルのみが表示され、他には何も表示されません。
resize2fs ツールからの最後のメッセージは「node 279256 / 593596231」でしたが、これをどう解釈すればよいかわかりません。移動されていないファイルシステム データにアクセスする方法はありますか?
答え1
表面下を掘り下げた後、幸運にも、r-studio という (独自の) ツールがファイル システムのスーパー ブロックを見つけました。e2image はまだ元のファイル システムを上書きしていませんでした。セクター番号を武器に、古いパーティションを再作成するだけで、データ損失はまったくありませんでした。ボリューム全体を grep して、まだ保持している UUID を探そうとしていましたが、これは前述のツールではなく、ほぼ同じアプローチですが手動で行いました。言うまでもなく、ファイル システムのメタデータの e2image バックアップを作成しており、gparted が失敗した理由を調査する予定です。