異なるドライブ間でNASのスクラブエラーが同じコントローラーポートに続くのはなぜですか？

異なるドライブで、1つのコントローラーポートに追従してスクラブエラーが発生する場合、通常はディスクの記録メディアではなく、共有経路に問題があることを示しています。

スクラブでは広範囲のブロックを読み取るため、通常の日常的なアクセスでは到達しない障害が明らかになることがあります。正常であることが確認された複数のドライブを同じポートに接続したときだけエラーが発生するなら、共通する構成要素には、コントローラーチャネル、コネクター、ケーブル、バックプレーンのレーン、エクスパンダー経路、電源経路、ファームウェア、その経路周辺の冷却が含まれます。診断では、ドライブの識別情報、タイムスタンプ、エラーの種類を保持しながら、エラーがポートに追従していることを証明する必要があります。

ドライブ名ではなくポートにエラーが追従していることを確認する

次回のスクラブ前に、ドライブのシリアル番号、安定したデバイスID、コントローラーポートまたはHBA PHY、ケーブル、ベイ、プールメンバー、読み取り・書き込み・チェックサムのカウンターを記録します。変化する /dev/sdX 名だけに頼らないでください。

TrueNASのドライブトラブルシューティングフローでは、エラーを消去したりデバイスを交換したりする前に、プールとSMARTの証拠を収集することを重視しています。

電源を切って交換した後、エラーがドライブ、ベイ、ケーブル、コントローラーポートのどれに追従するかを確認します。結果を解釈できる状態に保つため、1回のテストで変更するコンポーネントは1つだけにしてください。

スクラブのチェックサムエラーとドライブの読み取り・書き込みエラーを分ける

スクラブの完全な結果と、デバイスごとのカウンターを保存します。チェックサム不一致、コマンドタイムアウト、読み取り不能セクター、書き込み失敗は、それぞれ異なる障害層を示します。

Oracleのドキュメントでは、ZFSスクラブがアクティブなデータのチェックサムを検証する一方、プールのステータスでは、デバイスごとの読み取り、書き込み、チェックサムエラーが個別に報告されると説明されています。

メディアエラーがないのにチェックサムエラーだけが増加し、1つの物理経路に追従する場合は、メモリとドライブの間でのデータ破損、または不安定な転送を疑います。読み取りエラーがポートを変えてもドライブに追従する場合は、ディスク側の可能性が高くなります。

ディスクを正確なコントローラーとリンクに対応付ける

ホストコントローラー、PCIアドレス、SASエクスパンダーまたはSATAポート、エンクロージャー、ケーブル、ベイを経由する安定したディスクパスを追跡します。ハードウェアを移動する前に、この対応関係を保存してください。

lspciのデバイス表示では、ファイルシステム名やプール名とは独立してPCIストレージコントローラーを識別できます。これにより、単に新しいデバイス名が割り当てられたディスクではなく、故障しているコントローラー経路を特定しやすくなります。

HBAの場合は、利用できるならPHYとエクスパンダーの情報も含めます。前面の2つのベイが別々のスロットとしてUIに表示されていても、1本のmini-SASケーブルまたはエクスパンダーレーンを共有していることがあります。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

スクラブ中のSATAまたはSASリンクリセットを調べる

スクラブ開始時点からカーネルログを監視します。影響を受けた経路で、強制リセット、COMRESETの失敗、リンクダウンイベント、コマンドタイムアウト、プロトコルエラー、ネゴシエーション速度の変化を探します。

LinuxのlibATAガイドでは、ポート単位のリンクリセットとエラーリカバリーについて説明しています。これにより、一般的なプール警告よりも、1つのATAポートに関連付けられたメッセージが強い証拠となる理由が分かります。

最初に発生した転送エラーのメッセージを保存してください。その後に出るファイルシステムエラーは、読み取り中にコントローラーが通信を失った結果にすぎない場合があります。

インターフェースCRCとコマンドタイムアウトのカウンターを比較する

各ドライブについて、1回のスクラブの前後にSMART属性とログを取得します。影響を受けた経路でのみ、インターフェースCRCまたはコマンドタイムアウトのカウンターが増加しているかを追跡します。

Unraidでは、UDMA CRCエラーはドライブとコントローラーの間で発生すると説明されており、一般にプラッターの損傷ではなく、ケーブル、コネクター、配線、コントローラーリンクが関係します。

過去からのCRC合計値だけでは、現在問題のあるコンポーネントを特定できません。生のカウント値を記録し、範囲を限定したテストを1回実行して、その値が増加したかどうかだけを確認します。

スクラブの負荷とは別にドライブテストを実行する

プールが通常より空いており、データが保護されている状態で、対応している短時間および拡張SMARTテストを実行します。別のスクラブや再構築と同時に、完全なSMARTテストをスケジュールすることは避けてください。

Debianのsmartctlリファレンスでは、ドライブ内部のセルフテストとエラーログが、ホスト側のファイルシステム検証とは分けて扱われています。

ドライブが内部テストに合格し、1つのコントローラーポートでのみエラーが発生するなら、経路に問題があるという仮説が強まります。ただし、ディスクに問題がないことの証明にはならないため、ポートを変更した後も監視を続けてください。

共有コンポーネントを1つ交換し、範囲を限定したスクラブを再実行する

バックアップが最新であることを確認し、サーバーの電源を切ってから、正常なことが確認されたドライブを疑わしい経路に接続するか、他の変数を固定したままケーブルを1本交換します。すべてのディスクを同時に入れ替えないでください。

ZimaSpaceのディスクが脱落した場合と不良ベイの場合に関するガイドでは、隣接する管理された交換方法を説明しています。この記事では、その考え方を、1つのコントローラーポートに繰り返し追従するスクラブエラーに特化して適用します。

エラーが急速に増加する、同じコントローラー上の複数のドライブがリセットされる、プールが劣化する、またはアプリケーションが破損ファイルを報告する場合は、スクラブを停止し、データ保護を優先します。同じポート経路で、新たなエラーを発生させずに複数回のスクラブと通常のI/Oを完了できて初めて、問題は解決したと判断できます。