Introdução Ao SMART

O que é Smart?

O SMART (Self-Monitoring, Analysis and Reporting Technology) é um conjunto de recursos integrado ao firmware dos dispositivos de armazenamento (como HDDs, SSDs e unidades NVMe), com ele, podemos saber o estado de saúde desses dispositivos e identificar sinais que possam indicar falhas iminentes. Os dispositivos de armazenamento possuem isso integrado e sempre podemos consultar os valores.

O firmware do dispositivo coleta métricas internas e registra qualquer anomalia que possa indicar desgaste, falhas mecânicas ou problemas na memória flash no caso dos SSDs. Esse monitoramento é contínuo e não gera impacto perceptível no uso normal.

Cada dispositivo mantém um conjunto de atributos SMART, esses atributos variam de acordo com o fabricante e o modelo do equipamento. Cada atributo possui um valor bruto, que é a métrica real e um valor normalizado, que é usado pelo fabricante para avaliar se o comportamento do disco permanece dentro do esperado ou se já indica algum desgaste.

Testes

Os testes são executados pelo próprio hardware, ou seja, pelo dispositivo de armazenamento, seja ele HDD ou SSD. O sistema operacional apenas envia o comando para que o teste interno seja realizado. Existem alguns tipos de testes, como: Short Test é o mais rápido e verifica componentes básicos, Long Test (ou Extended Test) realiza uma varredura completa de leitura em todos os setores acessíveis do disco, verificando integridade da mídia em HDDs ou consistência lógica dos blocos em SSDs.

Também existe o Conveyance Test que detecta danos causados durante o transporte e também o Selective Test que permite avaliar áreas específicas do disco com base em intervalos de blocos, sendo mais comum em HDDs do que em SSDs.

Como mencionado anteriormente, os testes do SMART são iniciados por comandos enviados pelo sistema operacional. Essa solicitação pode ocorrer de maneira automática, usando o smartd, ou de modo manual, por meio do comando smartctl no Linux e/ou Windows. Para consultar as informações geradas pelos testes, podemos usar o próprio smartctl (Linux e Windows) ou o CrystalDiskInfo no Windows.

O uso do SMART é altamente recomendado para quem trabalha com HDDs e SSDs, já que ninguém quer ser surpreendido por uma falha repentina no disco. Ainda assim, ele possui limitações, pois cada fabricante decide quais testes implementar e de que forma executá-los. Por isso, muitos atributos são proprietários e até pouco documentados.

SMARTD

O smartd é o daemon responsável por monitorar continuamente o estado dos dispositivos de armazenamento que oferecem suporte ao SMART, enquanto que o SMART, fica internamente no firmware do próprio dispositivo de armazenamento. O smartd consulta as informações do SMART, registra eventos e emite alertas quando detecta sinais de desgaste ou falha.

O comportamento do daemon é controlado pelo arquivo /etc/smartd.conf. É nesse arquivo que definimos quais dispositivos serão monitorados, quais atributos devem acionar alertas, com que frequência os testes internos do SMART devem ser solicitados e como as notificações serão enviadas.

O intervalo padrão de verificação do smartd é de 30 minutos, esse valor pode ser ajustado por meio da opção --interval=N passada ao daemon durante sua inicialização, onde N representa o tempo em segundos.

O método mais comum de fazer isso em sistemas baseados em Debian é editar o arquivo /etc/default/smartmontools, utilizando a variável smartd_opts, como no exemplo abaixo:

smartd_opts="--interval=1800"

Depois disso, basta reiniciar o serviço:

sudo systemctl restart smartd

No arquivo smartd.conf, a opção -s (ou -s STATE) é utilizada para agendar testes automáticos nos dispositivos monitorados e deve ser acompanhada de parâmetros que definem tanto o tipo de teste, como S, L, C ou X, quanto o intervalo ou o horário em que ele será executado.

A forma geral dessa sintaxe é algo como /dev/sdX -s T/MM/DD/d/HH, em que T representa o tipo de teste e os demais campos indicam a periodicidade com base em mês, dia, dia da semana e hora.

Na prática, é comum encontrar configurações mais simples, por exemplo /dev/sdX -s S/../../1/03, onde são usados curingas para mês e dia do mês, enquanto se fixa apenas o dia da semana e o horário.

Os tipos de teste são indicados por letras, como S para short test, L para long (extended) test, C para conveyance test e X para selective test.

Depois do tipo de teste, aparecem os campos de data e hora, que podem ser preenchidos com valores numéricos ou com curingas como o ponto (.).

O campo MM representa o mês, de 1 até 12, ou pode ser substituído por um curinga.

O campo DD indica o dia do mês, de 1 até 31, também podendo usar curinga.

O campo d corresponde ao dia da semana, em que 1 é segunda-feira e 7 é domingo, e o campo HH define a hora do dia no formato de 0 a 23.

Um exemplo concreto de configuração é /dev/sda -a -s L/../../7/03 -m admin@example.com.

No exemplo acima, o smartd monitora o dispositivo /dev/sda, agenda a execução de um long test todos os domingos (representados pelo valor 7 no campo de dia da semana), sempre às 3 horas da manhã. Ele também envia notificações para o endereço de email admin@example.com caso sejam detectados problemas ou eventos relevantes.

