ZFSのエラー報告を理解する（Linux）

一般的な概要については、次を参照してください。ZFSのトラブルシューティング、最も興味深い部分は次のとおりです。

構成出力の 2 番目の部分にはエラー統計が表示されます。これらのエラーは3つのカテゴリに分類されます。

• READ – 読み取り要求を発行したときに発生したI/Oエラー
• WRITE – 書き込み要求の発行中に発生したI/Oエラー
• CKSUM - チェックサムエラー。読み取り要求が原因でデバイスが破損したデータを返したことを意味します。

これらのエラーは、損傷が永続的であることを確認するために使用できます。 I / Oエラーの数が少ないと一時的な中断が発生する可能性がありますが、エラーの数が多い場合はデバイスに永続的な問題があることを示している可能性があります。これらのエラーは、アプリケーションによって解釈されたデータ破損と必ずしも一致するわけではありません。デバイスが冗長構成の場合、ミラーレベルまたはRAID-Zデバイスレベルではエラーは発生しませんが、デバイスは修正できないエラーを表示できます。この場合、ZFSは正しいデータを正常に取得し、既存のコピーから破損したデータを回復しようとします。

---

今あなたの質問について：

まず、この文脈で「デバイス」とはどういう意味ですか？物理デバイス、vdevなどについて話していますか？私の仮定は、彼らが階層の各「デバイス」について話しているということです。その後、vdevのエラー数は物理デバイスのエラー数の合計であり、プール内のエラー数はvdevエラーの数の合計になります。そうですか？

各デバイスは、独自にすべてのエラーを独立して検査し、要約します。これらのエラーが両方のミラーに存在する場合、またはvdev自体が重複していない場合は、上向きに伝播されます。つまり、vdev自体に影響を与えるエラーの量です（各行を個別に表示するロジックにも適しています）。

しかし、私が本当に興味を持っているのは、ZFSレベル（ハードウェアレベルではない）にチェックサムエラーがあるかどうかです。私は現在CKSUMが後者を示していると確信していますが（そうでなければあまり意味がないでしょう）、確信したいと思います。

はい、ハードウェアの側面です（ケーブル障害、突然削除されたディスク、停電などの非永久的な問題）。私もこれがポイントだと思います。 「ソフトウェア側」エラーは、ZFS自体にバグがあることを意味するため、未確認（すべての一般的なユーザー対話が正しいと見なされると仮定して）、誤った動作がZFS自体で認識されないことを意味します。幸いなことに、最近ではそういうことはほとんどありません。残念ながら、彼らはまた、ほとんどの場合非常に深刻です。

第三に、彼らが言うチェックサムエラーが実際にハードウェアレベルではなくZFSレベルチェックサムエラーであると仮定すると、なぜ修正できないエラーの数だけが表示されますか？これは言葉ではありません。修正可能かどうかにかかわらず、すべてのチェックサムエラーを確認したいと思います。そうではありませんか？結局のところ、チェックサムエラーは、ハードウェアがまだ検出していないディスクのデータ破損があることを意味するため、エラーが発生する直前にそれを変更したいと思うかもしれません（ミラーリングされたディスクがまだ機能している場合でも）。 「バックアップ」）。だからおそらく、「修正不可能」が実際に何を意味するのか、まだ理解していないかもしれません。

障害のあるディスクは、読み取り/書き込みエラー（ディスクのUREなど）としてマークされています。チェックサムエラーは説明するものです。ブロックを読み込み、ツリー内のその上のブロックのチェックサムは、戻り値が正しくないと考えて返す代わりに削除され、エラーとして表示されます。 「修正不可能」はおおよその定義です。なぜなら、ゴミが発生し、それがゴミであることを知っている場合は修正できませんが、無視して使用しない（または再試行する）可能性があるからです。しかし、これらの表現は不必要な混乱を引き起こす可能性があります。

この段落によれば、データ破損エラーとデバイスエラーの2種類のエラーが発生する可能性があります。両方のディスクのミラーリング構成は間違いなく冗長であるため、その段落に応じて、ZFSがディスクの1つ（ハードウェアレベルではなくZFSチェックサムレベル）でチェックサムエラーが発生した場合、これはデータ破損エラーではありません。これは、その段落によってエラーが継続的なエラーログの一部として記録されないことを意味します。

