Eu quero executar os autotestes do smartctl para verificar a integridade das unidades em minha matriz RAID (PERC 5 / i). A matriz está em sda e compreende seis unidades. Eu posso verificar o status usando
sudo smartctl /dev/sda -d megaraid,0 -a
E vejo que o SMART está disponível e ativado em todas as unidades. Eu tentei executar auto-testes usando
sudo smartctl /dev/sda -d megaraid,0 -t short
e
sudo smartctl /dev/sda -d megaraid,0 -t long
Eu também tentei em todas as unidades 0-5. Não importa o que eu tente, quando eu corro:
sudo smartctl /dev/sda -d megaraid,0 -l selftest
Eu sempre obtenho o mesmo resultado, que parece sempre informar que nunca fiz um autoteste.
/dev/sda [megaraid_disk_00] [SAT]: Device open changed type from 'megaraid' to 'sat'
===START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
No self-tests have been logged. [To run self-tests, use: smartctl -t]
Pelo que eu li, eu não deveria ter problemas em executar os autotestes curtos e longos no array enquanto ele está montado. Alguém mais tem experiência em executar esses testes em um array PERC 5 / i que poderia dar uma idéia do que está causando o problema?
(smartmontools release 5.40 de 2009-12-09 at 21:00:32 UTC)
Este é um controlador de matriz de hardware Dell Perc 5 / i. Deixe-o fazer as coisas . Se você não tem luzes vermelhas ou amarelas nos discos, por que está preocupado com a execução de seu próprio SMART testes?
O controlador de array usa S.M.A.R.T. além de outros recursos / teste para determinar a integridade da unidade. Executar sua própria análise é desnecessário.
Este é um tópico antigo, mas deixe-me dizer que os controladores de HW, em particular, as leituras de patrulha têm muito a desejar. Aparentemente, eles devem testar a superfície do disco e corrigir problemas, e às vezes fazem isso, mas nunca corrigem setores pendentes em superfícies, enquanto podem e devem usar os dados redundantes. Portanto, quando você tem um disco rígido com erros inteligentes e deseja desativá-lo, não pode realmente saber que a outra unidade (em raid1, por exemplo) é totalmente legível, portanto, um teste longo inteligente seria desejável. Sim ... Concordo que uma verificação de consistência pode funcionar, mas isso degradará a matriz e você perderá os dados que poderia ter salvo com uma matriz ideal que tenha erros não descobertos ou conhecidos, mas que ainda tenha dados 100% legíveis. O ponto é que o firmware do ataque é buggy e os funcionamentos internos são excessivamente empolgados. Eles dão uma falsa segurança que é mais perigosa do que um sistema que você sabe que falhará em um certo ponto.