Embora o smartd permaneça em execução contínua, ele não verifica os discos em tempo real, mas sim em intervalos periódicos, como mostrado anteriormente. Também é importante observar que um alerta não é enviado simplesmente porque um teste foi iniciado. A opção -s define o período em que determinado teste deve ser executado, mas sua execução ocorre de fato durante um dos ciclos periódicos de verificação do smartd. Portanto, o teste não é necessariamente iniciado exatamente no começo da hora programada e nenhum teste agendado será iniciado enquanto o daemon não estiver em execução.

O agendamento realizado por -s possui um prazo que fica dentro de uma janela de uma hora. Por exemplo, ao utilizar -s S/../.././02, estamos solicitando que um Short Test seja iniciado entre 02h00 e 02h59. O teste será iniciado no ciclo de verificação do smartd que ocorrer dentro desse período.

Imagine que estamos definindo --interval=3600 (igual a 1 hora). Agora se as verificações começaram às 00h20, os próximos ciclos ocorrerão aproximadamente às 01h20, 02h20, 03h20 e assim por diante. Portanto, um teste configurado com -s S/../.././02 será iniciado por volta das 02h20, pois esse é o ciclo de verificação que ocorre dentro da janela das 02h.

Outro detalhe importante é que o smartd não tenta interpretar o significado dos atributos que ele coleta, já que cada fabricante define seus próprios limites, ele apenas compara os valores normalizados com os limites críticos definidos pelo próprio firmware do dispositivo.

A partir dessa comparação, ele determina se deve notificar ou não. Esse mecanismo reduz a chance de falsos positivos, já que é o próprio disco que estabelece o que considera um comportamento aceitável.

Configurando o smartd

A configuração padrão do smartd em sistemas como o Ubuntu 24.04 é bastante minimalista, voltada a evitar consumo desnecessário de energia e alertas excessivos em dispositivos removíveis. Após a instalação do pacote smartmontools, o conteúdo inicial do arquivo /etc/smartd.conf geralmente é o seguinte:

DEVICESCAN -d removable -n standby -m root -M exec /usr/share/smartmontools/smartd-runner

O parâmetro DEVICESCAN faz com que o smartd procure automaticamente todos os discos conectados.

O argumento -d removable informa ao smartd que o dispositivo pode ser removível, como pendrives ou HDs externos. Isso permite que o daemon continue em execução mesmo que o dispositivo não esteja presente no momento da inicialização, e evita o envio de alertas caso o dispositivo seja desconectado depois.

Já o parâmetro -n standby indica que o smartd não deve acordar discos que estejam em modo standby ou sleep, o que evita consumo desnecessário de bateria em laptops, reduz o desgaste mecânico em HDDs e aumenta a vida útil do dispositivo, dessa forma, apenas discos ativos são verificados.

Por fim, o parâmetro -m root define o destinatário dos alertas, que nesse caso serão enviados para o usuário root via email.

O parâmetro -M exec /usr/share/smartmontools/smartd-runner é um dos mais importantes da configuração, ele define as diretivas de notificação, que determinam quando e com que frequência os alertas serão enviados, além de permitir a personalização do método de notificação.

Atualmente, existem seis diretivas válidas: always, once, daily, diminishing, test e exec.

A diretiva once envia apenas um email para cada tipo de problema detectado. Se o erro persistir, nenhum novo alerta será enviado, e esse é o comportamento padrão, a menos que a opção -s seja usada.

Já a diretiva always envia um email sempre que a verificação encontra um problema (é uma opção nova). Mas cuidado, se o smartd verifica o disco a cada 30 minutos, você receberá um email a cada 30 minutos até que o problema seja resolvido.

A diretiva daily envia o primeiro alerta normalmente, caso o problema permaneça, envia apenas um aviso por dia. Esse é o comportamento padrão quando a opção -s está ativa.

A diretiva diminishing reduz a frequência dos alertas ao longo do tempo. Ela envia a primeira notificação assim que o problema aparece, depois repete um dia depois, depois dois dias, depois quatro, depois oito e assim sucessivamente, até chegar a um intervalo de 32 dias, momento em que ela para de notificar.

A diretiva test serve apenas para enviar um email de teste quando o smartd é iniciado. Ela existe para confirmar que o sistema de notificação está funcionando corretamente.

A diretiva exec permite usar um script externo para realizar as notificações no lugar do mecanismo interno de envio de emails. Vale notar que o script padrão /usr/share/smartmontools/smartd-runner já é bastante completo e normalmente não precisa ser substituído, embora você possa definir outro se necessário.

Esse script padrão utiliza os arquivos presentes no diretório /etc/smartmontools/run.d/, cada arquivo nesse diretório deve ser um script executável e o nome do arquivo deve começar com um número para definir a ordem de execução, como 00-email, 10-telegram e assim por diante.

Quando ocorre um alerta SMART, o smartd-runner executa todos os scripts desse diretório, enviando a mensagem do erro como entrada para cada um.

Eu criei um script para enviar notificações pelo Telegram. O conteúdo do arquivo /etc/smartmontools/run.d/1telegram ficou assim:

#!/bin/bash

msg="${SMARTD_FULLMESSAGE}"

TOKEN="1128941882:AbEk1vu-3c884865cddba6e8dfb4cd6d1a8"
CHAT_ID="-1021433275329"
message_thread_id="2051"

