通常のログ システムに加えて、BTRFS には統計があります。 ドライブごとのエラー (読み取り、書き込み、破損/チェックサム エラーを含む) を追跡するコマンド:
# btrfs device stats /
[/dev/mapper/luks-123].write_io_errs 0
[/dev/mapper/luks-123].read_io_errs 0
[/dev/mapper/luks-123].flush_io_errs 0
[/dev/mapper/luks-123].corruption_errs 0
[/dev/mapper/luks-123].generation_errs 0
したがって、単純なルート cronjob を作成できます:
[email protected]
@hourly /sbin/btrfs device stats /data | grep -vE ' 0$'
これにより、正のエラー カウントが 1 時間ごとにチェックされ、メールが送信されます。明らかに、そのようなシナリオをテストして (たとえば、破損を引き起こしたり、grep を削除したりして)、電子メール通知が機能することを確認します。
さらに、(チェックサムを備えた) BTRFS のような高度なファイルシステムでは、不良ドライブによって引き起こされるサイレント破損を検出するために、2 週間ごとにスクラブをスケジュールすることが推奨されることがよくあります。
@monthly /sbin/btrfs scrub start -Bq /data
-B オプションは、スクラブをフォアグラウンドに保持するため、cron が送信する電子メールで結果を確認できます。そうしないと、バックグラウンドで実行され、結果が電子メールに含まれないため、結果を手動で確認する必要があります。
更新 :Michael Kjörling の提案による grep の改善、ありがとう。
アップデート 2 :スクラブと通常の読み取り操作に関する追加の注意事項 (これは BTRFS だけに適用されるわけではありません):
Ioan が指摘したように、アレイのサイズとタイプ (およびその他の要因) によっては、スクラブに何時間もかかる場合があり、場合によっては 1 日以上かかることもあります。また、これはアクティブ スキャンであり、将来のエラーは検出されません。スクラブの目的は、その時点でドライブのエラーを見つけて修正することです。ただし、他の RAID システムと同様に、定期的なスクラブをスケジュールすることをお勧めします。ファイルの読み取りなどの一般的な i/o 操作では、読み取ったデータが実際に正しいかどうかを確認します。しかし、単純なミラーを考えてみましょう。ファイルの最初のコピーが、おそらく壊れそうなドライブによって破損しているが、正しい 2 番目のコピーが実際には BTRFS によって読み取られている場合、BTRFS は破損があることを認識しません。ドライブの 1 つに。これは単に、要求されたデータが受信されたためであり、BTRFS がこのファイルに保存したチェックサムと一致するため、BTRFS が他のコピーを読み取る必要はありません。 つまり、あるドライブで破損していることがわかっているファイルを具体的に読み取ったとしても、この読み取り操作によって破損が検出される保証はありません。
ここで、BTRFS が正常なドライブからのみ読み取りを行い、不良ドライブの損傷を検出するスクラブが実行されず、正常なドライブも同様に不良になると仮定しましょう。その結果、データが失われます (少なくとも BTRFS は知っているでしょう)。どのファイルはまだ正しく、それらを読み取ることができます)。もちろん、これは単純化された例です。実際には、BTRFS は常に 1 つのドライブから読み取り、もう 1 つのドライブを無視するとは限りません。
しかし重要なのは、定期的な読み取り操作では必ずしも検出されないエラーを検出 (および修正) するため、定期的なスクラブが重要であるということです。
障害のあるドライブ :この質問はよく寄せられる質問なので、この「監視ソリューション」は、不良ドライブの可能性がある問題を検出するためのものであることを指摘しておきます (たとえば、ドライブが故障してエラーが発生しているが、まだアクセス可能であるなど)。
一方、ドライブが突然なくなった場合 (切断されてエラーが発生するのではなく、切断されたか完全に停止した場合)、そのドライブは障害のあるドライブになります (ZFS はそのようなドライブを FAULTED としてマークします)。残念ながら、2015 年 9 月のこのメーリング リスト エントリで指摘されているように、ファイル システムがマウントされている間、BTRFS はドライブがなくなったことを認識しない場合があります (パッチが適用されている可能性があります)。
<ブロック引用>違いは、マウント時にデバイスが存在しないことを検出するコードがあり、マウントされたファイルシステムにデバイスがドロップされたことを検出するコードが (まだ) ないことです。デバイスの消失を適切に検出することが優先事項ではない理由はわかりませんが、それはマウントの動作とは別の問題です。
https://www.mail-archive.com/[email protected]/msg46598.html
その時までに dmesg には大量のエラー メッセージが表示されるため、dmesg の grep は信頼できない可能性があります。
BTRFS を使用するサーバーの場合、RAID アレイ内のドライブの少なくとも 1 つがなくなった場合、つまりアクセスできなくなった場合にアラートを送信するカスタム チェック (cron ジョブ) を用意することをお勧めします...
btrfs-progs v4.11.1 の時点で、stats には --check オプションがあり、値のいずれかがゼロでない場合にゼロ以外を返すため、正規表現が不要になります。
デバイス統計 -c /
ドライブが突然なくなった場合、このコマンドはエラーを返さないため、エラー通知のために stats コマンドに依存しません。 sata ケーブルを外すかドライブを抜くことでテストできますが、重要なファイル システムではお勧めできません。
btrfs device stats /
再起動後、btrfs は見つからないドライブを表示しますが、それでは遅すぎる可能性があります。
btrfs fi show