ハードウェアRAIDアレイの拡張後、fdiskで追加の利用可能なセクターを使用できなくなります
Dell R720xdには、最大18 TBのハードウェアRAIDアレイがあります。現在、RAID5アレイは6x4TBで構成されており、拡張する必要がありました。
ステップ1ハードウェアRAIDアレイを拡張します
デルの管理ツールがインストールされている場合は、非常にシンプルです。
omconfig storage vdisk action=reconfigure controller=0 vdisk=1 raid=r5 pdisk=0:1:0,0:1:1,0:1:3,0:1:3,0:1:4,0:1:5,0:1:8,0:1:9
（最後の2つは新しいディスクでした。これはomreportツールを使用して確認できます）少し時間がかかりましたが、すべてうまくいき、アレイが拡張されたことを確認できました。
% omreport storage vdisk controller=0 vdisk=1
Virtual Disk 1 on Controller PERC H710P Mini (Embedded)
Controller PERC H710P Mini (Embedded)
ID : 1
Status : Ok
Name : bak
State : Ready
Hot Spare Policy violated : Not Assigned
Encrypted : No
Layout : RAID-5
Size : 26,078.50 GB (28001576157184 bytes)
...
Device Name : /dev/sdb
...
ステップ2新しいパーティション
そのため、vdiskは増加した（26TB）サイズを報告しています。 fdiskは同意します...
Disk /dev/sdb: 25.5 TiB, 28001576157184 bytes, 54690578432 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: A2D20632-37D1-4607-9AA0-B0ED6E457F91
Device Start End Sectors Size Type
/dev/sdb1 2048 39064698846 39064696799 18.2T Linux LVM
ただし、ディスクにパーティションを追加すると、次のようになります...
Command (m for help): n
Partition number (2-128, default 2): 2
First sector (34-2047):
現在、ディスクには約160億のセクターがありますが、使用できません。私はセクター34-2047のみを提供しています。現在、単一のパーティションのみでセットアップされているにもかかわらず、8TBの新しいスペースを割り当てることができません。
奇妙なことに私を驚かせたもう1つのことは、単に2-4ではなく、2〜128のパーティション番号が提供されたことです。パーティションテーブルには拡張パーティションが表示されないので、最初は4つのパーティションに制限することを期待していました。
不足しているものはありますか？
- ドライブアレイが拡張されてから、マシンが再起動されました。その前に、fdiskは元の18TBのみを報告していました
- 代わりに
cfdiskを試してみると、全体で25TBと報告されているにもかかわらず、2015セクターは390億の範囲で利用できると報告されています。 - すべてのデータが失われる可能性があるため、回避できる場合は、パーティションを削除して再作成する必要はありません。 LVMボリュームグループを拡張したら、新しいパーティションで拡張することをお勧めします。
- これは 別のサーバー障害の質問 と同様の問題ですが、パーティションが不足することによる制限はなく、考えません拡張パーティションによって制限されています。
- それではない ドライブ拡張によって拡張されるセクターサイズ 。もしfdiskがセクター数の増加を報告していなければ、私は思っていたでしょう。さらに、
pvsおよびvgsは、LVMの下で追加の未割り当てスペースを報告していません - これを仮想マシンで予行演習として実行しましたが、これは経験されませんでした。しかし、私はvmをシャットダウンして、そのディスクデバイスサイズを増やしていました。そのため、サイズの増加中はオンラインではありませんでした。さらに、VMのドライブサイズは数桁も小さくなりました。
Update 1Michealから要求された 'x'pertモード出力...
Command (m for help): x
Expert command (m for help): p
Disk /dev/sdb: 25.5 TiB, 28001576157184 bytes, 54690578432 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: A2D20632-37D1-4607-9AA0-B0ED6E457F91
First LBA: 34
Last LBA: 39064698846
Alternative LBA: 39064698879
Partitions entries LBA: 2
Allocated partition entries: 128
Device Start End Sectors Type-UUID UUID Name Attrs
/dev/sdb1 2048 39064698846 39064696799 E6D6D379-F507-44C2-A23C-238F2A3DF928 E9CB58BF-F170-4480-A230-6E2A238367D1 Linux LVM
Expert command (m for help): v
MyLBA mismatch with real position at backup header.
1 error detected.
では、LBAエラーの可能性はありますか？
問題は、バックアップパーティションテーブルの場所でした。通常、最初にプライマリパーティションテーブルがあり、最後にバックアップパーティションテーブルがあります。ディスクのサイズ変更により、利用可能なセクターが増えましたが、バックアップテーブルは移動されませんでした。 fdiskはこれが気に入らなかったし、それがMyLBA mismatch with real position at backup header. エラーメッセージ。明確ではない。
fdiskからgdiskに切り替えたところ、出力が少し異なりました。 gdiskには...
r recovery and transformation options (experts only)
その中に入ってverifyを実行すると、より役立つエラーメッセージが表示されました...
Recovery/transformation command (? for help): v
Problem: The secondary header's self-pointer indicates that it doesn't reside
at the end of the disk. If you've added a disk to a RAID array, use the 'e'
option on the experts' menu to adjust the secondary header's and partition
table's locations.
Identified 1 problems!
gdiskエキスパートモードでは、次のオプションがあります...
e relocate backup data structures to the end of the disk
...正常に実行され、検証出力は今...
Expert command (? for help): v
No problems found. 15625881566 free sectors (7.3 TiB) available in 2
segments, the largest of which is 15625879552 (7.3 TiB) in size.
パーティションテーブルを印刷すると、最後の使用可能なセクターが39億ではなく56億と表示されました。新しいパーティションを作成してLVMに追加することができました。
partprobe <-- add the /dev/sdb2 device if you don't want to reboot
pvcreate /dev/sdb2
vgextend bak /dev/sdb2
lvextend /dev/mapper/bak-bak -l 100%PVS -r
このsnafuの鍵は次のとおりです。
Last LBA: 39064698846
GPTラベルは、変更された中サイズを反映していません。 fdiskは、完全ではないが少なくとも論理的な方法でフリースペースを検索します。GPT Label'sの最初と最後の間で利用可能な最大のフリースペースで最初に利用可能なセクターを探しますLBA。
回避策の1つは、sfdiskを使用してラベルをダンプし、適切なサイズに編集して、それを書き戻すか、問題のIMOを処理するpartedを使用することです。