# URL da API do Telegram
URL="https://api.telegram.org/bot$TOKEN/sendMessage"

curl -X POST "https://api.telegram.org/bot$TOKEN/sendMessage" \
             -d "chat_id=$CHAT_ID" \
             -d "message_thread_id=$message_thread_id" \
             -d "text=$(echo -e "${msg}")" \
             -d disable_notification="true" >/dev/null 2>&1

exit 0

Para testar, basta configurar o DEVICESCAN no arquivo /etc/smartd.conf exatamente como mostrado abaixo:

cat /etc/smartd.conf
DEVICESCAN -d removable -n standby -m root \
    -M test \
    -M exec /usr/share/smartmontools/smartd-runner

Depois disso, basta reiniciar o serviço:

sudo systemctl restart smartd

Não se esqueça de remover o -M test ao colocar o sistema em produção. Um comando bem útil é o smartd -q onecheck, esse comando força o smartd a executar imediatamente uma verificação de todas as entradas definidas no smartd.conf, simulando uma checagem normal, porém sem aguardar o próximo ciclo. É especialmente útil para validar rapidamente se a configuração está correta e se algum alerta seria disparado.

Sempre faça testes nos discos

É importante deixar claro que o smartd realiza verificações automáticas a cada 30 minutos por padrão, mas ele não executa testes por conta própria.

Por isso, é recomendado configurar os testes periódicos nos discos. Para unidades críticas, como servidores ou dispositivos NAS que armazenam dados importantes, uma boa prática é realizar um teste Short semanalmente e um teste Long mensalmente. O Long pode ser agendado para finais de semana ou em horários de baixa carga.

Se você quiser que o smartd execute testes automáticos, por exemplo, todo domingo às 03h da manhã, pode usar algo assim:

cat /etc/smartd.conf
/dev/sda -a -s (S/../../7/03) -m seuemail@dominio.com

Caso prefira usar o DEVICESCAN:

DEVICESCAN -n standby \
   -m root \
   -M exec /usr/share/smartmontools/smartd-runner \
   -s (S/../.././07)

Ou, se preferir, agendar diretamente via smartctl no crontab (o meu método preferido):

0 3 * * * /usr/sbin/smartctl -t short /dev/sda

SMARTCTL

O smartctl é uma ferramenta que está disponível no pacote smartmontools. Ele é usado para consultar informações detalhadas do disco, executar testes internos e até definir algumas configurações do disco.

Na maior parte do tempo, o smartctl é utilizado para verificar sinais de degradação ou falha iminente em um disco de forma manual

Quando você executa o smartctl, ele envia comandos específicos ao disco para consultar os dados SMART. A quantidade e o tipo de informações acessíveis dependem dos atributos que o firmware do disco suporta e expõe, algo que é definido pelo fabricante.

Para solicitar um teste longo em disco, podemos usar o comando abaixo:

sudo smartctl -t long /dev/sda

Para ver todas as informações disponíveis, inclusive ver se o teste já finalizou, podemos usar o comando abaixo:

sudo smartctl -a /dev/sda

Também podemos usar o comando abaixo para exibir apenas o resultado dos testes realizados:

sudo smartctl -l selftest /dev/sda

Informações do disco

Ao consultar os dados SMART de um dispositivo, é comum encontrar campos adicionais relacionados à estrutura interna do próprio sistema de monitoramento. Esses campos não representam atributos de saúde diretamente, mas oferecem informações úteis para entender como o SMART daquele modelo opera e quais informações podem ser consideradas confiáveis.

A seção chamada Vendor Specific SMART Attributes with Thresholds, apresentada pelo smartctl, reúne os principais atributos que o firmware do dispositivo acompanha. Ela inclui métricas como erros de leitura, setores realocados, tempo total de operação e desgaste de células NAND no caso dos SSDs, além de outros indicadores considerados relevantes para avaliar o estado do hardware.

Cada atributo pode ter um threshold, que é um valor limite definido pelo fabricante para indicar falha iminente. Quando o valor normalizado de um atributo cai abaixo desse limite, o disco é considerado em risco. Como esses atributos são específicos de cada fabricante (vendor specific), não existe padronização nas métricas, escalas ou interpretações, o que exige análise cuidadosa.

Um exemplo da lista Vendor Specific SMART Attributes with Thresholds pode ser visto abaixo:

Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   200   200   051    Pre-fail  Always       -       0
  3 Spin_Up_Time            0x0027   205   203   021    Pre-fail  Always       -       2733
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       875
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x002e   200   200   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   093   093   000    Old_age   Always       -       5797
 10 Spin_Retry_Count        0x0032   100   100   000    Old_age   Always       -       0
 11 Calibration_Retry_Count 0x0032   100   100   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       597
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       111
193 Load_Cycle_Count        0x0032   200   200   000    Old_age   Always       -       833
194 Temperature_Celsius     0x0022   119   102   000    Old_age   Always       -       28
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   100   253   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0008   200   200   000    Old_age   Offline      -       0

Campo ID

O campo ID# é apenas o identificador interno do atributo. Cada fabricante segue sua própria classificação quando vão criar os identificadores. No entanto, existe um conjunto de identificadores amplamente utilizado pelos fabricantes, cujo significado se mantém consistente entre diferentes modelos e marcas.

Esses identificadores são:

