Después de la expansión de la matriz RAID de hardware, fdisk no me permitirá usar sectores adicionales disponibles

Tenemos una gran matriz RAID de hardware de ~ 18 TB en un Dell R720xd. Actualmente, la matriz RAID5 consta de 6x4TB y necesitaba extenderla.

Paso 1 expanda la matriz de raid de hardware.

Suficientemente simple si tiene instaladas las herramientas de administración de Dell.

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

(los nuevos discos fueron los dos últimos, lo que puede confirmarse mediante el uso de la omreportherramienta). Todo salió bien aunque lleva un tiempo, y pude confirmar que la matriz se había 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
...

Paso 2 nueva partición

Por lo tanto, el disco virtual ahora informa el aumento del tamaño (26 TB). y fdiskestá de acuerdo ...

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

Sin embargo, cuando voy a agregar una partición adicional al disco, sucede lo siguiente ...

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

Ahora tengo unos 16 mil millones más de sectores en el disco, pero no puedo usarlos. Solo me ofrecen los Sectores 34-2047. No puedo asignar los 8 TB de espacio nuevo a pesar de que actualmente estoy configurado con una sola partición.

La otra cosa que me pareció extraña fue el hecho de que me ofrecieron los números de partición 2-128, no simplemente 2-4. La tabla de particiones no muestra ninguna partición extendida, por lo que esperaba que eso me limitara a solo 4 particiones inicialmente.

¿Hay algo que me falta?

La máquina se ha reiniciado desde que se amplió la matriz de unidades. Antes de eso, fdisk informaría solo los 18TB originales
Intentar en su cfdisklugar solo informa 2015 sectores disponibles en el rango de 39 mil millones a pesar de informar 25TB en general.
No podemos eliminar y volver a crear la partición si podemos evitarla, dado que podríamos perder todos los datos. Preferimos simplemente extender el grupo de volúmenes LVM con la nueva partición una vez hecha.
Es un problema similar a otra pregunta de Falla del servidor , pero no estoy limitado por haberme quedado sin particiones, y no creo que me esté restringiendo una partición extendida.
No se expande el tamaño del sector por la expansión de la unidad . Si fdisk no informara el aumento del recuento del sector, habría pensado. Además, pvsy vgsno informan ningún espacio adicional no asignado bajo LVM
Ejecuté esto como una ejecución en seco en una máquina virtual y no experimenté esto. Sin embargo, estaba apagando el vm y aumentando el tamaño de su dispositivo de disco. Por lo tanto, no estuvo en línea durante el aumento de tamaño. Además, los tamaños de las unidades eran muchos órdenes de magnitud más pequeños para la VM.

Actualización de la salida del modo 1 '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.

Entonces, ¿un posible error de LBA?

— Vagnerr
fuente

En, fdiskpor favor, vaya al xmodo e pert, luego pvuelva a vlimpiar la tabla de particiones y luego erréguela.

— Michael Hampton

¿Alguien arregló fdisk para soportar GPT? La última vez que lo probé en un disco GPT me dio una advertencia de que realmente debería usar GNU Parted, pero ha pasado mucho tiempo.

— DerfK

Sí, las versiones modernas de fdisk pueden manejar GPT.

— Spooler

Supongo que GPT es la razón por la que me ofrecieron 2-128 como recuento de particiones en lugar de limitarme a 4 particiones. ¿está bien?

— Vagnerr

@Vagnerr sí, GPT admite más particiones que el antiguo esquema MBR.

— DerfK

Respuestas:

El problema era la ubicación de la tabla de partición de respaldo. Normalmente espera una tabla de partición primaria al inicio y una tabla de partición de respaldo al final. El cambio de tamaño del disco hizo que hubiera más sectores disponibles, pero nunca movió la tabla de respaldo. A fdisk no le gustó esto y creo que ese fue el MyLBA mismatch with real position at backup header.mensaje de error. No exactamente claro.

Cambié de fdiska gdisky la salida fue un poco diferente. En gdisk tienes ...

r       recovery and transformation options (experts only)

Al entrar en eso y ejecutar verify dio el mensaje de error más ú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!

En gdiskmodo experto, existe la siguiente opción ...

e       relocate backup data structures to the end of the disk

... que se ejecutó con éxito, y la salida de verificación ahora ...

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 impresión de la tabla de particiones ahora mostraba el último sector utilizable como 56 mil millones en lugar de 39 mil millones y pude crear la nueva partición y agregarla a LVM, que si alguien está interesado, los pasos para eso fueron ...

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
fuente

Para aclarar, para evitar tener que reiniciar después de reubicar las estructuras de datos de respaldo, ¿ejecutó partprobe? Además, esta publicación es un salvavidas . Gracias por contribuir

— Giratorio

@Swivel Eso es correcto. Sin ejecutar partprob, o reiniciar el dispositivo sdb2 no se creará en el directorio / dev y eso debe estar allí para ejecutar los comandos lvm que siguen. Me alegra que la publicación te haya ayudado :-)

— Vagnerr

La clave de este problema es esta:

Last LBA: 39064698846

Su etiqueta GPT no refleja el tamaño mediano, que ha cambiado. fdiskbusca espacio libre de una manera que no sea perfecta, pero al menos lógica: busca el primer sector disponible en el mayor espacio libre disponible entre el primer y el último LBA de GPT Label .

Una forma de evitarlo puede ser usar sfdiskpara volcar la etiqueta, editarla adecuadamente a su tamaño mediano y volver a escribirla, o un mejor uso partedque debería solucionar ese problema de la OMI.

— Peter Zhabin
fuente