Depois que o fdisk de expansão de matriz RAID de hardware não me permite usar setores disponíveis adicionais

Temos uma grande variedade de raides de hardware de ~ 18 TB em um Dell R720xd. Atualmente, o array RAID5 consiste em 6x4TB e eu precisava estendê-lo.

Etapa 1 expanda a matriz de ataques de hardware.

Simples o suficiente se você tiver as ferramentas de administração da dell instaladas.

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

(os novos discos foram os dois últimos, o que pode ser confirmado usando a omreportferramenta) Tudo correu bem, apesar de demorar um pouco, e eu pude confirmar que a matriz foi expandida.

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

Etapa 2 nova partição

Portanto, o vdisk agora está relatando o tamanho aumentado (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

No entanto, quando vou adicionar uma partição adicional ao disco, acontece o seguinte ...

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

Agora tenho cerca de 16 bilhões de setores a mais no disco, mas não posso usá-los. Só me são oferecidos os setores 34-2047. Não consigo alocar os 8 TB de novo espaço, embora atualmente esteja configurado com apenas uma única partição.

A outra coisa que me pareceu estranha foi o fato de me oferecerem os números de partição 2-128, não simplesmente 2-4. A tabela de partições não mostra nenhuma partição estendida, então eu esperaria que isso me limite a apenas 4 partições inicialmente.

Falta alguma coisa?

A máquina foi reinicializada desde que a matriz da unidade foi expandida. Antes desse fdisk reportaria apenas os 18 TB originais
Tentar cfdiskapenas relatar 2015 setores disponíveis na faixa de 39 bilhões, apesar de reportar 25 TB no total.
Não queremos excluir e recriar a partição se pudermos evitá-la, pois podemos perder todos os dados. Preferimos simplesmente estender o grupo de volumes LVM com a nova partição, uma vez concluída.
É um problema semelhante ao de Outra questão de falha no servidor , mas não estou limitado por ter ficado sem partições e não acho que estou sendo restringido por uma partição estendida.
Seu tamanho do setor não está sendo expandido pela expansão da unidade . Se o fdisk não informasse o aumento da contagem do setor, eu teria pensado. Além disso, pvse vgsnão estão relatando espaço adicional não alocado no LVM
Eu executei isso como uma execução a seco em uma máquina virtual e não tive essa experiência. No entanto, eu estava desligando a VM e aumentando o tamanho do dispositivo de disco. Portanto, não estava online durante o aumento de tamanho. Além disso, os tamanhos das unidades eram muitas ordens de magnitude menores para o vm.

Atualização 1 saída do modo 'x'pert solicitada por 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.

Então, um possível erro do LBA?

— Vagnerr
fonte

Em fdiskfavor, entre no xmodo e pert, em seguida, parme a tabela de partição novamente e depois a verite.

— Michael Hampton

Alguém corrigiu o fdisk para dar suporte à GPT? A última vez que tentei em uma unidade GPT, me deu um aviso de que eu realmente deveria usar o gnu parted, mas faz muito tempo.

— DerfK 17/02

Sim, as versões modernas do fdisk podem lidar com o GPT.

— Spooler

Presumo que a GPT seja a razão pela qual me ofereceram 2-128 como uma contagem de partições, em vez de limitar-me a 4 partições. Isso está certo?

— Vagnerr 17/02/19

@ Vagnerr sim, o GPT suporta mais partições do que o antigo esquema MBR.

— DerfK 17/02

Respostas:

O problema foi o local da tabela da partição de backup. Normalmente, você espera a tabela de partição primária na tabela de partição inicial e de backup no final. O redimensionamento do disco disponibilizou mais setores, mas nunca moveu a tabela de backup. O fdisk não gostou disso e acredito que essa foi a MyLBA mismatch with real position at backup header.mensagem de erro. Não é exatamente claro.

Mudei de fdiskpara gdiske a saída foi um pouco diferente. No gdisk você tem ...

r       recovery and transformation options (experts only)

Ao entrar nisso e executar o verify, deu a mensagem de erro mais útil ...

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!

No gdiskmodo especialista, existe a seguinte opção ...

e       relocate backup data structures to the end of the disk

... que foi executado com sucesso e a saída de verificação estava agora ...

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.

Imprimir a tabela de partição agora mostrava o último setor utilizável como 56 bilhões em vez de 39 bilhões e eu pude criar a nova partição e adicioná-la ao LVM que, se alguém estiver interessado, as etapas para isso foram ...

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

Para esclarecer, para evitar a necessidade de reinicialização após a realocação das estruturas de dados de backup, você executou partprobe? Além disso, este post é um salva-vidas . Obrigado por contribuir.

— Giratório

@ Swivel Isso está correto. Sem executar o partprob ou a reinicialização do dispositivo sdb2 não será criado no diretório / dev e ele precisa estar lá para executar os comandos lvm a seguir. Fico feliz a mensagem que você ajudou :-)

— Vagnerr

A chave para este snafu é esta:

Last LBA: 39064698846

Seu rótulo GPT não reflete o tamanho médio, que foi alterado. fdiskprocura espaço livre de uma maneira que não seja perfeita, mas pelo menos lógica - procura o primeiro setor disponível no maior espaço livre disponível entre o primeiro e o último LBAs da GPT Label .

Uma maneira de contornar isso pode ser usar sfdiskpara despejar o rótulo, editá-lo adequadamente para o tamanho médio e gravá-lo de volta ou usar melhor o partedque deve resolver esse problema da IMO.

— Peter Zhabin
fonte