データ破損この段落の内容は、一部のファイルが部分的または完全に破損して読み取れないため、最後のバックアップをインポートしてできるだけ早く交換する必要があることを意味します。 ZFSのすべての予防措置が失敗し、もはや役に立つことができない場合（ただし、次回ディスクスキャンが実行されたときにサーバーが起動するのではなく、今すぐ通知されます）。

私にZFSに切り替える主な理由は、自動ビット減衰を自己検出する機能、つまりハードウェア/ドライバレベルでI / Oエラーを引き起こさない場合でも、デバイスのエラーを検出して報告する機能です。ただし、永続ログにこれらのエラーが含まれていないと、再起動時にエラーが失われて致命的になる可能性があります（IMHO）。

ZFSシステムの基本的な概念は、ファイルシステムをオンラインで確認できるため、これらのエラーを検出するためにシステムをシャットダウンする必要がないことです。 10年前、これは当時ほとんどの小規模システムにはなかった機能でした。したがって、（もちろん冗長構成では）ハードウェアの読み書きエラーを確認し、よく知られたレプリカを使用して修正できるという考えです。また、毎月スクラビングを実行してすべてのデータを読み取る（未読データが良いかどうかを知る方法がないため）、見つかったエラーを修正することもできます。

それは大きな古い本のアーカイブ/図書館のようです。貴重な本があり、あまり価値のない本があり、一部は時間の経過とともに腐敗する可能性があるため、毎週または毎月確認するには一人の人が必要です。本のすべてのページは次のとおりです。真菌、エラーなどを発見した場合、彼はあなたに言うでしょう。同じ図書館が2つある場合は、別の建物に行き、同じページで同じ本を見て、最初の図書館の破損したページをコピーに置き換えることができます。もし彼が本を確認しなかったならば、20年後にひどい事故に遭ったかもしれません。

このトピックについてもっと考えて、user121391の回答を数回読んだ後、user121391の文をより明確にするために私の質問に答えたいと思います。間違った点があれば修正してください。

最初の質問：「デバイス」とはどういう意味ですか？

これはuser121391によって明確になりました。意味のあるコンテンツを追加できません。

2番目と3番目の質問：修正できないエラーは何ですか？/なぜ修正不可能なエラーですか？修正できないエラーカウンタにエラーが表示されますか？

Sun / Oracleが選択した表現は非常に不明であり、誤解を招く可能性があります。通常、ディスク（または階層のハードウェアコンポーネント）にデータ整合性エラーが発生すると、次の2つの状況が発生する可能性があります。

• エラーはECCなどのメカニズムを介して修正することができ、適切なコンポーネントは修正後にデータを渡します（したがって、管理者が適切なツールを介して読み取ることができるいくつかのエラーカウンタが増加する可能性があります）。

• 間違いは可能ですいいえ修正される。この場合、通常はI / Oエラーが発生し、問題が発生したことをハードウェア/ドライバ/アプリケーションに通知します。

まれに、I / Oエラーが発生します。いいえあってもそういうことは起こるだろう以前はまだ修正されていないデータ整合性エラーです。これは、ソフトウェアの障害、ハードウェアの障害などによって発生する可能性があります。これが私が個人的に「自動ビット腐敗」を意味し、私がZFSに切り替えた理由です。これらのエラーは、ZFS自体の「エンドツーエンド」チェックサムによって検出されます。

だから、ZFSチェックサムエラー正確にはデータ（整合性）エラーです。ハードウェアレベルではI / Oエラーは発生しません。したがって、ZFSセルフチェックサム以外のメカニズムでは検出できず、その逆も同様です。この意味で、コマンドのCKSUM列のエラー数は、zpool status -vZFSチェックサムエラーの数と検出されなかったハードウェアエラーの数です。 2つの数字が全く同じだからです。

つまり、デバイスがそれ自体で整合性エラーを修正した場合（エラーを修正できない場合）、I / Oエラーを設定した場合、ZFSはいいえCKSUMエラーカウンターを増やしました。

