Estou executando badblocks (ou melhor, "e2fsck -c") em uma unidade de 1 TB e se o indicador de progresso for alguma indicação (sem trocadilhos), levará quase uma eternidade para concluir.
No momento, ele diz o 0.01% done, 30:20 elapsedque significaria que a coisa levaria 17 semanas ou mais para ser concluída, o que parece bastante excessivo no meu livro.
É um período normal de tempo para tal verificação ou simplesmente para que minhas suspeitas estejam corretas porque a unidade está falhando, fazendo com que a verificação demore apenas um pouco mais que a eternidade?
Encontrei essa pergunta aqui, mas isso diz respeito à quantidade de passes realizados.
linux
bad-blocks
Steven Don
fonte
fonte
badblocksfazem com que ele execute tarefas diferentes, o que também afetará os tempos de execução, por exemplo, a-wopção.badblocksem execução: somente leitura, gravação não destrutiva ou leitura e gravação destrutiva. Dito isto, 30 minutos para 0,1% parecem longos.Respostas:
Para responder à sua pergunta, o mais próximo que posso oferecer é com um 3TB que testei para isso. Aqui estão os três testes que fiz, alterando apenas os valores dos parâmetros
-ce realizando-os em até 10%, pois demoraram MUITO tempo. Cada um foi feito 3 vezes para obter uma média.Para chegar a 1%: 1 hora
Para chegar a 10%: 8 horas 40 minutos
Para chegar a 1%: 35 minutos
Para chegar a 10%: 4 horas 10 minutos
Para chegar a 1%: 16 minutos
Para chegar a 10%: 2 horas 35 minutos
Então, sim, o
-cparâmetro tem uma influência muito grande no tempo necessário para verificar o inversor. Eu diria que, para um disco rígido de 1 TB, assumindo que ele mantenha o mesmo período de tempo de 3 TB, seria 1/3 do tempo mencionado aqui; portanto, para chegar a 10%-c 65536no HD de 1 TB, seria de cerca de 50 minutos.fonte
Badblocks faz 4 corridas. Em um HD externo de 1 TB, normalmente leva cerca de 70 horas.
fonte
badblocks(apenas) o padrão é quatro execuções com o-wsinalizador de gravação destrutiva.Tente aumentar a quantidade de blocos processados juntos, como em
badblocks -svn -b 512 -c 65536 /dev/sda. Dessa maneira, posso verificar uma unidade de disco rígido de 1 TB em 8 horas.fonte
Estou executando badblocks em unidades WD Red de 4 TB. Como são unidades de setor de 4k (verificadas usando
lsblk -o NAME,PHY-SeC), estou executando com ele-b 4096. Eu queria dar a cada uma das instâncias de badblocks ~ 800Mb de RAM, então usei o-c 200000que oferece4096 bytes * 200,000 blocks = 800,000 Kb. Eles começaram com cerca de 800 Mb cada, mas isso aumentou com o tempo. Essas configurações fornecem uma aceleração significativa em relação às configurações padrão.Ele rodou 1% em 3min 56seg, mas isso é 1% de 4 padrões. Também parece levar mais tempo quanto mais perto você chegar do final de uma corrida. Ele verificou o disco com o primeiro padrão em cerca de 17 horas, para completar 4 TB em cerca de 68 horas .
COMANDO ABAIXO EXECUTA UMA ESCRITA DESTRUTIVA
O comando que estou usando é:
badblocks -svw -b 4096 -c 200000 /dev/sdc -o bb_sdc.txtfonte
Corri isso anteontem em uma unidade com falha de 1 TB no meu RAID 6 de 6 TB (MODO DE GRAVAÇÃO DESTRUTIVA!):
A placa principal é um rack ASRock C2550D4I (eu sei…) com 8x Samsung SpinPoint M8 HN-M101MBB (eu sei…) conectado às portas SATA3. As unidades são unidades 4K "Advanced Format", daí o tamanho do bloco 4K.
badblocksdemorou cerca de 28 horas para terminar, sem erros.As unidades únicas têm ~ 105 MB / s (tempo médio de
hdparm -tTleitura em buffer), 200–230 MB / s ao testar toda a matriz. Nada de superior hoje em dia, mas bom para uma pilha de drives antigos de laptop.Espero que isso ajude tanto quanto esse segmento me ajudou a encontrar uma maneira rápida de executar badblocks no disco. Sei que seu uso é duvidoso hoje em dia, mas quando uma
smartctl -t longfalha anterior ocorreu devido a falhas de leitura, decidi que todos os setores fossem tocados e reescritos algumas vezes para ver como os valores SMART mudariam. Outrosmartctlteste está pendente; se isso falhar novamente, comprarei uma nova unidade.fonte
Algumas observações de desempenho:
Estou executando
e2fsck -c -c -v /dev/sda2, que reside neste dispositivo:O tempo de execução atual para 63,5% é 53:28:40; 53,5 horas. A taxa de progresso é de 1,186% / hora. Nesse ritmo, serão necessárias 31 horas adicionais para concluir, com um tempo total estimado de execução de 85 horas. Este é um dispositivo USB 3.0. iotop indica que a velocidade média de leitura / gravação é de cerca de 25 MB / s. Até agora, zero blocos ruins foram encontrados.
A linha de comando subjacente executada
e2fscké:Postagens no StackOverflow afirmam que é seguro interromper badblocks com ^ C (SIGTERM). Se eu fizer isso, não vejo a desvantagem de interromper esse teste e continuar no futuro mais tarde, pois esta é uma operação em nível de bloco de disco. Preciso desmontar esse sistema de arquivos antes de continuar com a porcentagem de verificação concluída.
fonte