Como posso rastrear a causa da corrupção do sistema de arquivos ext3?

Question

Temos um ambiente VMware vSphere 5 executando máquinas virtuais do CentOS 5.8. Nas últimas duas semanas, tivemos cinco incidentes de máquinas virtuais com um sistema de arquivos corrompido, exigindo que um fsck fosse reparado.

Aqui está o que vemos nos registros:

Nov 14 14:39:28 hostname kernel: EXT3-fs error (device dm-2): htree_dirblock_to_tree: bad entry in directory #2392098: rec_len is smaller than minimal - offset=0, inode=0, rec_len=0, name_len=0
Nov 14 14:39:28 hostname kernel: Aborting journal on device dm-2.
Nov 14 14:39:28 hostname kernel: __journal_remove_journal_head: freeing b_committed_data
Nov 14 14:39:28 hostname last message repeated 4 times
Nov 14 14:39:28 hostname kernel: ext3_abort called.
Nov 14 14:39:28 hostname kernel: EXT3-fs error (device dm-2): ext3_journal_start_sb: Detected aborted journal
Nov 14 14:39:28 hostname kernel: Remounting filesystem read-only
Nov 14 14:39:28 hostname kernel: EXT3-fs error (device dm-2): htree_dirblock_to_tree: bad entry in directory #2392099: rec_len is smaller than minimal - offset=0, inode=0, rec_len=0, name_len=0
Nov 14 14:31:17 hostname ntpd[3041]: synchronized to 194.238.48.2, stratum 2
Nov 14 15:00:40 hostname kernel: EXT3-fs error (device dm-2): htree_dirblock_to_tree: bad entry in directory #2162743: rec_len is smaller than minimal - offset=0, inode=0, rec_len=0, name_len=0
Nov 14 15:13:17 hostname kernel: __journal_remove_journal_head: freeing b_committed_data

O problema parece acontecer enquanto nós estamos rsync'ing dados de aplicativos de outro servidor. Até agora, não conseguimos reproduzir o problema ou identificar uma causa raiz.

Depois que alguns servidores tiveram esse problema, presumimos que havia um problema com o modelo, então descartamos todas as VMs clonadas do modelo, destruímos o modelo e construímos um novo modelo a partir do zero, instalado a partir de um modelo. recém-baixado CentOS ISO.

Usamos o SAN do HP EVA para datastores e passamos de um 4400 para um 6300 após o primeiro problema. Desde a mudança e reconstrução de novas máquinas virtuais, vimos o problema duas vezes. Em uma VM encerramos o servidor, removemos duas CPUs virtuais e iniciamos o backup novamente, o problema se apresentou quase imediatamente. Na outra VM, nós a reinicializamos e o problema aconteceu meia hora depois.

Qualquer dica ou ponteiros na direção correta seria bem-vinda.

    

Answer 1

Existe um KB referente ao HP EVA, especialmente se você estiver usando o Round Robin PSP. Em primeiro lugar você deve verificar o vmkernel.log para verificar erros de armazenamento. Entrada em KB relevante (pdf)

Para otimizar o desempenho do array EVA, a HP recomenda alterar o valor IOPS de balanceamento de carga de round robin padrão para 1. Essa atualização deve ser executada para cada Vdisk usando o seguinte comando no ESX4.x:

esxcli nmp roundrobin setconfig -t iops -I 1 -d naa.xxxxxxxxx

Para o ESXi5:

for i in 'esxcli storage nmp device list | grep naa.600' ; do esxcli storage nmp psp roundrobin deviceconfig set -t iops –I 1 -device $i; done

    

Answer 2

Se o problema puder ser replicado somente quando você estiver rsyncing dados de um servidor para outro, isso significa que está relacionado a como a consistência de dados está sendo vista do ponto do kernel. Se o kernel acha que o sistema de arquivos vai ser danificado ou tem algum dano, ele irá transformar o fs em somente leitura.

Eu não sei muito sobre o HP EVA, mas ele tem cache de gravação com bateria. Em caso afirmativo, você pode desativar o cache de gravação em disco e usar o cache de gravação da matriz de SAN. Para fazer isso, monte com mount -o barrier = 1 e veja se você vê alguma melhoria.

E eu tenho um instinto de que isso está de alguma forma relacionado ao armazenamento, não a qualquer falha de fs. Eu não tenho certeza de como provar isso, mas a maioria dos casos que eu vi sobre a corrupção do fs de alguma forma e em algum lugar envolve o armazenamento como o culpado, se não o principal.