私はSunドキュメントのこの部分について非常に懸念してきました。なぜなら、「修正できないエラー」という用語はまったく説明されておらず、非常に誤解を招くからです。 「I/Oエラーを起こさない修正不可能なハードウェアエラー」と書かれていたら普通のように「ドキュメントのこの部分には問題はありません。

したがって、要約すると、この場合、「修正不可能」とは、「ハードウェアレベルで修正不可能で検出されない」（検出されていないがデータ（整合性）エラーがあったがI / O発生エラーは発生しない）を意味します。 「ZFSレベル」修正するためにその他ディスク（ミラー）またはデータをディスク（ミラー）のデータから再構成できるかどうかその他ディスク（RAIDZ））。

最後の質問（永久ログ関連）

ここでもSunの文書は間違っています（または少なくとも何が起こっているのかを理解するために読んでいる人がいないほど誤解を招く可能性があります）。

明らかに少なくとも二つ永久ログ。

このマニュアルで説明されているものの1つは、アプリケーションI / Oエラー（冗長メカニズムを介しても修正できないI / Oエラー、またはZFSのZFSチェックサムエラー）のために読み取れないファイルを詳細に含むログです。つまり、ディスクレベルでI / Oエラーが発生したが、ZFSが冗長メカニズム（RAIDZ、ミラーリング）を介してエラーを回復できる場合、エラーは次のようになります。いいえこの永続ログに記録されます。

IMHO これは意味があります。このログの助けを借りて、管理者はバックアップからどのファイルを復元する必要があるかを一目でわかります。

しかし、ドキュメントには、2番目の永続的な「ログ」、つまりエラーカウンタの「ログ」への言及はありません。もちろん、エラーカウンタは、クリーンアップ中にエラーが検出されたか、通常の動作中に検出されたかにかかわらず、再起動の間に維持されます。それ以外の場合、ZFSは意味がありません。

毎晩11時に実行され、結果をメールで送信するスクリプトがあり、毎朝電子zpool status -vメールをチェックして、すべてが正しいことを確認すると想像してください。ある日の正午に、ZFSはディスクの1つでエラーを検出し、そのデバイスのI / OまたはCKSUMエラーカウンタを増やし、エラーを修正してから（たとえば、ミラーリングされたディスクに正しいデータがあるため）、データを渡しますします。この場合、アプリケーションしたがって、入力/出力エラーが発生します。いいえドキュメントに記載されているように、継続的なエラーログに記録します。

その時、I / OまたはCKSUMエラーカウンターが唯一の手がかりです。そのディスクに問題があります。その後、2時間後に何らかの理由でサーバーを再起動する必要があります。時間的圧力が大きく、生産を継続する必要があります。もちろんzpool status -v、この場合は再起動する前に手動で実行しません（おそらくログインできません）。今、ZFSが別々の「ログ」にエラーカウンタを書き込まないと、ディスクの1つにエラーがあるという情報が失われます。 ZFSの状態を確認するスクリプトは夜11時に実行される予定です。

したがって、エラーカウンタはどこかに永久に保存されます（「ログ」と呼ばれるべきかどうかについて議論することができますが、重要なのは、再起動後に再起動直後と同じ結果をzpool status -v表示するように永久に保存されることです）。以前）。実際、私が知っている限り、zpool clearこれはエラーカウンタをリセットする唯一の方法です。

私はSun / Oracleがそのような不明な文書を書くことによって自分自身に利益を与えているとは思いません。私は経験豊富なユーザー（実際には開発者）であり、不都合な文書を読むのに慣れています。しかし、Sunの文書は本当に災難です。彼らは何を期待していますか？実際に私のディスクの1つをだましてI / Oエラーを生成し、サーバーを再起動してエラーカウンタが保存されていることを確認する必要がありますか？それとも、この基本的で重要な質問に答えるためにソースコードを読む必要がありますか？

ZFS / Solarisに関する決定を下す必要がある場合は、文書を読んで決定を下します。この場合、ドキュメントを見ると、エラーカウンタが再起動後も保持されないという印象を受けたので、明らかに反対することにしました。もちろんこれはまったく受け入れられないことです。

幸いにも、ZFSに関する他の記事を読んだ後、ZFSを試してみました。今後Sun のマニュアルをお読みください。製品は文書（IMHO）と同じくらい優れています。