RAIDの再構築が停止したと判断するまで、どのくらい待つべきですか？

処理済みブロック数が繰り返しのチェックで増加しなくなり、ログに意図的な一時停止、優先度制限、キューイングされたフェーズ、または回復可能なリトライがない場合にのみ、RAIDリビルドが停止したと判断します。経過時間だけでは不十分です。

大規模なアレイは遅い領域で数時間かかることがあり、アプリケーション負荷で速度が急変したり、再構築と検証の間で一時停止したりします。介入する前にカウンタとログで動きを確認してください。停止や再構築は待機よりもリスクが高くなることがあります。

単一のパーセンテージではなく進捗の差分を使う

一定間隔で正確な処理済みブロック数、パーセンテージ、速度、推定完了時間を記録します。ブロック数が増加していればリビルドは進行中です。丸めたパーセンテージが変わらなくても進んでいます。マルチテラバイトのアレイでは、表示される0.1%が大きな作業量を示すことがあります。

毎回同じインターフェースからコントローラやOSを確認してください。異なるダッシュボードはステータスをキャッシュしたり、異なるフェーズを報告したりすることがあります。ブロックカウンタが進んでいるのに進捗バーが停止して見える場合は、監視の問題であり、リビルドが停止しているわけではありません。

普遍的なタイムアウトではなく、ローカルの基準を推定する

安全な時間数は一つに定められません。リビルド時間は使用容量、RAID構成、ドライブ速度、エラー、コントローラのポリシー、バックグラウンド負荷、そして実装がすべてのブロックをコピーするか割り当てられた領域のみをコピーするかによって異なります。

最初の安定した1時間を使っておおよその範囲を推定し、その後の間隔と比較します。非常に遅いmdadmの再同期速度は、ワークロード、アライメント、リンクの挙動、または問題のあるドライブが原因である可能性があります。正しい診断には速度制限の単純な引き上げ以上の対応が必要です。

意図的な一時停止や新しいフェーズを探す

一部のシステムは、フォアグラウンドI/Oを保護するためにリカバリ速度を制限したり、レジルバー中にスクラブを一時停止したり、スペア割り当てを待機したり、リビルドからパリティ初期化や整合性検証への移行を行います。アクティブなタスクが変わっても、ラベルは「リビルド中」のままの場合があります。

予定されたメンテナンス、電源設定、温度制限、リビルド優先度、アプリケーショントラフィックを見直してください。前景負荷が下がったときに速度が上がる場合、アレイは停止しているのではなくリソース制約を受けています。

繰り返される読み取りエラーは実際の停止を引き起こす

ソースドライブは弱いセクターの再試行に長時間費やし、同じブロック範囲付近でスループットが崩壊することがあります。コントローラーが最終的に回復不能な読み取りを報告すると、冗長性がその領域を再構築できないためリビルドが中止されることがあります。

読み取りエラーで停止したリビルドは、最後に成功したブロックと直後のカーネルエラーが重要であることを示しています。データを保護しソースメンバーを調査せずに、同じアドレスで失敗するリカバリを繰り返し再起動しないでください。

ログ活動があるゼロ速度は再試行中の可能性があります

表示速度がゼロになるのは、コマンドの再試行、デバイスリセット、エラー回復、メタデータ更新、一時的な一時停止中に発生することがあります。ディスクのビジー時間、キュー深度、コントローラーイベント、カーネルメッセージを監視してください。繰り返されるリセットやタイムアウトは健全な進行ではありません。

繰り返し中断するリカバリは、すべての停止に明らかなSMART障害があるわけではないことも示しています。新しいディスクや高速設定で解決すると仮定せず、正確な停止点とすべてのログを記録してください。

実用的な停止判断表を使用する

再構築が停滞していると判断するには、少なくとも2つの独立した信号からの証拠が必要です：カウンターが動かず、エラー、中止状態、または持続的に同じ停止点があること。

何かを再起動する前にすべきこと

1. アレイの詳細、メンバーのシリアル、処理済みブロックのカウンター、完全なイベントログを保存してください。
2. 不要なアプリケーションI/Oを減らし、ターゲットとソースのディスクが検出され続けていることを確認してください。
3. すべてのアクティブなソースでSMARTメディア指標とリンクリセットやCRCカウンターをチェックしてください。
4. 一時停止状態、温度制限、優先度ポリシー、または検証フェーズのキューがないことを確認してください。
5. 同じ読み取り不能範囲で繰り返し試行が停止した場合は、バックアップ、イメージング、または回復にエスカレーションしてください。

アレイの状態と正確な実装がわかるまで、stop、assemble、force-online、metadata-clearコマンドは使用しないでください。

静かな間隔中の進行を比較する

有効な停滞テストには制御された観察ウィンドウが必要です。大きな転送やスケジュールされたジョブを一時停止し、間隔の開始と終了でカウンターを記録します。これにより、フォアグラウンドの競合と自力で進めない回復プロセスを区別できます。

負荷が下がって進行が再開する場合は、メンテナンスの優先度を下げるか、静かなスケジュールを選んでください。カウンターが固定され同じエラーが繰り返される場合、調査なしにさらに待つことはほとんど情報を増やしません。

よくある質問

99.9パーセントで1時間は自動的に停滞ですか？

いいえ。最終のメタデータ更新や検証フェーズには時間がかかることがあります。介入する前に、処理済みブロック、デバイス書き込み、または操作状態がまだ変化しているか確認してください。

再構築速度の制限を上げるべきですか？

ディスクが正常であり、フォアグラウンドI/Oポリシーがボトルネックであることを証明した後のみです。制限を上げるとアプリケーションの遅延が悪化し、限界に近いソースドライブにさらに負荷がかかる可能性があります。

いつ待つのをやめるべきですか？

カウンターが繰り返しのチェックで変わらず、ログに中止、繰り返されるデバイスリセット、回復不能な読み取り、または同じブロック範囲での失敗が記録されている場合、それを正常と見なすのをやめてください。

停滞の作業定義

再構築は、測定可能な作業が停止し、システムがポリシー、負荷、または新しいフェーズとして一時停止を説明できない場合に停滞します。カウンターとエラーの証拠を使用し、不安や実時間は使わないでください。