• Read_Error_Rate (ID 1)
• Reallocated_Sector_Count (ID 5)
• Spin_Retry_Count (ID 10)
• Reallocated_Event_Count (ID 196)
• Current_Pending_Sector (ID 197)
• Offline_Uncorrectable (ID 198)

Campo ATTRIBUTE_NAME

Em seguida temos o ATTRIBUTE_NAME, que exibe o nome descritivo associado a cada identificador, ele serve para indicar o que está sendo monitorado. Esses nomes não são definidos pelo firmware do disco, eles são atribuídos pelo smartctl com base em uma base de dados mantida pela comunidade.

Embora não sejam oficialmente padronizados, são amplamente reconhecidos e ajudam na interpretação dos atributos, especialmente ao indicar quais informações são mais relevantes para a análise da integridade do dispositivo.

Campo FLAG

O campo FLAG é um valor hexadecimal que representa um conjunto de bits de controle definidos pelo firmware do disco. Ele indica o comportamento de cada atributo SMART.

Esses bits indicam se o atributo está ligado a sinais de falha iminente ou ao desgaste natural do dispositivo e se ele é atualizado de forma contínua durante o uso normal ou apenas durante testes executados em background.

Esse campo é útil para sistemas de monitoramento automatizado, que usam essas informações para entender melhor o significado de cada atributo e a forma como ele é atualizado durante o uso do disco.

Campo VALUE, WORST e THRESH

Os campos VALUE, WORST e THRESH descrevem a condição de cada atributo. O VALUE indica o valor atual normalizado de acordo com a escala definida pelo fabricante, em que valores mais altos representam melhor estado.

O WORST registra o menor valor já alcançado pelo atributo desde o início do monitoramento, ou seja, o ponto em que ele esteve mais próximo de indicar falha.

O THRESH é o limite mínimo aceitável nessa escala, quando o VALUE fica abaixo desse ponto, o atributo passa a ser interpretado como estando em situação de falha iminente.

É importante lembrar que esses números não representam valores absolutos, e sim escalas internas normalizadas definidas pelos fabricantes. Por isso, um VALUE de 200 ou 100 pode representar situações completamente diferentes em dispositivos de fabricantes diferentes.

Em condições normais, VALUE tende a ser igual ou superior a WORST, o que indica que o atributo permaneceu estável ao longo do tempo. No entanto, isso nem sempre ocorre, já que cada fabricante define suas próprias regras para normalização e atualização desses valores.

Por esse motivo, embora o WORST seja útil como referência histórica, o RAW_VALUE e a evolução dos dados ao longo do tempo costumam ser mais confiáveis para avaliar a saúde do disco.

Campo TYPE

O campo TYPE indica a categoria do atributo, quando ele é marcado como Pre-fail, significa que caso o valor normalizado (VALUE) caia abaixo do limite estabelecido (THRESH), existe risco de falha iminente no dispositivo.

Já atributos classificados como Old_age indicam desgaste natural decorrente do tempo de uso. Atingir o limite nesse caso não indica falha imediata, mas mostra que o disco chegou ao ponto esperado de envelhecimento.

Campo UPDATED

O campo UPDATED informa quando o atributo é atualizado, se estiver como Always, significa que o valor é ajustado continuamente durante o uso normal do disco.

Quando mostrar Offline, significa que a atualização ocorre apenas durante testes internos SMART, como os testes curto, estendido ou seletivo.

Essa diferença é relevante porque atributos do tipo Offline não acompanham mudanças em tempo real e permanecem estáveis enquanto o disco está em operação comum, algo que precisa ser considerado ao interpretar seus valores.

Campo WHEN_FAILED

O campo WHEN_FAILED indica se algum atributo já teve seu valor normalizado (VALUE) abaixo do limite crítico definido em THRESH, sinalizando falha iminente do disco.

Valores como FAILING_NOW ou PAST indicam que o disco já atingiu estado crítico. No nosso exemplo, todos aparecem com -, o que é positivo, pois não existe histórico de falha.

Campo RAW_VALUE

Por fim, o campo RAW_VALUE representa o valor bruto do atributo, antes de qualquer processamento. Ele corresponde ao número real coletado pela controladora, embora seja o campo mais confiável, também é o mais difícil de interpretar, já que cada fabricante utiliza formatos próprios.

Em alguns casos, o valor é literal, como horas de operação, mas na maior parte das vezes ele expressa taxas, contagens codificadas ou dados acumulados que não seguem um padrão fixo.

Principais atributos

Ao analisar a tabela de atributos SMART, alguns indicadores merecem atenção especial, já que eles estão diretamente ligados à saúde física do dispositivo e costumam ser os primeiros a apontar sinais de falha iminente.

Para essa análise, vou usar um SSD de 1TB comprado usado:

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
  9 Power_On_Hours          0x0032   098   098   000    Old_age   Always       -       9698
 12 Power_Cycle_Count       0x0032   099   099   000    Old_age   Always       -       805
