中断されたサイズ変更からEXT4パーティションを回復する
世界！ [それは面白い、それは自動的に主要な「ハロー」を取り除く]
友人のラップトップにUbuntuをインストールしていますが、Ubuntuパーティションのサイズ変更中に問題が発生しました。私はそれを左に移動（移動およびサイズ変更）していましたが、実際のデータコピーの実行中にプロセスが中断されました。 GPartedは、パーティションが破損しており、ファイルシステムを読み取ることができないと言います。今、私は再インストールを心配していません。問題は、Windowsパーティションからいくつかのファイルを既にコピーしていたことです。
コピープロセスを再開するにはどうすればよいですか？ GPartedがそれについて言っていることは次のとおりです。
Filesystem volume name: <none>
Last mounted on: /
Filesystem UUID: [tl;dt]
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal_ext_attr_resize_inode dir_index filetype extent flex_bg sparse_super large_file
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 1155072
Block count: 4619008
Reserved block count: 230950
Free blocks: 764535
Free inodes: 968259
First block: 0
Block size: 4096
Fragment size: 4069
Reserved GDT blocks: 1022
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
Flex block group size: 16
...
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
...
Journal superblock magic number invalid!
Unable to read the contents of this filesystem!
...
興味深いのは、has_journal_ext_attr_resize_inodeの下のFilesystem features属性です。サイズ変更の最中であることがわかっているようです。ただの推測。
できません。ファイルシステムはトーストです。
移動を再開するには、中断されたときにプロセスのどこにいたかを正確に知る必要があります。
機能に関しては、下線がないところにアンダースコアを挿入したと思います。 has_journal、ext_attr、およびresize_inodeは個別の機能です。 1つ目は、メタデータの更新をfsに記録するext3/4ジャーナルで、クラッシュ後すぐに回復できるようにします。 2番目は拡張属性が有効であることを意味し、3番目はfsがまだマウントされている間に拡張できることを意味します。それらのいずれも、パーティションのgpartedの移動とは関係ありません。
唯一の希望はphotorecです。これは、名前やメタデータがなくても、someファイルを別のディスクに復元できる場合があります。
私はあなたがそこで何をしたか正確にはわかりません。ファイルシステムを拡張しただけですか、それともパーティションも移動しましたか？サイズ変更中にそのパーティションにファイルをコピーしていませんか？これは非常に悪い考えです。同時に削除しようとしていたWindowsパーティションのファイルですか？これは本当に紛らわしいです。
ファイルシステムの回復を試みているだけで、スーパーブロックが不良である場合、事態を悪化させないために、最初にドライブのバックアップと破損したファイルシステムのダンプを作成します。これを試すより： Linux：Find Alternative Superblocks