Pergunta 1:
Com relação à opção -b
: isso depende do seu disco. Os discos modernos e grandes têm blocos de 4 KB, caso em que você deve definir -b 4096
. Você pode obter o tamanho do bloco a partir do sistema operacional , e também é normalmente obtida lendo as informações do disco fora da etiqueta, ou pesquisando o número do modelo do disco. Se -b
estiver definido como algo maior que o tamanho do bloco, a integridade dos resultados badblocks
poderá ser comprometida (ou seja, você poderá obter falso-negativos: nenhum bloco defeituoso encontrado quando ainda existir). Se -b
estiver definido como algo menor que o tamanho de bloco da sua unidade, a velocidade da execução de badblocks
poderá ser comprometida. Não tenho certeza, mas pode haver outros problemas com a configuração de -b
para algo menor que seu tamanho de bloco, já que não está verificando a integridade de um bloco inteiro, pode ainda ser possível obter falso-negativos se for definido muito pequeno.
A opção -c
corresponde a quantos blocos devem ser verificados de uma só vez. Lote de leitura / escrita, basicamente. Essa opção não afeta a integridade de seus resultados, mas afeta a velocidade na qual badblocks
é executado. badblocks
irá (opcionalmente) gravar, ler, armazenar em buffer, verificar, repetir para cada N blocos, conforme especificado por -c
. Se -c
for definido como muito baixo, isso fará com que as execuções de badblocks
demorem muito mais do que o normal, pois o enfileiramento e o processamento de uma solicitação de I / O incorrem em sobrecarga eo disco também pode impor sobrecarga adicional por solicitação. Se -c
estiver definido como muito alto, badblocks
poderá ficar sem memória. Se isso acontecer, badblocks
falhará rapidamente depois de iniciado. Considerações adicionais aqui incluem badblocks
runs paralelas: se você estiver executando badblocks
em várias partições no mesmo disco (má ideia) ou em vários discos no mesmo canal de IO, provavelmente você vai querer ajustar -c
para algo sensivelmente alto, dada a memória disponível para badblocks
, para que as execuções paralelas não lutem por largura de banda IO e possam paralelizar de uma maneira sã.
Pergunta 2:
Ao contrário do que outras respostas indicam, o teste -w
do modo de gravação não é mais ou menos confiável do que o teste não destrutivo de leitura-gravação, mas é duas vezes mais rápido, ao custo de ser destrutivo para todos os seus dados. Vou explicar porquê:
No modo não destrutivo, badblocks
faz o seguinte:
- Leia os dados existentes, soma-os (leia novamente, se necessário) e armazene-os na memória.
- Escreva um padrão predeterminado (substituível com a opção
-p
, embora geralmente não seja necessário) para o bloco. - Leia o bloco de volta, verificando se os dados lidos são iguais aos do padrão.
- Grave os dados originais de volta no disco.
- Não tenho certeza sobre isso, mas também provavelmente relê e verifica se os dados originais foram gravados com êxito e ainda as somas de verificação para a mesma coisa.
No modo destrutivo ( -w
), badblocks
apenas executa as etapas 2 e 3 acima. Isso significa que o número de operações de leitura / gravação necessárias para verificar a integridade dos dados é reduzido pela metade. Se um bloco é ruim, os dados estarão errados em qualquer um dos modos. É claro que, se você se preocupa com os dados armazenados em sua unidade, deve usar o modo não destrutivo, pois -w
apagará todos os dados e deixará os padrões badblocks
'gravados no disco.
Ressalva: se um bloco está indo ruim, mas ainda não foi completamente eliminado, alguns pares de verificação de leitura / gravação podem funcionar, e outros não. Nesse caso, o modo não destrutivo pode fornecer uma indicação mais confiável da "instabilidade" de um bloco, já que ele realiza dois conjuntos de verificação de leitura / gravação (talvez - veja o tópico na etapa 4). Mesmo que o modo não destrutivo seja mais confiável dessa forma, é apenas mais confiável por coincidência . A maneira correta de verificar se há blocos que não são totalmente ruins, mas não podem sustentar várias operações de leitura / gravação, é executar badblocks
várias vezes sobre os mesmos dados, usando a opção -p
.
Pergunta 3:
Se a SMART estiver realocando setores, você provavelmente deve considerar a substituição da unidade o mais rápido possível. Drives que perdem alguns setores não sempre continuam a perdê-los, mas a causa geralmente é um drive muito usado que fica magneticamente fraco ou cabeças / motores defeituosos resultando em leituras / gravações imprecisas ou com falha. A decisão final depende de você, é claro: com base no valor dos dados na unidade e na confiabilidade necessária dos sistemas executados, você pode decidir mantê-la ativa. Eu tenho alguns drives com blocos ruins conhecidos que estão girando com avisos SMART há anos no meu servidor de arquivos, mas eles são armazenados em um cronograma tal que eu poderia lidar com uma falha total sem muita dor.