177 Wear_Leveling_Count     0x0013   099   099   000    Pre-fail  Always       -       12
179 Used_Rsvd_Blk_Cnt_Tot   0x0013   100   100   010    Pre-fail  Always       -       0
181 Program_Fail_Cnt_Total  0x0032   100   100   010    Old_age   Always       -       0
182 Erase_Fail_Count_Total  0x0032   100   100   010    Old_age   Always       -       0
183 Runtime_Bad_Block       0x0013   100   100   010    Pre-fail  Always       -       0
187 Uncorrectable_Error_Cnt 0x0032   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0032   069   052   000    Old_age   Always       -       31
195 ECC_Error_Rate          0x001a   200   200   000    Old_age   Always       -       0
199 CRC_Error_Count         0x003e   100   100   000    Old_age   Always       -       0
235 POR_Recovery_Count      0x0012   099   099   000    Old_age   Always       -       198
241 Total_LBAs_Written      0x0032   099   099   000    Old_age   Always       -       26404943808

Vale reforçar que por se tratar de um SSD, muitos atributos que só estão presentes em HDD não estão presentes aqui.

Read_Error_Rate (ID 1)

Esse atributo indica a taxa de erros de leitura detectados pelo hardware ao acessar dados na superfície do disco. Em teoria, valores brutos (raw_value) diferentes de zero podem indicar problemas em componentes como cabeçotes de leitura, superfícies magnéticas ou no circuito de leitura.

No entanto, é importante destacar que em muitos modelos, o valor bruto desse atributo não representa diretamente erros reais, mas sim uma métrica codificada usada internamente pelo firmware. Por isso, o mais relevante nesse caso é observar a variação do valor normalizado (VALUE) ao longo do tempo e monitorar se ele está se aproximando do limiar de falha (THRESH), além de correlacionar com outros atributos como Current_Pending_Sector (ID 197) e Offline_Uncorrectable (ID 198) para uma análise confiável.

Reallocated_Sector_Count (ID 5)

Esse atributo é um dos mais importantes da tabela SMART, ele registra a quantidade de setores defeituosos que foram realocados para a área de reserva do disco.

Sempre que a controladora encontra um setor ilegível, ela tenta mover os dados para uma região saudável, então um valor bruto acima de zero já indica início de deterioração e tende a crescer ao longo do tempo.

Quanto maior o número de setores realocados, maior a probabilidade de falha total nos meses seguintes. Além disso, quantidades elevadas de remapeamentos podem causar queda perceptível no desempenho do disco.

Spin_Up_Time (ID 3)

Esse indica o tempo que o disco rígido leva para sair do estado de repouso e alcançar sua velocidade nominal.

Vale reforçar que o RAW_VALUE normalmente é codificado de forma proprietária e não represente diretamente esse tempo. Por isso, o mais confiável é acompanhar o valor normalizado (VALUE).

Se esse valor começar a diminuir com o tempo, isso pode indicar desgaste nos componentes mecânicos, atrito excessivo, vibrações anormais ou falhas no circuito de alimentação do motor.

Em situações mais graves, o disco pode levar tanto tempo para atingir a rotação necessária que falha ao inicializar, muitas vezes acompanhado de alertas em outros atributos, como o Spin_Retry_Count (ID 10).

Spin_Retry_Count (ID 10)

Indica quantas vezes o disco tentou atingir sua velocidade nominal de rotação após uma tentativa malsucedida.

Quando o disco não consegue estabilizar a rotação na primeira tentativa, isso costuma apontar desgaste ou falha no conjunto mecânico, como motor, eixo ou rolamentos.

Se esse valor começar a aumentar, é um sinal claro de que o dispositivo está passando por degradação física significativa.

End-to-End_Error (ID 184)

Esse atributo está presente em discos com sistemas avançados de verificação interna, como o SMART IV da Hewlett-Packard. Ele registra falhas que ocorrem no caminho dos dados dentro do próprio disco, desde a controladora até a mídia, incluindo até a RAM interna.

Qualquer aumento nesse valor indica que os dados foram corrompidos antes de serem gravados corretamente, o que pode apontar problemas na controladora, na memória cache ou em outros circuitos internos.

Reported_Uncorrect (ID 187)

Esse atributo registra erros que não puderam ser corrigidos pelos mecanismos de ECC do hardware. A presença de erros não recuperáveis é um forte indicador de falhas mecânicas ou deterioração da superfície do disco.

Embora não seja marcado como crítico por muitos fabricantes, a evolução desse atributo pode sinalizar problemas sérios.

Command_Timeout (ID 188)

Esse atributo registra operações que foram interrompidas porque o disco não conseguiu respondê-las dentro do tempo limite.

O valor bruto ideal é zero, quando esse número começa a subir, isso normalmente indica problemas na alimentação elétrica, cabos SATA com defeito ou oxidação, falhas na controladora interna do disco ou outros erros relacionados à comunicação.

Se esse valor aumentar, é recomendável fazer backup imediato e iniciar o planejamento de substituição do hardware.

Reallocation_Event_Count (ID 196)

Esse atributo registra o número total de tentativas de realocação, incluindo tanto as bem-sucedidas quanto as que falharam.

Diferente do ID 5, que indica quantos setores foram efetivamente realocados, esse atributo mostra quantas vezes o disco tentou realizar o processo de realocação.

Ele é um contator cumulativo, ou seja, o valor desse atributo nunca diminui e a evolução constante desse valor é um forte indicativo de deterioração acelerada.

Current_Pending_Sector_Count (ID 197)

Esse indica a quantidade de setores instáveis, esses setores estão aguardando remapeamento porque apresentaram erros de leitura irrecuperáveis.

Se, em uma leitura futura, o setor puder ser lido corretamente e os dados forem considerados íntegros, ele é removido da lista de pendentes.

