O Linux não pega a nova partição corretamente no pseudo-dispositivo emc

Question

Temos um servidor de banco de dados executando o oracle rac. Recentemente, ficamos sem espaço no LUN principal ao qual ele está conectado. Eu criei um novo LUN de 100 GB e concatenei isso no LUN existente, criando um novo MetaLUN. Depois de algumas bagunças, consegui que o linux reconhecesse o novo espaço. Em seguida, criei uma nova partição no pseudo-dispositivo para usar o novo espaço. Anteriormente, quando eu fiz isso em outro sistema, a próxima etapa é criar um disco ASM na nova partição e adicionar esse disco ao grupo de discos oracle. Isso, no entanto, falha. Estou ciente de vários problemas com o ASM e o powerpath, mas não acho que esse seja o problema aqui. Da mesma forma que investigamos o problema, descobri que um dos dispositivos lógicos subjacentes não reflete a mudança de tamanho. Veja abaixo:

O Powermt exibe todas as unidades lógicas subjacentes

[root@XXXXX~]# powermt display dev=emcpowerd  
Pseudo name=emcpowerd  
CLARiiON ID=CKM00091500009 [VFRAC2]  
Logical device ID=6006016030312200787502866C65DE11 [LUN 30]  
state=alive; policy=CLAROpt; priority=0; queued-IOs=0  

Owner: default=SP A, current=SP A       Array failover mode: 1  
'=============================================================================='
---------------- Host ---------------   - Stor -   -- I/O Path -  -- Stats ---  
'###  HW Path                I/O Paths    Interf.   Mode    State  Q-IOs Errors'
'=============================================================================='
   3 qla2xxx                   sde       SP A0     active  alive      0      0  
   3 qla2xxx                   sdj       SP B0     active  alive      0      0  
   4 qla2xxx                   sdo       SP A1     active  alive      0      0  
   4 qla2xxx                   sdt       SP B1     active  alive      0      0  

**Fdisk on the pseudo device shows correct space.**

[root@XXXXX ~]# fdisk -l /dev/emcpowerd  

Disk /dev/emcpowerd: 429.4 GB, 429496729600 bytes  
255 heads, 63 sectors/track, 52216 cylinders  
Units = cylinders of 16065 * 512 = 8225280 bytes  

         Device Boot      Start         End      Blocks   Id  System  
/dev/emcpowerd1               1       39162   314568733+  83  Linux  
/dev/emcpowerd2           39163       52216   104856255   83  Linux  

**fdisk on one of the logical units is wrong**

[root@XXXXX~]# fdisk -l /dev/sde  

Disk /dev/sde: 322.1 GB, 322122547200 bytes    
255 heads, 63 sectors/track, 39162 cylinders  
Units = cylinders of 16065 * 512 = 8225280 bytes  

   Device Boot      Start         End      Blocks   Id  System  
/dev/sde1               1       39162   314568733+  83  Linux  
/dev/sde2           39163       52216   104856255   83  Linux  

**fdisk on the rest of the units is fine**

[root@XXXXX ~]# fdisk -l /dev/sdj  
Disk /dev/sdj: 429.4 GB, 429496729600 bytes  
255 heads, 63 sectors/track, 52216 cylinders  
Units = cylinders of 16065 * 512 = 8225280 bytes  
   Device Boot      Start         End      Blocks   Id  System  
/dev/sdj1               1       39162   314568733+  83  Linux  
/dev/sdj2           39163       52216   104856255   83  Linux  

Além disso, quando criei a partição, o linux não criou nenhuma entrada no diretório / dev da segunda partição, então criei estas manualmente

[root@XXXXX dev]# mknod sde2 b 8 66
[root@XXXXX dev]# ls -al sd[ejot]?  
brw-r----- 1 root disk  8,  65 Dec 29 14:20 sde1  
brw-r--r-- 1 root disk  8,  66 Apr  8 20:31 sde2  
brw-r----- 1 root disk  8, 145 Dec 29 14:19 sdj1  
brw-r--r-- 1 root disk  8, 146 Apr  8 20:33 sdj2  
brw-r----- 1 root disk  8, 225 Apr  6 23:12 sdo1  
brw-r--r-- 1 root disk  8, 226 Apr  8 20:33 sdo2  
brw-r----- 1 root disk 65,  49 Dec 29 14:19 sdt1  
brw-r--r-- 1 root disk 65,  50 Apr  8 20:33 sdt2  

Este é um servidor de produção que não podemos reiniciar facilmente.

Qualquer ideia seria muito apreciada.

J

    

Answer 1

Além de partprobe , tente usar o utilitário blockdev para reler a tabela de partições do dispositivo:

blockdev --rereadpt /dev/sde

Então, o problema pode ser que o próprio LUN não tenha sido atualizado corretamente.

Você pode tentar emitir um comando rescan contra o host Fibre Channel ou SCSI através do sistema de arquivos /sys .

Algum tempo atrás, eu escrevi este script scsi_rescan_bus.sh para lidar com nossos dispositivos EMC Clariion:

#!/bin/sh
host_number="$1"
echo "1" > /sys/class/fc_host/host${host_number}/issue_lip
sleep 10
echo "- - -" > /sys/class/scsi_host/host${host_number}/scan

Não tenho certeza absoluta de que ainda funcionaria com os kernels e dispositivos modernos. Sempre teste isso em um ambiente de teste dedicado antes de tentar isso em produção!

Existem inúmeras dicas, por isso certifique-se de ler estes tópicos relevantes:

link

E a documentação oficial da Red Hat ("Online Storage Reconfiguration Guide"): link

    

Answer 2

tente executar /sbin/partprobe /dev/emcpowerd

partprobe diz ao seu kernel para reexaminar partições

    

Answer 3

Eu tenho investigado isso com a EMC e parece que não há maneira de contornar isso sem uma reinicialização. No entanto, como um trabalho em volta, criei um novo lun e tive que pegar dinamicamente e consegui fazer com que a Oracle reconhecesse isso. J