マウントしないBTRFSパーティションを回復するにはどうすればよいですか？
12.04のインストールは失敗し続け、解決策は、以前に/ homeに使用していたbtrfsパーティションをインストーラーに無視させることでした。
インストールが完了したので、70GBのファイルにアクセスできるように、btrfsパーティションをマウントするように試みました。マウントされず、次の3行でbtrfsckエラーが発生します。
parent transid verify failed on 31302336512 wanted 62455 found 62456
parent transid verify failed on 31302336512 wanted 62455 found 62456
parent transid verify failed on 31302336512 wanted 62455 found 62456
このパーティションを機能させる方法を教えてください。私はオンラインで、おそらくbtrfs-restoreを使用してデータを回復できることを読みましたが、そのプログラムはどこにも見つかりません。
最も簡単な方法
btrfs-zero-log /dev/sda5
トランザクション（書き込みまたは削除）がジャーナルログに残っており、ディスクがそれに一致しないため、その問題が発生します。
使い方：
そのため、データが最初にジャーナルに書き込まれ、次にディスクに書き込まれます（または同時に、ジャーナルは今後の書き込みに関するメタデータを保存するだけです-確かではありません...その部分についてさらに調査が必要です）...
とにかく、この書き込み/削除の途中でシステムの電源を切るか、何かをシステムに接続する（btrfsマウントポイントを保持しているUSBを取り外す）と、そのマウントが機能しないと返されると失敗します（dmesgおよびbtrfsckは、エラーをより詳細に表示します）...
Dmesgを見ると、それらと同じtransidメッセージが表示されます。
次のようなものが表示されます。
parent transid verify failed on 109973766144 wanted 1823 found 1821
これは、btrfsがtransif 1826（ジャーナル上にあった）を望んでいたことを意味しますが、ディスク上では1821が見られました。したがって、ディスクはジャーナルと同期していない2トランザクションでした。私は個人的にここでbrtfs-zero-logを危険にさらすのは、たった2つのトランザクションがあるからです。ただし、これが唯一のデータである場合は100％安全です（重要なデータがある場合は、コピーを1つだけにして、他の安全な場所に常にコピー/バックアップを作成します-btrfsの作成者を非難しますバックアップを持っていないことに対する責任の欠如を正当化する-btrfsはバックアップソリューションではなく、ファイルシステムです-コピーや他の場所を持っている以外に真のバックアップソリューションはありません-パリティドライブやミラードライブでさえも、真のバックアップはありませんアクティブコピーがテキサスのオフィスにある間、アルプスの地下のどこかに座っている）
parent transid verify failed on 31302336512 wanted 62455 found 62456
ここでは、ジャーナルは62455を必要としていますが、ディスクは62456で1つ先にあるため、あなたの場合、ジャーナルをクリアするだけです。ジャーナルは今回は更新しませんでした。繰り返しますが、あなたのデータがあなたの唯一のデータであり、非常に重要な場合（あなたに恥を知れ）、安全なものであることを伝え、安全のために最初に以下の操作を行います。
Btrfsck/dev/sda5（ちなみに読み取り専用のチェックを行うだけなので、完全に安全で、心配する必要がある唯一のbtrfsckオプション）を実行すると、これらのメッセージも表示されます。
しかし、そのデータが重要な場合は、最初に行うことに注意してください（他の男性が言ったように）
mount -t btrfs -o rootflags=recovery,nospace_cache /dev/sda3 /mnt/sda3
mount -t btrfs -o rootflags=recovery,nospace_cache,clear_cache /dev/sda3 /mnt/sda3
mount -t btrfs -o recovery,nospace_cache,nospace_cache /dev/sda3 /mnt/sda3
次に、すべてのファイルを安全な場所にcpまたはrsyncし、安全なときにbtrfs-zero-logを実行し、操作が成功した場合はシステムのバックアップにかなりの時間を無駄にしました（しかし、成功しなかった場合は、 arse）
その後、マウントが失敗した場合、btrfs復元を実行します（システムのダンプ、私はその再開可能な操作を理解していますが、時々Yまたはyを要求し続けるので、出力を監視します）
btrfs restore /dev/sda5 /USB
その後、安全な場合（btrfsの復元が完了したとき）、btrfs-zero-logを実行します。操作が成功した場合は、システムのバックアップに多くの時間を無駄にしました（ただし、成功しなかった場合は、arseを保存しました）
最初に画面を実行できます
screen /bin/bash
btrfs restore /dev/sda5 /USB
スクリーンサイドノート
デタッチするには（コマンドは引き続き実行されます）：CONTROL-a次に引用符なしで「：detach」と入力し、Enterキーを押します
別のデタッチ方法：その後、PuTTYまたはターミナルを閉じてデタッチします（コマンド/復元は引き続き実行されます）。
それを確認するには、スクリーンに戻ってください：
screen -x
screen -xは、デタッチされていてもセッションにアタッチし、-hとは異なり、すでにアタッチされていてもアタッチされます）
複数の画面がある場合、画面-xは、セッションにアタッチするためにより具体的にする必要があることを示します。
screen -ls
すべてのセッションを一覧表示するためのls、覚えやすい。
pIDを表示するには、これも実行できます。
ps aux | grep screen
PIDを確認したら、次のような画面を実行します。
screen -x PID
特定のセッションにアタッチされます。同じ画面に複数のセッション/パテを接続できます（同じテキストを出力し、1つにコマンドを入力でき、他のPuTTYにミラーリングされます）
ルートfsマウントオプションを使用してブート時にマウントします。
rootflags=recovery,nospace_cache
または
rootflags=recovery,nospace_cache,clear_cache
Btrfsマウントオプションの完全なリストはここにある必要があります https://btrfs.wiki.kernel.org/index.php/Mount_options およびnoatime、nodatacow（修正済みファイルをコピーする機会を与えてくれるカーネルバグ）。
Grub.cfg/menu.lstに追加するか、起動時に入力します。
Nospace_cacheスタッフは物事をものすごく遅くします。起動し、（長く）待機し、シャットダウンして、通常どおり起動します。
数日前に同じことがありましたが、上記で修正しました。しかし、その後、いくつかのスペースの問題もありました...報告されたスペースは100％ではありませんが、スペースが不足していると言うことができます。
==
たとえば、fstabに同じオプションを追加することもできます。
UUID=0237alksfadg-lhdfkj3624-4fdfjb-9dsfe2d-dfddaf /home btrfs defaults,recovery,nospace_cache,clear_cache,subvol=@home 0
2
UUID=0237alksfadg-lhdfkj3624-4fdfjb-9dsfe2d-dfddafでパーティション上にマウントされた/ homeディレクトリを回復しようとした場合。
同じ問題がありました。再起動後、btrfsパーティションをマウントできなくなりました。ただし、ここで説明した解決策では解決できませんでした。
私にとってそれを修正したのは、カーネルを3.10から3.12にアップグレードすることでした。再起動後、btrfsパーティションを再度マウントできます。
mount -t btrfs -o ro,nospace_cache,nospace_cache /dev/sda3 /mnt/sda3
ro =読み取り専用
私のためのこの仕事
ピーターの答えは、Ubuntuではありませんが、問題を解決しました。もちろん、破損した/homeパーティションbtrfsがありました。 fstabにあるため、システムは起動しません。メンテナンスモードに入り、そのパーティションの行をハッシュし、正常に起動しました（/homeとして使用できる予備のext4パーティションがありました）。
次のコマンドでパーティションを手動でマウントしました：
mount -t btrfs -o recovery,nospace_cache,nospace_cache /dev/sda3 /mnt/sda3で、実際にデータを保存できました。マウントするのにそれほど時間はかかりませんでしたが。ピーターに感謝します。