Determinando a causa da falha do SSD após 30 minutos

1

Temos uma unidade SSD de 64 GB em um servidor em torre com uma empresa de colocation local. Esta unidade e o sistema de entrada foram construídos há cerca de seis meses, novas peças.

Até este fim de semana, o SSD / sistema estava funcionando perfeitamente. Estamos rodando o CentOS 6.2

Depois de inicializar perfeitamente, o sistema pode ser usado cerca de 20 a 30 minutos (sem consistência real com o tempo) antes que o disco comece a agir de maneira engraçada.

As bibliotecas começam a dizer que não podem carregar, o ssh começa a negar logins de chaves públicas. O desligamento começa dizendo "erro de entrada / saída". Alguns programas começam a indicar que a unidade é somente leitura.

Apenas 25 GB dos 64 GB são usados.

Não consigo encontrar erros que indiquem o que aconteceu. Eu tentei rodar o fsck de um live cd no drive e ele não mostrou problemas e a maior parte do tempo o boot funciona bem. Houve uma inicialização que dizia "não foi possível encontrar os", mas isso não está acontecendo mais.

Onde posso encontrar registros sobre o que acontece? Existem outras verificações de disco que devo fazer? Parece um problema reparável, e não que eu precise de uma nova unidade.

Atualização:

Eu habilitei o SMART após reinicializar o servidor. Após 1 hora de uptime e operação normal do sistema (os serviços em execução são httpd, mysql, mas muito pouco ou nenhum tráfego), de repente as coisas simplesmente param de funcionar. Durante a hora de atividade, ele respondeu com um PASS para a verificação de saúde inteligente. Após a hora, tentei novamente (através do webmin) e agora diz que o SMART está desativado.

O disco rígido agora está mostrando os mesmos problemas que eu vi antes - tentar a maioria dos comandos mostra "erro de entrada / saída".

A execução de uma verificação de integridade inteligente agora mostra:

Log Sense failed, IE page [scsi response fails sanity test]

O que posso fazer para descobrir o que está causando isso falhar após um período aleatório de tempo? Funciona perfeitamente por 30 a 60 minutos e então começa a agir de maneira estranha assim.

Atualização 2

Alguns pediram que eu tentasse o dmesg e este foi o resultado: link . Alguém mais recomendou que eu não assuma que é a unidade, mas possivelmente o controlador da unidade. Eu não entendo como determinar se o erro é o controlador versus a unidade - além de tentar uma unidade diferente. Se eu tiver que comprar uma placa-mãe ou unidade de substituição, preciso saber qual está falhando primeiro.

A execução do fsck mostra:

fsck from util-linux-ng 2.17.2
e2fsck 1.41.12 (17-May-2010)
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/mapper/vg_192-lv_root

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
    
por BotskoNet 23.04.2012 / 21:45

3 respostas

6

SSDs são notoriamente frágeis. Jeff Atwood descreve algumas taxas de falhas aqui . Eles falharão sem qualquer aviso e transformarão seus dados em uma memória distante.

Parece que é hora do RMA e restaurar a partir do backup. Não deve ser um problema, porque você não está executando um servidor de produção em um único disco não-RAID, certo? E você definitivamente tem backups recentes que você pode usar para se recuperar, certo?

certo?

    
por 23.04.2012 / 21:48
5

Se o seu disco rígido tiver estatísticas SMART (e é quase garantido que as tenha), use um utilitário SMART para abater todas as mensagens e estatísticas disponíveis. A resposta provavelmente está lá, ou pelo menos alguma sugestão de onde procurar em seguida.

EDITAR

Considere que você pode estar extraviando suas suspeitas. Seu controlador de unidade pode fazer parte do problema. Olhe em quais métricas são coletadas, bem como quais logs são criados. Mantê-lo no círculo de suspeitos por agora. Tudo na TI é culpado até que se prove inocente.

    
por 23.04.2012 / 21:48
1

Eu tive a mesma falha com o meu PC doméstico executando um sistema de arquivos EXT-4 em um SSD Crucial / Micron M4 de 64Gb. Eu corri smartctl -a no meu dispositivo e passou por todos os testes de forma satisfatória. Eu inicializei o meu servidor a partir de um CD systemrescue e reran smartctl e isso detectou firmware antigo, 0009 conhecido por causar problemas e desde a correção. Meu firmware está agora no lançamento 070H e os problemas desapareceram. Assim, a solução no meu caso foi visitar o site crucial e baixar uma imagem iso inicializável smal para atualizar meu firmware SSD. Não há mais erros de entrada / saída

    
por 23.01.2014 / 13:31

Tags