元の情報から、RAID 1の両メンバーを大容量ディスクに交換しても、使用可能なファイルシステム容量は自動的には拡張されないことが分かります。あるユーザーは500 GBのディスク2台を、1台ずつ1 TBのディスクに交換し、交換のたびにZimaOSで再構築を実行しました。この時点で物理メンバーは両方とも1 TBでしたが、RAID／デバイスとBtrfsファイルシステムが公開していた容量は、依然として従来の500 GBのままでした。
そのユーザーはZimaOS+ 1.5.4で、SSHから拡張を完了しました。 mdadm --grow /dev/md0 --size=maxを実行し、結果として発生したリカバリ／再同期を待った後、最後に次を実行しました。 btrfs filesystem resize max マウント済みファイルシステムに対して実行しました。ユーザーはGUIと df その後、容量が増えたことが表示されました。これはコミュニティによる有力な検証ですが、現在のIceWhale GUIの手順ではなく、手動のCLIワークフローです。
容量拡張を開始する前にバックアップを作成する
RAID 1は1台のメンバー障害には対応しますが、オペレーターのミス、アレイメタデータの損傷、ファイルシステム上のミス、再構築中の2台目のディスク障害からは保護しません。
RAIDメンバーは一度に1台だけ交換する
- 電源を切る
- 最初の古いディスクを大容量ディスクに交換する
- 起動する
- ZimaOS Recoveryを使用して再構築します。
- リカバリが完全に完了するまで待ってください。
2台目のメンバーでも繰り返す
最初の再構築が完了してから、ユーザーは電源を切って2台目のディスクを交換し、GUIから再度リカバリを実行して、完全に完了するまで待ちました。
この時点で、アレイは2台の大容量物理デバイス上で正常な状態でしたが、サイズは依然として従来のメンバー容量に制限されていました。
コミュニティユーザーは続いてmdadmアレイを拡張しました
元のコマンドは次のとおりです。
sudo mdadm --grow /dev/md0 --size=max新しいアレイ構成を確認しました。 mdadm --detail 新しいリカバリ／再同期状態の完了を待ちました。
アレイが /dev/md0。まず実際のアレイを確認してください。
その後、Btrfsファイルシステムを拡張する必要がありました
元の手順の最後は次のとおりです。
sudo btrfs filesystem resize max /your/mounted/filesystemプレースホルダーをそのままコピーせず、実際にマウントされているBtrfsパスを使用してください。
サイズ変更が2段階必要だった理由
- Linux md RAIDデバイス
- その上に構築されたBtrfsファイルシステム。
どちらも、ユーザーが追加容量を利用できるようになる前に、より大きいサイズを認識させる必要があります。
これはバージョン固有のコミュニティ手順として扱ってください
ソースのユーザーはZimaOS+ 1.5.4を明示的に実行していました。現在のZimaOSはより新しく、ストレージ管理の動作は変わる可能性があります。手動で実行する前に mdadm --grow 本番ストレージでは、UIに対応済みの拡張パスがまだないことを確認し、IceWhaleサポートに最新の手順を問い合わせることを検討してください。
各物理交換の前にRAIDの健全性を確認する
1台目のディスクを交換する前、そして2台目を交換する前にも、アレイが正常で完全に同期されていることを確認してください。1台目の再構築が完了する前に2台目の交換を開始すると、アップグレード中に頼っている冗長性が失われます。
メンバーのシリアル番号を記録し、取り外す物理ドライブがZimaOSに表示される論理メンバーと一致することを確認してください。
交換用ドライブには十分な実容量が必要
公称容量が同じドライブでも、使用可能なセクター数はわずかに異なる場合があります。最も安全な拡張方法は、旧メンバーより明らかに大きく、かつ互いに同等以上の容量を持つ交換用ディスクを使用することです。
2台目の「1 TB」ドライブが1台目よりわずかに小さい場合、mdの拡張／再構築手順が期待どおりに動作しない可能性があります。
複数回の再同期サイクルを想定する
ソースのワークフローでは、1台目の物理交換後に再構築し、2台目の交換後にも再構築し、その後、さらに別の復旧／再同期状態に入りました。 mdadm --grow。つまり、容量アップグレードには、2台のディスクを単に交換するよりも大幅に長い時間がかかる場合があります。
各復旧段階でNASを安定した電源に接続し、不要な再起動を避けてください。
最終段階でブロックデバイスとファイルシステムの両方を確認する
最後のBtrfsリサイズ後、複数の層から結果を確認してください：
-
mdadm --detail— md RAIDの構成； -
df -hまたはBtrfsファイルシステムツール — 使用可能なファイルシステム容量； - ZimaOSストレージUI — 期待されるプールサイズと正常な状態。
どこか1つの層に古いサイズが表示されている場合は、growコマンドを盲目的に繰り返さず、停止して調査してください。
RAID 1拡張に関するよくある質問
大容量ディスクを1台使うだけで、RAID1の容量をすぐに増やせますか？
いいえ。ミラーは小さい方のメンバーと、過去のアレイ構成によって制限されたままです。
小さい方のディスクを両方交換すると、ソース上で容量は自動的に増加しましたか？
いいえ。ユーザーは引き続きmdアレイを拡張してから、Btrfsのサイズを変更する必要がありました。
手動で拡張するワークフローは、ソースで確認済みでしたか？
はい、1人のZimaOS+ 1.5.4ユーザーによるものです。公式のIceWhale手順として投稿されたものではありません。
