O firmware da unidade executa os testes.
Os detalhes dos testes podem ser lidos em, por exemplo, www.t13.org/Documents/UploadedDocuments/technical/e01137r0.pdf, que resume os elementos dos testes curtos e longos assim:
um segmento elétrico em que o inversor testa seus próprios componentes eletrônicos. Os testes específicos neste segmento são específicos do fornecedor, mas como exemplos: esse segmento pode incluir testes como um teste de RAM de buffer, um teste de circuito de leitura / gravação e / ou um teste dos elementos do cabeçote de leitura / gravação.
um segmento de busca / servo em que o inversor testa sua capacidade de encontrar e servo em trilhas de dados. A metodologia específica usada neste teste também é específica do fornecedor.
um segmento de verificação de leitura / verificação em que a unidade executa a verificação de leitura de alguma parte da superfície do disco. A quantidade e a localização da superfície digitalizada dependem da restrição de tempo de conclusão e são específicas do fornecedor.
Os critérios para o autoteste estendido são os mesmos do autoteste curto, com duas exceções: o segmento (3) do autoteste estendido deve ser uma verificação de leitura / verificação de toda a área de dados do usuário e não há limite de tempo máximo para o inversor executar o teste.
É seguro executar testes não destrutivos enquanto o sistema operacional estiver em execução, embora seja provável que haja algum impacto no desempenho. Como a smartctlpágina de manual diz para ambos -t shorte -t long,
Este comando pode ser dado na operação normal do sistema (a menos que seja executado no modo cativo)
Se você chamar o modo cativo com -C, smartctlassume que a unidade pode ser ocupada até a indisponibilidade. Isso não deve ser feito em uma unidade que o sistema operacional está usando.
Como a página de manual também sugere, o teste offline (que significa simplesmente teste periódico em segundo plano) não é confiável e nunca se tornou oficialmente parte das especificações do ATA. Eu corro o meu do cron, em vez disso; Dessa forma, eu sei quando eles devem acontecer e posso parar se precisar.
- Os resultados podem ser vistos na
smartctlsaída. Aqui está um com um teste em execução:
[imagens root @ risby] # smartctl -a / dev / sdb
smartctl 6.4 - 04/04/2015 - r4109 [x86_64-linux-4.1.6-201.fc22.x86_64] (compilação local)
Copyright (C) 2002-15, Bruce Allen, Christian Franke, www.smartmontools.org
[...]
Número de revisão 1 da estrutura de log de autoteste SMART
Num Test_Description Status Tempo restante da vida útil (horas) LBA_of_first_error
Nº 1 offline estendido concluído sem erro 00% 20567 -
# 2 Estendido offline concluído sem erro 00% 486 -
Número de revisão 0 da estrutura de dados de log de autoteste seletivo SMART
Nota: o número de revisão não 1 implica que nenhum autoteste seletivo foi executado
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Self_test_in_progress [90% restantes] (0-65535)
2 0 0 Não_teste
3 0 0 Não_teste
4 0 0 Não_teste
5 0 0 Não_teste
Observe dois testes concluídos anteriores (com 486 e 20567 horas de inicialização, respectivamente) e o atual em execução (10% concluído).
MadHatter apoia Monica
fonte
As implementações SMART são dependentes do fabricante, às vezes logs bastante extensos estão disponíveis via
smart -acomando. Aqui está o que eu recebo em uma das minhas unidades de criptografia automática da Hitachi :Este white paper lança alguma luz sobre os códigos de erro que aparecem no log. As abreviações de erro comuns são:
No meu caso, o erro IDNF (ID não encontrado) pode ser rastreado até um incidente quando a unidade foi conectada via adaptador USB-SATA e ficou com pouca energia, o que impediu que ela procurasse corretamente.
fonte