Ext3 continua recebendo o erro de diário e tornando-se somente leitura

Question

Eu tenho um servidor RHEL5.5 x86_64 com 2 HBAs conectando a storage arrays EMC e HP. O EMC PowerPath está instalado porque meu fornecedor da EMC insiste nisso.

Meu problema é que os volumes no armazenamento da HP geralmente apresentam erros de registro (veja abaixo) e entram no modo somente leitura.

É um problema de SAN ou sistema operacional? Como posso resolver isso?

May 27 14:16:57 cvoddv01 kernel: journal_bmap: journal block not found at offset 6156 on dm-7
May 27 14:16:57 cvoddv01 kernel: Aborting journal on device dm-7.
May 27 14:16:57 cvoddv01 kernel: ext3_abort called.
May 27 14:16:57 cvoddv01 kernel: EXT3-fs error (device dm-7): ext3_journal_start_sb: Detected aborted journal
May 27 14:16:57 cvoddv01 kernel: Remounting filesystem read-only
May 27 14:16:57 cvoddv01 kernel: __journal_remove_journal_head: freeing b_frozen_data
May 27 14:16:57 cvoddv01 kernel: __journal_remove_journal_head: freeing b_committed_data
May 27 14:16:57 cvoddv01 kernel: __journal_remove_journal_head: freeing b_frozen_data
May 27 14:17:36 cvoddv01 kernel: ext3_abort called.
May 27 14:17:36 cvoddv01 kernel: EXT3-fs error (device dm-7): ext3_put_super: Couldn't clean up the journal

Meu modprobe.conf é:

alias scsi_hostadapter mptbase
alias scsi_hostadapter1 mptspi
alias scsi_hostadapter2 cciss
alias scsi_hostadapter3 ata_piix
alias scsi_hostadapter4 qla2xxx
alias eth0 e1000e
alias eth2 e1000e
alias eth1 e1000e
alias eth3 e1000e
alias eth4 bnx2
alias eth5 bnx2
#Added by HP rpm installer
alias scsi_hostadapter_mptscsih_module mptscsih
#Added by HP rpm installer
alias scsi_hostadapter_mptsas_module mptsas
options qla2xxx ql2xmaxqdepth=16 ql2xloginretrycount=30 qlport_down_retry=64
options lpfc lpfc_lun_queue_depth=16 lpfc_nodev_tmo=30 lpfc_discovery_threads=32
###BEGINPP
include /etc/modprobe.conf.pp
###ENDPP

O / etc / fstab é:

/dev/VolGroup00/LogVol00 /                       ext3    defaults        1 1
LABEL=/boot             /boot                   ext3    defaults        1 2
tmpfs                   /dev/shm                tmpfs   defaults        0 0
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
sysfs                   /sys                    sysfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0
/dev/VolGroup00/LogVol01 swap                    swap    defaults        0 0
#/dev/sdae1             /mnt/sda1               ext3    defaults        0 0
#/dev/sdaf1             /mnt/sdb1               ext3    defaults        0 0
#/dev/sdag1             /mnt/sdc1               ext3    defaults        0 0
#/dev/sdah1             /mnt/sdd1               ext3    defaults        0 0
/dev/vg01/lvu02         /u02                    ext3    defaults        0 0
/dev/vg01/lvu03         /u03                    ext3    defaults        0 0
/dev/vg01/lvu04         /u04                    ext3    defaults        0 0
/dev/vg01/lvu05         /u05                    ext3    defaults        0 0
/dev/vg02/lvu06         /u06                    ext3    defaults        0 0
/dev/vg02/lvu07         /u07                    ext3    defaults        0 0
/dev/vg02/lvu08         /u08                    ext3    defaults        0 0
/dev/vg02/lvu09         /u09                    ext3    defaults        0 0
shmfs                   /dev/shm                tmpfs   rw,size=22g     0 0

uanme -a

Linux cvoddv01.globetel.com 2.6.18-194.el5 #1 SMP Tue Mar 16 21:52:39 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux

    

Answer 1

Você deve estar usando o dm-multipath ou o PowerPath, não os dois ao mesmo tempo.

Do Guia de administração do PowerPath :

PowerPath is not compatible with the native Linux device mapper (DM-MPIO). Configuring both products on the same host can cause system instability. EMC recommends that you do not configure the native device mapper on a host on which PowerPath will be installed.

    

Answer 2

Você tentou remover e reconstruir os diários? Existem alguns posts em torno dos quais explicam como recriar seus diários EXT3. Se uma reconstrução das revistas ainda lhe der erros, eu investigaria o hardware / drivers. - Desculpe, não posso ser mais detalhado aqui.

    

Answer 3

O dispositivo afetado no log em anexo é dm-7, portanto, espero que você use multipathd para o armazenamento da HP, certo? Se fizer isso, anexe também sua configuração de vários caminhos.

el5 no nome do kernel sugere RHEL 5. Se você tiver um contrato de suporte, entre em contato com eles assim que possível, eles poderão ajudá-lo ao máximo.

O que temos certeza dos dados é que uma tentativa de acessar o log foi feita, falhou e o sistema operacional fez a única coisa que pôde, ou seja, congelou o sistema de arquivos para evitar danificá-lo com gravações.

A falha pode estar em qualquer um dos componentes:

1. Armazenamento - o sistema de arquivos está OK após uma remontagem? Você pode fazer um fsck completo para ver se o problema com o diário é a única coisa que deu errado, ou talvez você tenha muita corrupção silenciosa, e somente quando o bug atinge o diário fica visível.
2. Este LUN específico. Você pode (como em: é possível) formatá-lo, restaurar dados e ver se isso acontece novamente?
3. Você pode criar outro LUN no mesmo array e ver se consegue reproduzir o erro? Um LUN em um array diferente no mesmo armazenamento?
4. Multipathing - você pode reproduzir erros se acessar o armazenamento diretamente, em apenas um caminho (isso requer alterações no zoneamento SAN ou lun masking no armazenamento).
5. Colisão de drivers entre o PowerPath e o multipathing nativo. Você pode reproduzir um erro no mesmo LUN quando não tiver o powerpath instalado?

Eu não acho que seria um bug no código ext3, porque já existe há algum tempo, mas você usa alguma opção de montagem exótica? Você tem bloqueio de 4K no armazenamento? Alguma coisa exótica?

O servidor já funcionou bem? Em caso afirmativo, você pode nomear a alteração que causou a falha?

Se você for solucionar o problema sozinho, sua melhor opção seria criar um conjunto mínimo de opções que façam o sistema falhar. Uma abordagem mais prática poderia ser reorganizar seu armazenamento para que você use somente o armazenamento de um fornecedor em qualquer servidor. Isso pode economizar um pingue-pongue entre os fornecedores.

Sua melhor aposta, no entanto, seria entrar em contato com seu fornecedor de SO e fazê-lo impulsionar o caso, eu acho.