Após a expansão do array RAID por hardware, o fdisk não me permite usar outros setores disponíveis

7

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

Etapa 1 expanda o array de raids 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 ferramenta omreport ). Tudo correu bem, embora demore um pouco, e eu pude confirmar que o array foi expandido.

% 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 (26TB). e fdisk concordam ...

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 adicionais no disco, mas não posso usá-los. Eu sou oferecido apenas Sectores 34-2047. Eu não posso alocar o 8TB de espaço novo, embora eu esteja atualmente configurado com apenas uma única partição.

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

Há algo que eu esteja sentindo falta?

  • A máquina foi reinicializada desde que a matriz da unidade foi expandida. Antes disso, o fdisk informava apenas os 18 TB originais
  • A tentativa de cfdisk apenas informa os setores de 2015 disponíveis no intervalo 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 poderemos perder todos os dados. Estamos preferindo simplesmente estender o grupo de volumes LVM com a nova partição, uma vez feito.
  • É um problema semelhante ao Outra questão de falha do servidor , mas eu não estou limitado por ter ficado sem partições, e eu não acho que estou sendo restringido por uma partição estendida.
  • Não é tamanho do setor que está sendo expandido pela expansão da unidade . Se fosse fdisk não estaria relatando o aumento da contagem do setor, eu teria pensado. Além disso, pvs e vgs não estão reportando nenhum espaço adicional não alocado sob o LVM
  • Eu executei isso como uma execução a seco em uma máquina virtual e não experimentei isso. No entanto, eu estava desligando a VM e aumentando o tamanho do dispositivo de disco. Por isso, não ficou online durante o aumento de tamanho. Além disso, os tamanhos das unidades eram muito menores em magnitude para a 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?

    
por Vagnerr 17.02.2017 / 17:04

2 respostas

1

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

Eu mudei de fdisk para gdisk e a saída foi um pouco diferente. No gdisk você tem ...

r       recovery and transformation options (experts only)

Ao entrar nisso e executar v erify, 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!

Em gdisk expert mode existe a seguinte opção ...

e       relocate backup data structures to the end of the disk

... que foi executada com sucesso e a saída de verificação foi 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.

A impressão da tabela de partições agora mostrava o último setor utilizável como 56 bilhões, em vez de 39 bilhões, e consegui criar a nova partição e adicioná-la ao LVM. 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
    
por 20.02.2017 / 17:18
2

A chave para essa confusão é esta:

Last LBA: 39064698846

O seu rótulo GPT não reflete o tamanho médio, que foi alterado. fdisk procura espaço livre de uma maneira que não é 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 Etiqueta da GPT .

Uma maneira de contornar isso pode ser usar sfdisk para despejar o rótulo, editá-lo adequadamente para seu tamanho médio e gravá-lo novamente ou usar melhor parted que deve cuidar desse problema IMO.

    
por 20.02.2017 / 11:32