Caso a leitura falhe novamente, o disco tenta mover os dados para uma área saudável e o setor é marcado como realocado. Esse atributo é extremamente sensível e costuma aparecer cedo quando a superfície do disco começa a apresentar falhas.

Mesmo um único setor pendente já merece atenção.

Uncorrectable Sector Count (ID 198)

Representa a quantidade de setores que não puderam ser recuperados, mesmo após todas as tentativas de correção.

Um aumento nesse valor indica defeitos graves na superfície do disco ou falhas mecânicas no conjunto de leitura.

Se esse número começar a subir, o ideal é substituir o disco o quanto antes.

Soft Read Error Rate (ID 201)

Esse atributo indica a quantidade de erros de leitura detectados em nível de software. Valores baixos são comuns, mas aumentos progressivos podem sinalizar deterioração física ou interferências que afetam outros atributos, especialmente os relacionados à leitura instável.

É recomendável monitorá-lo em conjunto com os IDs 1, 5, 197 e 198.

Power_On_Hours (ID 9)

Esse atributo não indica criticidade, mas registra quantas horas o disco permaneceu ligado desde que saiu de fábrica.

Ele serve como referência para estimar a vida útil da unidade, que geralmente é de cerca de 5 anos, ou aproximadamente 43.800 horas de operação contínua. É um dos poucos atributos que refletem valores reais diretamente.

Wear_Leveling_Count (ID 177)

Esse é um dos atributos mais importantes ao analisar um SSD, já que ele está relacionado ao desgaste das células de memória NAND.

A memória flash possui uma quantidade limitada de ciclos de programação e apagamento (Program/Erase Cycles). Para evitar que determinadas células sejam utilizadas muito mais do que outras, a controladora distribui as gravações entre os blocos, processo conhecido como wear leveling (esse atributo pode ser beneficiado pelo recurso Write Caching que falaremos mais adiante).

A interpretação exata desse atributo varia de acordo com o fabricante. Em SSDs Samsung que utilizam essa implementação, o RAW_VALUE representa a média de ciclos de apagamento dos blocos, enquanto o valor normalizado tende a diminuir conforme a unidade se desgasta.

Portanto, não se deve assumir que um RAW_VALUE diferente de zero represente um problema, o mais importante é entender a implementação utilizada pelo fabricante e acompanhar sua evolução ao longo do tempo.

Used_Rsvd_Blk_Cnt_Tot (ID 179)

Esse atributo representa a quantidade de blocos da área de reserva que precisaram ser utilizados para substituir blocos que apresentaram falhas de leitura, gravação ou apagamento.

Os SSDs possuem uma quantidade de memória reservada justamente para substituir blocos NAND que deixam de ser confiáveis durante sua vida útil.

Um valor crescente nesse atributo indica que o dispositivo está consumindo sua reserva de blocos e deve ser analisado em conjunto com atributos como Reallocated_Sector_Ct (ID 5), Program_Fail_Cnt_Total (ID 181) e Erase_Fail_Count_Total (ID 182).

Program_Fail_Cnt_Total (ID 181)

Registra a quantidade total de operações de programação da memória NAND que falharam.

Uma operação de programação corresponde, de forma simplificada, à gravação de dados nas células de memória.

O valor ideal é zero, caso ele comece a aumentar, pode indicar deterioração das células NAND ou outros problemas internos no SSD.

Erase_Fail_Count_Total (ID 182)

Registra a quantidade de operações de apagamento de blocos NAND que falharam.

Como a memória flash precisa apagar um bloco antes de reutilizá-lo para novas gravações, falhas nesse processo podem indicar desgaste ou defeitos nas células NAND.

O valor ideal também é zero e qualquer crescimento deve ser acompanhado.

Runtime_Bad_Block (ID 183)

Indica blocos que se tornaram defeituosos durante o funcionamento do SSD.

Na implementação documentada pela Samsung, esse atributo funciona como um indicador agregado das falhas de leitura, programação e apagamento detectadas pela controladora.

Um valor crescente pode indicar deterioração da memória NAND e deve ser correlacionado com os IDs 5, 179, 181, 182 e 187.

Uncorrectable_Error_Cnt (ID 187)

Registra erros que não puderam ser recuperados pelos mecanismos de correção de erros, como o ECC.

Erros desse tipo são mais preocupantes do que erros corrigidos automaticamente pela controladora, pois significam que os mecanismos internos não conseguiram reconstruir corretamente os dados.

O ideal é que permaneça em zero.

ECC_Error_Rate (ID 195)

Esse atributo está relacionado aos erros detectados e corrigidos pelo mecanismo de ECC da unidade.

A existência de correções ECC não significa necessariamente que o SSD esteja falhando, já que a correção de erros faz parte do funcionamento normal da memória NAND.

A interpretação do valor bruto varia bastante entre fabricantes e modelos, portanto ele deve ser analisado principalmente em conjunto com atributos como Uncorrectable_Error_Cnt (ID 187), Runtime_Bad_Block (ID 183) e os indicadores de desgaste.

Total_LBAs_Written (ID 241)

Esse é um dos atributos mais importantes ao avaliar um SSD usado, pois permite estimar a quantidade total de dados gravados na unidade.

