ドライブ交換後にRAID容量が増えない場合、何を確認すべきですか？

RAIDの容量は通常、1つのレイヤーが古い境界を報告し続けるため変わりません。リビルド、メンバーサイズ、アレイのジオメトリ、パーティショニング、ファイルシステムの順に確認してください。

ディスクの交換はハードウェアのステップに過ぎません。NASは複数の積み重なったサイズ制限を含むことがあり、それぞれのレイヤーが次のレイヤーで使用できる前により大きな境界を公開しなければなりません。最も安全な診断は読み取り専用の状態チェックから始め、まだ小さい最初のレイヤーを特定し、交換を繰り返すのではなくそのレイヤーだけを拡張します。

すべての交換が完全に統合されていることを確認する

ミラーやパリティグループに元の小さいメンバー、まだアクティブになっていないスペア、またはリビルド中の交換メンバーが含まれている間は容量は増加しません。アレイは通常、そのジオメトリを定義するメンバー間で共通の容量のみを使用します。

ディスクはNASのインベントリに存在しても同期済みメンバーであるとは限りません。検出されたディスクが交換プロセスを完了したと仮定せず、アレイの状態、リビルド状態、メンバーの役割、シリアル番号、報告されたデバイスサイズを比較してください。

必要なすべての交換とリシルバーまたはリビルドが新たなエラーなしに完了するまで待ちます。メンバーが欠落、故障、または予想より小さい場合は、アレイレイヤーが古いサイズを保持する正当な理由があるため、拡張コマンドを試みる前にその状態を解決してください。

各メンバーデバイスの使用可能サイズを確認する

より大きな物理ドライブでも古いサイズのパーティションや記録されたコンポーネント境界をRAIDに提示している場合があります。ディスク全体の容量、パーティションの終了セクター、アレイメンバーとしてリストされている正確なブロックデバイスを比較してください。

より大きなバージョン1.xのメンバーは、物理ディスクが交換された後でも記録されたコンポーネント境界を保持することがあります。すべてのアクティブメンバーが対応可能になってから最大コンポーネントサイズに拡張してください。

表示サイズが古いからといってパーティションを再作成しないでください。まず開始セクター、パーティションタイプ、RAID UUID、メンバーのシリアル番号を記録し、既存の開始位置とメタデータを保持するプラットフォーム対応の拡張方法を使用してください。

RAIDレイヤーが拡張されていることを確認する

すべてのメンバーが大きくなっているのにRAIDブロックデバイスがそうでない場合、アレイのジオメトリは拡張されていません。必要な対応はスタックがmd RAID、ZFS、Btrfs、ハードウェアコントローラー、またはNAS管理のストレージプールかによって異なります。

md RAIDの場合、アクティブコンポーネントサイズの変更は新たに公開された領域の再同期を開始します。ZFSミラーではミラーグループ内のすべてのデバイスが交換された後にのみ空き容量が利用可能になり、拡張にはautoexpandまたは明示的なオンライン拡張が必要な場合があります。

実際のRAID実装に属する管理インターフェースやコマンドを使用してください。アレイがリシェイプ、劣化状態、サポートされていないレイアウト変更、メンバーサイズ不一致を報告した場合は停止してください。これらの状態は新しい境界を信頼する前に解決が必要です。

RAIDの上位にパーティションやボリュームレイヤーがないか確認する

RAIDデバイスが拡張されても、パーティションテーブル、LVM物理ボリューム、論理ボリューム、暗号化マッピング、ストレージプール割り当てが以前のセクターで終わっている場合があります。ファイルシステムは中間レイヤーが割り当てていないブロックを認識できません。

プラットフォームのブロックデバイスビューでマウントパスを下方向にたどり、各段階のサイズを比較してください。最初に小さいままのオブジェクトが拡張すべきレイヤーです。上位レイヤーを先に変更すると失敗するか、新しい空き領域が割り当てられません。

境界は一度に1つずつ拡張し、次のレイヤーを再確認してから続行してください。この段階的な方法は明確なロールバックポイントを作り、ファイルシステム用のコマンドが誤ってRAIDメンバーやパーティションに適用されるのを防ぎます。

ブロックデバイスが拡張された後にのみファイルシステムを拡張する

ファイルシステムは基盤となるRAIDデバイスが大きくなっても必ずしも拡張されるわけではありません。マウントされたファイルシステムがまだ古いサイズを報告し、含むブロックデバイスが新しいサイズを報告していることを確認してください。

ext2、ext3、ext4ではファイルシステムのリサイズツールはパーティションや論理デバイスが先に拡大されていることを期待します。XFSも同様のレイヤー順序で、XFSの拡張操作はデバイスで既に公開された容量にマウント済みファイルシステムを拡張します。

デバイスパス、マウントポイント、対応するオンライン状態、最近のバックアップを確認した後にのみファイルシステム固有の拡張操作を使用してください。ファイルシステムが変わらないままのRAID拡張は不完全ですが、誤ったレイヤーを推測するより安全です。

ファイルシステム固有のデバイスリサイズに注意する

一部のファイルシステムは複数のデバイスを直接管理するため、交換やリサイズの手順が従来のRAID＋ファイルシステムのスタックと一致しません。Btrfsが一般的な例で、デバイスの交換と新しい容量の公開は別の操作です。

Btrfsデバイスをより大きなターゲットに交換しても、追加されたブロックが自動的にファイルシステムに公開されるわけではありません。別のデバイスリサイズ操作が、交換は正常に完了しても報告容量が変わらない理由を説明します。

mdadm、パーティション、LVMの指示を使う前にファイルシステム自体がデバイスセットを所有しているかどうかを特定してください。異なるストレージスタックの手順を混ぜることは、単純な容量問題をメタデータの問題に変える最も速い方法の1つです。

レイヤーごとの容量チェックを行う

決定的なテストは物理ディスクからマウントされたファイルシステムまでの各レイヤーで報告されるサイズを記録することです。容量はRAIDの冗長性、メタデータ、予約ブロック、単位変換による予想される減少を除き、スタック全体で単調に増加するはずです。

物理ディスクは大きいのにメンバーパーティションがそうでなければパーティションレイヤーを修正します。RAIDデバイスは大きいのに論理ボリュームがそうでなければボリュームを拡張します。すべてのブロックレイヤーが大きいのにマウントされたファイルシステムがそうでなければファイルシステムの拡張ステップを実行します。

説明できない形で隣接する2つのレイヤーが不一致を示すか、拡張中にいずれかのヘルスカウンターが上昇したら停止してください。ジオメトリを変更する前に状態出力とバックアップを保存してください。最初の説明できない境界は診断の手がかりであり、次の操作を強制する理由ではありません。