Nach der Erweiterung des Hardware-RAID-Arrays kann ich mit fdisk keine zusätzlichen verfügbaren Sektoren verwenden

Wir haben ein großes ~ 18 TB Hardware-RAID-Array auf einem Dell R720xd. Derzeit besteht das RAID5-Array aus 6x4 TB und ich musste es erweitern.

Schritt 1 Erweitern Sie das Hardware-RAID-Array.

Einfach genug, wenn Sie die Dell Admin-Tools installiert haben.

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

(Neue Festplatten waren die letzten beiden, die mit dem omreportTool bestätigt werden können. ) Das alles ging gut, obwohl es eine Weile dauerte, und ich konnte bestätigen, dass das Array erweitert wurde.

% 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
...

Schritt 2 neue Partition

Die vdisk meldet nun die erhöhte Größe (26 TB). und fdiskstimmt überein ...

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

Wenn ich jedoch eine zusätzliche Partition zur Festplatte hinzufüge, geschieht Folgendes:

Command (m for help): n
Partition number (2-128, default 2): 2
First sector (34-2047): 

Ich habe jetzt ungefähr 16 Milliarden weitere Sektoren auf der Festplatte, aber ich kann sie nicht verwenden. Mir werden nur die Sektoren 34-2047 angeboten. Ich kann die 8 TB neuen Speicherplatzes nicht zuweisen, obwohl ich derzeit nur mit einer einzigen Partition eingerichtet bin.

Das andere, was mir seltsam vorkam, war die Tatsache, dass mir die Partitionsnummern 2-128 angeboten wurden, nicht nur 2-4. Die Partitionstabelle zeigt keine erweiterte Partition an, daher hätte ich erwartet, dass ich anfänglich nur auf 4 Partitionen beschränkt bin.

Fehlt mir etwas?

• Der Computer wurde neu gestartet, seit das Laufwerksarray erweitert wurde. Vorher würde fdisk nur die ursprünglichen 18 TB melden
• Wenn Sie cfdiskstattdessen versuchen, nur die 2015 verfügbaren Sektoren im Bereich von 39 Milliarden zu melden, werden insgesamt 25 TB gemeldet.
• Wir möchten die Partition nicht löschen und neu erstellen, wenn wir dies vermeiden können, da wir alle Daten verlieren könnten. Wir ziehen es vor, die LVM-Volume-Gruppe nach Abschluss einfach um die neue Partition zu erweitern.
• Es ist ein ähnliches Problem wie bei einem anderen Serverfehler , aber ich bin nicht darauf beschränkt, dass mir die Partitionen ausgehen, und ich glaube nicht, dass ich durch eine erweiterte Partition eingeschränkt werde.
• Seine nicht Sektorgröße wird durch die Laufwerkserweiterung erweitert . Wenn es fdisk wäre, würde ich nicht über die Erhöhung der Sektoranzahl berichten, hätte ich gedacht. Plus pvsund vgsmelden keinen zusätzlichen nicht zugewiesenen Speicherplatz unter LVM
• Ich habe dies als Trockenlauf auf einer virtuellen Maschine ausgeführt und dies nicht erlebt. Allerdings habe ich die VM heruntergefahren und die Größe des Festplattengeräts erhöht. Während der Vergrößerung war es also nicht online. Außerdem waren die Laufwerksgrößen für den VM um viele Größenordnungen kleiner.

Update 1 'x'pert-Modus Ausgabe von Micheal angefordert ...

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.

Also ein möglicher LBA-Fehler?

Das Problem war der Speicherort der Sicherungspartitionstabelle. Normalerweise erwarten Sie am Anfang eine primäre Partitionstabelle und am Ende eine Backup-Partitionstabelle. Durch die Größenänderung der Festplatte wurden mehr Sektoren verfügbar, die Sicherungstabelle wurde jedoch nie verschoben. fdisk hat das nicht gefallen und ich glaube, das war die MyLBA mismatch with real position at backup header.Fehlermeldung. Nicht ganz klar.

Ich wechselte von fdiskzu gdiskund die Ausgabe war etwas anders. In gdisk hast du ...

r       recovery and transformation options (experts only)

Beim Ausführen und Ausführen von verify wurde die hilfreichere Fehlermeldung angezeigt ...

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!

Im gdiskExpertenmodus gibt es folgende Option ...

e       relocate backup data structures to the end of the disk

... das erfolgreich lief und die Überprüfungsausgabe war jetzt ...

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.

Das Drucken der Partitionstabelle zeigte nun den letzten verwendbaren Sektor als 56 Milliarden anstatt als 39 Milliarden an, und ich konnte die neue Partition erstellen und in LVM hinzufügen. Wenn jemand interessiert ist, waren die Schritte dafür ...

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

Der Schlüssel zu diesem Snafu ist folgender:

Last LBA: 39064698846

Ihr GPT-Etikett spiegelt nicht die mittlere Größe wider, die sich geändert hat. fdisksucht auf eine Weise nach freiem Speicherplatz, die nicht perfekt, aber zumindest logisch ist - es sucht nach dem ersten verfügbaren Sektor im größten verfügbaren freien Speicherplatz zwischen den ersten und letzten LBAs von GPT Label .

Eine Möglichkeit, dies sfdiskzu umgehen, besteht möglicherweise darin , das Etikett zu sichern, es entsprechend Ihrer mittleren Größe zu bearbeiten und es zurückzuschreiben, oder es partedsollte besser verwendet werden, um dieses Problem zu beheben, IMO.