O valor bruto representa a quantidade de LBAs gravados e cada LBA corresponde a 512 bytes (mas você deve usar a unidade usada pelo fabricante com base no seu SSD). Usando meu SSD Samsung como base, temos: Total gravado = RAW_VALUE × 512 bytes.

Fazendo a conta, temos 26404943808*512 é igual a 13519331229696. Como GB em bytes corresponde a 1.000.000.000 de bytes e TB corresponde a 1.000.000.000.000 de bytes, podemos converter:

# Para GB:
13519331229696/1000000000 = 13.519 GB

# Para TB:
13519331229696/1000000000000 = 13 TB

Fazendo uma conta aproximada, temos cerca de 13 TB escritos nesse SSD ao longo da vida dele. Esse valor pode então ser comparado com o TBW especificado pelo fabricante para aquele modelo.

O meu SSD é um Samsung 850 EVO de 1TB, ele tem endurance oficial de 150 TBW. A Samsung especifica que para os modelos 500 GB e 1 TB da série 850 EVO uma garantia de 5 anos ou 150 TBW, o que ocorrer primeiro.

O TBW significa Terabytes Written, ou seja, a quantidade total de dados que o fabricante garante que pode ser gravada no SSD dentro da especificação de endurance.

Ele não significa que o SSD necessariamente morrerá ao atingir 150 TB, mas indica que a partir disso, ele pode vir apresentar algum defeito. Então, esse valor é principalmente uma referência de desgaste/endurance e também um limite utilizado na garantia.

Eu uso muito o valor de dados que já foram gravados vs o TBW para saber se vou comprar ou não o SSD, além de analisar outros atributos.

Como o SSD já gravou cerca de 13,52 TB. Podemos calcular quantos TBW já foram utilizados:

(13,519 ÷ 150) = 0.090126667

0.090126667*100 = 9,01%

Esse SSD consumiu cerca de 9% do TBW.

POR_Recovery_Count (ID 235)

Nos SSDs Samsung, esse atributo registra quantas vezes ocorreu um desligamento inesperado que exigiu que o firmware recuperasse informações internas na próxima inicialização.

Um valor elevado não significa automaticamente que o SSD esteja defeituoso, mas pode revelar que ele sofreu muitos desligamentos abruptos ou perdas de alimentação.

CRC_Error_Count (ID 199)

Esse atributo registra erros de CRC ocorridos na comunicação entre o SSD e o computador.

Diferentemente dos atributos relacionados à NAND, um aumento nesse contador geralmente aponta para problemas externos ao SSD, como cabo SATA, conector, backplane ou sinalização da interface.

Por isso, se ele começar a subir, eu não condenaria imediatamente o SSD. Primeiro verificaria cabo e conexão.

Airflow_Temperature_Cel (ID 190)

Registra a temperatura medida internamente pela unidade.

Temperaturas elevadas de forma contínua podem reduzir a vida útil da memória NAND e da controladora, além de provocar redução de desempenho em alguns modelos.

O RAW_VALUE corresponde ao valor real, então um valor RAW_VALUE=31, indica que a temperatura atual é de aproximadamente 31 °C na região ao redor dos chips NAND.

Nos SSDs Samsung, o valor normalizado costuma seguir esta conta:

VALUE ≈ 100 - RAW_VALUE

Portanto, vamos calcular baseado no VALUE:

100 - 31 = 69

VALUE = 069

Exatamente como vemos no reporte:

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
190 Airflow_Temperature_Cel 0x0032   069   052   000    Old_age   Always       -       31

O WORST representa o pior valor normalizado já registrado, para saber qual a temperatura ele chegou, fazemos assim:

100 - 52 = 48 °C

Recursos disponíveis em Dispositivos de Armazenamento

Vamos ver agora alguns recursos disponíveis em HDDs e SSDs que ajudam a melhorar o desempenho e até a vida útil, dependendo do dispositivo.

Ajustar os parâmetros abaixo parâmetro pode evitar degradações desnecessárias e aumentar a resiliência diante de setores problemáticos.

Quando o write cache e o SCTERC estão configurados corretamente, o comportamento do disco melhora de forma significativa em operações intensas.

Um exemplo prático é quando você vê o tempo estimado de conclusão de atividades despencar de mais de 1 dia para algo em torno de 7 horas.

Isso acontece porque o write cache permite que o disco receba várias operações pequenas e agrupe tudo em um único ciclo de gravação.

Em tarefas como resilver, scrub, cópias extensas ou reconstruções de RAID, isso reduz a quantidade de eventos físicos de escrita, levando a um ganho imediato na taxa de transferência. Com isso, o tempo estimado cai drasticamente.

Já o SCTERC impede que o disco fique preso tentando recuperar setores por muito tempo. Sem esse limite, um único setor ruim pode travar a operação por 30 até 60 segundos, repetidas vezes, e o controlador pode até considerar o disco inativo, derrubando a performance geral do pool.

Com o SCTERC ajustado, o disco desiste rápido, devolve erro e deixa o sistema reconstruir o bloco a partir dos outros discos. Isso mantém a operação fluindo e evita quedas bruscas de desempenho.

Quando esses dois recursos trabalham juntos, o resultado é uma melhora na performance, já que os gargalos internos do disco foram eliminados ou reduzidos. Embora o write cache e o SCTERC ofereçam ganhos reais de desempenho, é importante considerar algumas ressalvas antes de ativar ou ajustar esses recursos.

