Dopo l'espansione dell'array RAID hardware, fdisk non mi permetterà di utilizzare altri settori disponibili

Abbiamo un ampio array di raid hardware da ~ 18 TB su un Dell R720xd. Attualmente l'array RAID5 è composto da 6x4 TB e avevo bisogno di estenderlo.

Passaggio 1: espandere l'array RAID hardware.

Abbastanza semplice se hai gli strumenti di amministrazione dell installati.

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

(i nuovi dischi erano gli ultimi due, che possono essere confermati usando lo omreportstrumento) Che tutto è andato bene anche se ci vuole un po 'di tempo, e sono stato in grado di confermare che l'array era stato espanso ..

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

Passo 2 nuova partizione

Quindi il disco virtuale ora segnala la dimensione aumentata (26 TB). e fdiskconcorda ...

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

Tuttavia, quando vado per aggiungere una partizione aggiuntiva al disco, accade quanto segue ...

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

Ora ho circa 16 miliardi di settori in più sul disco, ma non posso usarli. Mi vengono offerti solo i settori 34-2047. Non riesco ad allocare gli 8 TB di nuovo spazio anche se al momento sono configurato con una sola partizione.

L'altra cosa che mi ha colpito in modo strano è il fatto che mi hanno offerto i numeri di partizione 2-128, non semplicemente 2-4. La tabella delle partizioni non mostra alcuna partizione estesa, quindi mi sarei aspettato che inizialmente mi limitassi a solo 4 partizioni.

C'è qualcosa che mi manca?

Il computer è stato riavviato dall'espansione dell'array di unità. Prima che fdisk segnalasse solo i 18 TB originali
Provare cfdiskinvece a segnalare solo 2015 settori disponibili nell'intervallo di 39 miliardi nonostante abbia riportato complessivamente 25 TB.
Non vogliamo eliminare e ricreare la partizione se possiamo evitarla, dato che potremmo perdere tutti i dati. Preferiamo semplicemente estendere il gruppo di volumi LVM con la nuova partizione una volta eseguita.
È un problema simile a un'altra domanda di errore del server , ma non sono limitato dal fatto che ho esaurito le partizioni e non credo di essere limitato da una partizione estesa.
La sua dimensione non settoriale viene espansa dall'espansione dell'unità . Se fdisk non avesse riportato l'aumento del conteggio dei settori, avrei pensato. Inoltre pvse vgsnon stanno segnalando spazio aggiuntivo non-assegnato nell'ambito LVM
Ho eseguito questo come una corsa a secco su una macchina virtuale e non ho riscontrato questo. Tuttavia, stavo spegnendo la VM e aumentando le dimensioni del suo dispositivo disco. Quindi non era online durante l'aumento delle dimensioni. Inoltre, le dimensioni dell'unità erano di molti ordini di grandezza inferiori per la VM.

Aggiornamento 1 'uscita in modalità x'pert richiesta da Micheal ...

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.

Quindi un possibile errore LBA?

— Vagnerr
fonte

In fdisk, vai in xmodalità e pert p, quindi vstampa nuovamente la tabella delle partizioni, quindi cancellala.

— Michael Hampton,

Qualcuno ha risolto fdisk per supportare GPT? L'ultima volta che l'ho provato su un disco GPT mi ha avvertito che avrei dovuto usare gnu parted, ma è passato molto tempo.

— DerfK,

Sì, le versioni moderne di fdisk possono gestire GPT.

— Spooler,

Suppongo che GPT sia il motivo per cui mi è stato offerto 2-128 come conteggio delle partizioni anziché essere limitato a 4 partizioni. è giusto?

— Vagnerr,

@Vagnerr sì, GPT supporta più partizioni rispetto al vecchio schema MBR.

— DerfK,

Risposte:

Il problema era la posizione della tabella delle partizioni di backup. Normalmente ci si aspetta una tabella delle partizioni primaria all'inizio e una tabella delle partizioni di backup alla fine. Il ridimensionamento del disco ha reso disponibili più settori ma non ha mai spostato la tabella di backup. fdisk non mi è piaciuto e credo che fosse il MyLBA mismatch with real position at backup header.messaggio di errore. Non esattamente chiaro

Sono passato da fdiska gdiske l'uscita era un po 'diversa. In gdisk hai ...

r       recovery and transformation options (experts only)

vPassando a questo ed eseguendo erify ha dato il messaggio di errore più utile ...

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!

In gdiskmodalità esperto è disponibile la seguente opzione ...

e       relocate backup data structures to the end of the disk

... eseguito correttamente e l'output di verifica ora era ...

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.

La stampa della tabella delle partizioni ora mostrava l'ultimo settore utilizzabile come 56 miliardi anziché 39 miliardi e sono stato in grado di creare la nuova partizione e aggiungerla in LVM che, se qualcuno è interessato, i passaggi per questo erano ...

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

— Vagnerr
fonte

Per chiarire, al fine di evitare la necessità di riavviare dopo il riposizionamento delle strutture dei dati di backup, è stato eseguito partprobe? Inoltre, questo post ti salva la vita . Grazie per aver contribuito.

— Swivel

@Swivel È corretto. Senza eseguire partprob o riavviare il dispositivo sdb2 non verrà creato nella directory / dev e che deve essere lì per eseguire i comandi lvm che seguono. Sono contento che il post ti abbia aiutato :-)

— Vagnerr,

La chiave di questo snafu è questa:

Last LBA: 39064698846

L'etichetta GPT non riflette le dimensioni medie, che sono state modificate. fdiskcerca lo spazio libero in un modo che non è perfetto, ma almeno logico: cerca il primo settore disponibile nel più grande spazio libero disponibile tra il primo e l'ultimo LBA di GPT Label .

Un modo per aggirarlo potrebbe essere utilizzare sfdiskper scaricare l'etichetta, modificarla in modo appropriato per le dimensioni medie e riscriverla, o un uso migliore partedche dovrebbe occuparsi di quel problema IMO.

— Peter Zhabin
fonte