web-dev-qa-db-ja.com

BTRFSの修正不可能なエラーを含むファイルの検索

BTRFSファイルシステムの回復不可能なエラーについて質問があります。具体的には、最近RAMスティックの1つに問題が発生し、4つの修正不可能なエラーが検出されたようです。これが出力です。

scrub status for <UUID>
    scrub started at Thu Dec 25 15:19:22 2014 and was aborted after 89882 seconds
    total bytes scrubbed: 1.87TiB with 4 errors
    error details: csum=4
    corrected errors: 0, uncorrectable errors: 4, unverified errors: 0

幸い、すべてを3次バックアップでバックアップしているので、ファイルを失うことについて特に心配していません（BTRFSの試験的なステータスに関連する問題をよく知っています。データを安全に保つために複数のバックアップを持っています。 「ソリューション：BTRFSを使用しない」の投稿）ので、使用しないでください。

しかし、どのファイルが修正不可能なエラーに関連付けられているかを判断する方法を知りたいですか？それらを見つけて削除し、バックアップしたコピーで置き換えたいです。

これを行う方法に関する情報を誰かが持っているなら、私はあなたから聞いてみたいです。

前もって感謝します。

backupfilesystemsbtrfs
17
RedHack

次の方法が便利だと思いました...

btrfs scrub ボリューム。

上記で示したように、csumエラーがいくつも表示されます。
例の使用エラーの詳細：csum = 4。次のステートメントのtailディレクティブでその番号を使用します。

dmesg | grep "checksum error at" | tail -4 | cut -d\  -f24- | sed 's/.$//'

これをファイルにパイプアウトすると便利です（例：> csums.txt）

私はいくつかの提案されたiノード検索アプローチを試してみましたが、それらはすべて成功したとしても限られたものでした。

9
Mark

はい、INODEまたはブロック番号からファイル名へのマッピングは難しい場合があります。あなたが本当に興味があるなら、あなたはこのようなことを試して、どのファイルファイルをコピーするかを見ることができます...結局、ファイルが悪い場合、それはコピー中にエラーをスローするはずです。私は以前にこのタイプのテクニックを使用しました。

 find /mount-point -type f -exec cp {} /dev/null \;

 where mount-point is the ROOT node/mount-point of the affected filesystem
3
mdpc

dmesgは、修正不可能なチェックサムエラーに関連するファイルの詳細を提供します。通常、メッセージは次のようになります。「BTRFS：論理[...]でのチェックサムエラー、デバイス[...]、セクター[...]、ルート[...]、iノード[...]、オフセット[ ...]、長さ[...]、リンク[...]（パス：[...]） ";最後の情報は、破損したファイルへの絶対パスです。

2
arrrr

私もここに来て、BTRFSからの「訂正不能エラー」を探しました。上記のgrepは私にはうまくいきませんでした。代わりに使用する必要がありました：

$ dmesg | sed -n -r 's#.*BTRFS.*i/o error.*path: (.*)\)#\1#p' | sort -u
somepath/somefile.txt

パスがサブボリュームの開始位置からどのように相対しているかに注意してください。どのサブボリュームが含まれているかはわかりません。幸い、これは問題ではありませんでした。

1
crusaderky