A primeira delas é que o write cache mantém os dados temporariamente na memória volátil do disco. Em caso de queda de energia, qualquer informação que ainda não tenha sido escrita de forma permanente pode ser perdida.

Em servidores críticos, é indispensável contar com proteção contra falha elétrica, como um nobreak ou uma controladora com bateria (BBU). Em desktops ou ambientes sem esse tipo de proteção, ativar o write cache representa um risco de perda de dados.

Outra ressalva é que nem todos os discos implementam o SCTERC de maneira confiável. Alguns modelos simplesmente ignoram a configuração, outros até a aceitam, mas não aplicam o ajuste de forma consistente, e discos SMR normalmente nem disponibilizam esse parâmetro.

Write Caching

O cache de gravação (ou write cache) é um recurso disponível na maioria dos discos rígidos que permite coletar todos os dados na memória de cache HD, antes de serem gravados permanentemente no disco.

Depois que os dados são coletados, ele são transferidos e armazenados (escritos no disco) num único evento, é como agrupar todos os dados que precisam ser escrito no disco num grande pacote e escrever todo esse pacote lá ao invés de realizar diversos eventos de escrita (esse recurso reduz o número de operações físicas de escrita).

Por padrão esse recurso já vem habilitado, essa função é de extrema importância para os SSDs pois eles possuem um número de clicos de escrita e remoção dos dados.

Ativar esse recurso prolonga a vida útil do dispositivo como SSDs que utilizam memória flash, já que esses dispositivos possuem um número finito de ciclos de escrita/apagamento por célula.

Otimizar o uso dessas células com mecanismos como o write cache (e também wear leveling, TRIM, etc.) é essencial para garantir maior durabilidade.

Vale observar que existe riscos em manter o write cache ativado sem mecanismos adequados de proteção contra perda de energia. Se o sistema desligar de forma abrupta (queda de energia, por exemplo), os dados ainda não gravados no disco (mas que estavam na cache) podem ser perdidos.

Por isso, em servidores críticos, é comum combinar write cache com baterias de proteção (BBU) ou usar sistemas de arquivos com journaling robusto e sincronização forçada (fsync).

# Verificar se o write cache está ativado:
sudo hdparm -W /dev/sdX

Se estiver ativado, a saída será algo como:

write-caching =  1 (on)

Para ativar o write cache, faça:

sudo hdparm -W1 /dev/sdX

Para desativar o write cache, faça:

sudo hdparm -W0 /dev/sdX

Usando o SDPARM:

# Verificar o write cache. '1' = ativado e '0' = desativado:
sudo sdparm -a /dev/sdX | grep WCE

# Ativar:
sudo sdparm --set=WCE /dev/sdX

# Desativar:
sudo sdparm --clear=WCE /dev/sdX

Outra forma de ativar é usando o comando smartctl (disponível no pacote smartmontools):

smartctl -s wcache,on /dev/sda

Para consultar usando smarctl podemos fazer da seguinte forma:

sudo smartctl -g wcache /dev/sda

Write cache is:   Enabled

Para configurar via smartclt, vai depender do firmware e do driver do disco/controladora. O -s (ou --set) serve para modificar parâmetros do dispositivo, e a opção wcache,on tenta ligar o write cache via ATA/SCSI passthrough.

SCSI/SATA Error Recovery Control - SCTERC

O SCTERC é um mecanismo presente em diversos discos rígidos projetados para ambientes de NAS e servidores. Ele define quanto tempo o disco pode gastar tentando recuperar um erro de leitura ou escrita antes de desistir e devolver o erro para o sistema operacional.

Em discos comuns, projetados para uso doméstico, o comportamento padrão é tentar recuperar um setor “problemático” pelo maior tempo possível, às vezes por vários segundos.

Isso é aceitável em computadores pessoais, onde o sistema pode “esperar” essa tentativa prolongada. Mas em sistemas com RAID, isso se torna um problema.

Se o disco demora demais para responder, o sistema operacional ou a própria controladora RAID podem considerar que ele está travado.

Quando o SCTERC está configurado, o disco não fica tentando ler o mesmo setor repetidamente por longos períodos. Se não conseguir ler o setor dentro desse tempo, o disco retorna erro imediatamente para o sistema.

O RAID então usa as demais cópias dos dados para recuperar a informação, mantendo a integridade do array.

Esse comportamento é tão importante que vários fabricantes adotam nomes comerciais diferentes para representar a mesma ideia. Isso acaba dificultando a administração dessas otimizações em dispositivos de armazenamento de modelos diferentes.

Para verificar o valor atual do SCTERC, podemos usar o smartctl:

sudo smartctl -l scterc /dev/sda

Se o disco suportar ajuste, é possível configurar (por exemplo, 7 segundos):

sudo smartctl -l scterc,70,70 /dev/sda

O SCTERC é configurado com dois valores (read-timeout e write-timeout), cada um expressos em décimos de segundo (por exemplo, 70 equivale a 7 segundos).

Alguns discos permitem ajustar esse parâmetro, enquanto outros não, especialmente modelos SMR, que geralmente não disponibilizam essa configuração.

O SCTERC é particularmente importante em servidores, NAS e sistemas ZFS ou RAID, onde respostas rápidas são essenciais para manter a estabilidade do conjunto.