kernel: erro de E / S de confirmação de diário

9

Estou tendo alguns problemas com um servidor Dell 1950. Estou instalando o RHEL 4.6 junto com o Oracle e alguns outros softwares aqui.

Estou recebendo aleatoriamente uma mensagem de erro dizendo "kernel: journal commit I / O error" na minha sessão ssh e no monitor que eu conectei ao servidor, vejo um erro rolando pela mensagem "EXT3-fs error (device sda5) em start_transaction: o diário foi abortado. "

Isso já aconteceu várias vezes, mas nunca no mesmo ponto durante a instalação. Na verdade, desta última vez, o sistema estava em funcionamento e eu estava apenas tentando importar um banco de dados para o oracle.

Isso aconteceu em vários discos rígidos, por isso tenho certeza de que esse não é o problema. Isso me faz pensar que o controlador RAID está indo mal.

O que é que vocês acham?

** ATUALIZAÇÃO **

Tenho certeza que foi um disco rígido ruim. Joguei outra unidade no servidor e ela está em execução há cerca de 48 horas sem problemas.

linux raid ext3

— jasondewitt
fonte

9

Eu já vi esses erros antes, mas não durante o processo de instalação.

Isso significa que a unidade obteve erros suficientes que o sistema operacional levou ao modo somente leitura. Se você pudesse encontrar os logs completos, provavelmente haveria alguns erros de E / S que tentaram novamente e funcionaram antes dos erros de falha total que você viu. Algo com os blocos reais mencionados.

É um erro no sistema de armazenamento. Definitivamente, é a placa RAID, as unidades no conjunto RAID, os cabos da placa para as unidades, o backplane ao qual as unidades se conectam, o slot no qual a placa RAID está conectada, a fonte de alimentação para os discos rígidos ou outra coisa entre a CPU e os blocos de armazenamento reais.

— freiheit
fonte

2

Três possibilidades vêm à mente:

Há problemas de memória (geralmente causam falhas "aleatórias"). Se você tem ram ECC, é óbvio que é menos provável.
Há algum problema com o barramento. Eu tive o mesmo problema com um controlador APIC quebrado em uma placa-mãe Tyan dual Opteron há alguns anos atrás. Havia outras entradas de log que sugeriam isso, mas a maior parte dos sintomas era corrupção aleatória em unidades de disco com remontagens automáticas somente leitura. No meu caso, eu sabia que não estava relacionado ao disco, porque era uma caixa externa do FC RAID e estava bem.
O controlador RAID é um beliche.

Isso está na ordem em que considero os problemas.

— Alexandre Carmel-Veilleux
fonte

Provavelmente não há problemas de memória; esses seriam mais propensos a causar segfaults e mais erros aleatórios, não se restringindo apenas ao armazenamento.

— Freiheit

Verdade. Mas, em uma situação de instalação ou inicialização antecipada, quanto maior o uso da memória, maior é o cache do buffer, portanto os problemas tendem a aparecer primeiro. Uma vez que a máquina está executando alguma carga por um tempo, o processo do usuário domina a E / S de memória e, portanto, a prevalência do segfault. Dito isto, um PE1950 deve ter processadores Xeon e ram ECC, para que a RAM possa detectá-lo e reportá-lo ao Linux.

— Alexandre Carmel-Veilleux

2

Pode ser que o controlador RAID esteja com problemas, como você disse (tente um sobressalente, se você tiver um.) Pode ser o driver do controlador (verifique se há drivers alternativos, se disponíveis, mesmo que o desempenho seja pior, é bom ter um ponto de referência .) Pode ser o kernel (menos provável que no RHEL, é bastante bem testado.) Pode haver uma RAM ruim atrapalhando o cache do bloco.

Um problema de hardware é a causa mais provável, com base no comportamento de erro aparentemente aleatório.

— Mihai Limbăşan
fonte

2

Verifique se o disco não está cheio - em particular a partição raiz. Use df para ver o uso do disco do sistema de arquivos:

df -h

Procure partições próximas ou iguais a 100% de utilização

— Peter H
fonte

-5

tentar:

shutdown -rF now