現在、システムログで次のメッセージを確認して、失敗したファイルシステム（ディスク、コントローラの故障など）を監視しています。
2017-06-15T17:18:10.081665+00:00 2017-06-15T17:18:10+00:00 localhost kernel: [1381844.448488] blk_update_request: critical target error, dev sdj, sector 97672656
2017-06-15T17:18:10.724329+00:00 2017-06-15T17:18:10+00:00 localhost kernel: [1381845.047871] XFS (md0): metadata I/O error: block 0x2baa81400 ("xlog_iodone") error 121 numblks 512
2017-06-15T17:18:10.724329+00:00 2017-06-15T17:18:10+00:00 localhost kernel: [1381845.124418] XFS (md0): xfs_do_force_shutdown(0x2) called from line 1177 of file /build/linux-lts-wily-8ENwT0/linux-lts-wily-4.2.0/fs/xfs/xfs_log.c. Return address = 0xffffffffc050e100
2017-06-15T17:18:10.724349+00:00 2017-06-15T17:18:10+00:00 localhost kernel: [1381845.124425] XFS (md0): Log I/O Error Detected. Shutting down filesystem
2017-06-15T17:18:10.724349+00:00 2017-06-15T17:18:10+00:00 localhost kernel: [1381845.124452] XFS (md0): xfs_log_force: error -5 returned.
2017-06-15T17:18:10.724354+00:00 2017-06-15T17:18:10+00:00 localhost kernel: [1381845.163480] XFS (md0): Please umount the filesystem and rectify the problem(s)
2017-06-15T17:18:40.612572+00:00 2017-06-15T17:18:40+00:00 localhost kernel: [1381875.074647] XFS (md0): xfs_log_force: error -5 returned.
2017-06-15T17:19:10.612554+00:00 2017-06-15T17:19:10+00:00 localhost kernel: [1381905.101606] XFS (md0): xfs_log_force: error -5 returned.
2017-06-15T17:19:40.612558+00:00 2017-06-15T17:19:40+00:00 localhost kernel: [1381935.128546] XFS (md0): xfs_log_force: error -5 returned.
これはいいねしかし、私はより標準化された小切手が欲しいです。私が考えることができる唯一のことは、ファイルをディスクに書き込もうとし、何らかの理由で書き込めない場合に警告を出すスクリプトを書くことです。しかし、これは間違った肯定が起こりやすいようです。ファイルシステムエラーだけでなくファイルを書き込めないのには、いくつかの理由があります。
ログをgrepしたり、カナリアファイルをディスクに書き込んだりする以外に、これを監視するにはどうすればよいですか？
ベストアンサー1
まあ。何をすべきか私失敗したXFSファイルシステムが検出されましたか？
私は長年XFSを使用してきました。しかし、私は思う私まったく検出しないでください。インストールが成功すれば正しく機能すると思います。これがほとんどの人がやっていることです。ファイルシステムのチェックが自動化されて実行されている場合、それはすべてです。
誤解しないでください。私は実際に多くの監視を行いますが、その中にファイルシステムに固有の監視はありません。 SMARTセルフテストを実行します（時間がかかりすぎるselect,contため、毎日ディスクセグメントを実行します）。longRAIDチェック（ステージング段階でも）を実行し、パリティの不一致（mismatch_cnt= 0）をチェックします。これらのいずれかが失敗した場合は、すぐに電子メール通知を受け取り、セクターの再割り当てが開始されたら実際にHDDを交換します（または少なくとも重要なデータを信頼していません）。
そのため、ストレージが正常に動作しているかどうかを監視します。これには、ドライブ自体（SMART）内のエラーとある程度高いレベルのエラーが含まれます（RAIDチェックは、コントローラ、ケーブル、RAIDロジックなどをある程度テストします）。
正常に機能する限り、ファイルシステムも理想的に機能する必要があります。 ZFS / btrfs（将来はXFS対応）などのチェックサムファイルシステムを除いて、ファイルシステム自体で内部的に実行される完全性チェックに加えて、マウント時にファイルシステムレベルでスキャンを実行することは実際には不可能です。コンセプト。
出力には、RAIDを実行しており、そのRAIDに障害が発生したディスクがあることが表示されます。md0冗長性のないRAID（RAID0またはパフォーマンスが低下したRAID1/5/6/10）でない限り、エラーは発生しないでください。 。
まず、ファイルシステム階層の下の問題を解決する必要があります。ディスクエラーに対してXFSを非難することはできませんが、ディスクエラーを確認する方法ではありません。
ファイルシステム上で完全な読み取りテストを実行したい場合は、xfsdumpバックアップディスクに対して実行できるようです。とにかくファイルシステムで完全な読み取りテストを実行したい場合は、次のようにします。まあ、ある意味では意味があるんです。
その本質は、xfsdumpXFSファイルシステムを完全にナビゲートし、すべてのファイルを保存することです。したがって、これは空き領域を除いて可能な限り完全な読み取りテストに近づける必要があります。
もちろん、すでに別のバックアップシステムを実行している場合は、実際にはファイルシステムに依存しない方法で同じ状況です。 （該当するバックアップシステムで単純な権限不足以上の読み取りエラーが発生した場合は、メールレポートを送信するのが最善です。、また）もちろん、増分バックアップであれば、定期的な完全バックアップなしで実際にファイルを何度も読み取ることはありません。
しかし、通常、ストレージが動作していることを知っている限り、ファイルシステムは「正しく動作する」と信じています。すべてのプログラムが例外なしで発生するすべてのI / Oエラーを引き上げることをお勧めしますが、実際にこれを行う普遍的な解決策はありません。各プログラムには独自のエラー処理機能があります。