問題が発生しました。一部のパッケージをインストールした後、openSUSE Tumbleweedシステムの更新が失敗し、/ varが読み取り専用ファイルシステムであると主張しました。
以前のスナップショットに戻り、/ varが読み取り専用でないことをテストした後、更新を再実行し、いくつかのエラーメッセージの後に読み取り専用に戻りました。
これ質問のために開始メッセージを確認しましたが、BTRFSに問題があることを知りませんか？
[ 231.762975] BTRFS info (device sda2): scrub: started on devid 1
[ 287.021834] BTRFS error (device sda2): parent transid verify failed on 31572885504 wanted 278272 found 278280
[ 287.060064] BTRFS info (device sda2): scrub: not finished on devid 1 with status: -5
[ 643.134491] BTRFS info (device sda2): qgroup scan completed (inconsistency flag cleared)
[ 971.347644] BTRFS info (device sda2): scrub: started on devid 1
[ 1026.335159] BTRFS error (device sda2): parent transid verify failed on 31572885504 wanted 278272 found 278280
[ 1026.374518] BTRFS info (device sda2): scrub: not finished on devid 1 with status: -5
最後の3行についてもう一度繰り返します。以前のスナップショットに切り替えても影響を与えないように見えるため、これはファイルシステムの内容に対する最近の変更ではなく、途中で中断された可能性があります。しばらくの周りにいたか、何か違うものです。
クリーンアップしようとしましたが、I / Oエラーのため、1分間（約14GiB）プロセスが終了します。
> sudo btrfs scrub start -B /dev/sda2
ERROR: scrubbing /dev/sda2 failed for device id 1: ret=-1, errno=5 (Input/output error)
scrub canceled for 8b283f24-277b-4cf8-8d87-6107bca1ef57
Scrub started: Wed Jul 15 14:20:22 2020
Status: aborted
Duration: 0:00:55
Total to scrub: 60.00GiB
Rate: 183.09MiB/s
Error summary: no errors found
もしそうなら、エラーは見つかりませんでしたが、I / Oエラーによって中断されましたか？あるようです。以前は結局それは間違いだった。
ドライブのSMART状態をテストしましたが、私が知っている限り完璧に大丈夫だと思います。ドライブの寿命は約2700時間なので、摩耗が激しいとは予想されません。
もう少し検索して見つけました。これバックアップからディスクの内容を交換することをお勧めします。これは私のプライマリシステムパーティションなので、パーティション全体がマウントされたくないのです。最近の部分複製バックアップがありますが、エラーがあります（しばらくエラーがあった可能性があります）。さらに：アップデートを試みない限り、私のシステムはうまくいくので、何とか回復できますか？
csumエラーのみを確認してください。
> sudo btrfs check --check-data-csum /dev/sda2
Opening filesystem to check...
WARNING: filesystem mounted, continuing because of --force
Checking filesystem on /dev/sda2
UUID: 8b283f24-277b-4cf8-8d87-6107bca1ef57
[1/7] checking root items
[2/7] checking extents
parent transid verify failed on 31572885504 wanted 278272 found 278280
parent transid verify failed on 31572885504 wanted 278272 found 278280
Ignoring transid failure
[3/7] checking free space cache
[4/7] checking fs roots
parent transid verify failed on 31572885504 wanted 278272 found 278280
Ignoring transid failure
parent transid verify failed on 31572885504 wanted 278272 found 278280
Ignoring transid failure
parent transid verify failed on 31572885504 wanted 278272 found 278280
Ignoring transid failure
root 259 inode 4735696 errors 800, odd csum item
root 259 inode 4746779 errors 800, odd csum item
root 259 inode 4747724 errors 800, odd csum item
parent transid verify failed on 31572885504 wanted 278272 found 278280
Ignoring transid failure
[... lots of repetitions of the previous two lines ...]
Ignoring transid failure
ERROR: errors found in fs roots
found 49867616256 bytes used, error(s) found
total csum bytes: 38229736
total tree bytes: 1010974720
total fs tree bytes: 895434752
total extent tree bytes: 57819136
btree space waste bytes: 215524051
file data blocks allocated: 869778038784
referenced 68509286400
ああ…それなら、1つのブロックだけがチェックサム問題の影響を受けるという意味ですか？これは単にファイルという意味ですか？それとも、「fs rootでエラーが検出されました」行がファイルシステムにさらに問題があることを示していますか？
私は見たこれゼロロギングが推奨されていますが、このコマンドは私のシステムまたは削除時にディスクをチェックするために使用したManjaro Liveシステムにはないようです。 suはもはや必要/サポートされていないと思いますか？それでも、ウィキペディアファイルシステムをマウントできる限り、ゼロログは役に立たず、私のログもマウントできると言います。しかしそれも言うbtrfsなしでチェック他のすべての方法が失敗しない限り、修理を実行してください。
私にとっては、他のすべての方法が実際に失敗したように見えますが、この問題を処理する他の方法を見落としているのか、それとも最初に何が間違っているのかを知ることはできません。
btrfs check --init-csum-treeそれでは（または？）でこの問題を解決する価値がありますか？btrfs check --repairまたは、システムを再インストールせずにこの問題を解決するためのより賢い方法はありますか？どのファイルが影響を受けているかを確認し、そのファイルを回復または再生成できることを確認しますか？
ベストアンサー1
どのファイルがtransidエラーの影響を受けているかを見つけるために見つけることができる他のすべての分析方法を実行しましたが、実際にはそれほど遠くはありませんでした。だから私はそれを使ってまだ読むことができbtrfs restore、ライブブートシステムで実行されているbtrfs check --repairすべてをバックアップしました。btrfs check --init-csum-treeこれによりエラー報告が削除されますが、空き領域がほとんど残りません。だから、良い測定のためにフォローアップを実行しましたbrfs balance（何度も実行する必要がありましたが、最初はusage=10空き容量が少なすぎるため、ほとんど空のブロック（）に制限されていました。 . しかし、一部のファイルが破損または欠落している影響を受けているいくつかのパッケージを削除/再インストールし、システム全体の更新を実行し、すべてが正常に動作しました。
このタイプのエラーが再び発生し、目立たなくなる可能性を減らすために、openSUSEで定期的にディスクをクリーンアップしてバランスをとるサービスを設定しました。それ以来、よく戻っています。私はこの種の衛生がBTRFSの一部になることを心から願っています。すべてのX書き込みをスクラブし、ブロックのY％を再割り当てしてバランスをとり、問題が発生した場合にフラグを上げます。あるいは、少なくともデフォルトでBTRFSを提供するディストリビューションには、同様のものが事前設定されている必要があります。 BTRFSを使用する人は誰でもそれを整理してバランスを取る必要があるからです。