¿Cuánto tardan los badblocks en una unidad de 1 TB?

Estoy ejecutando badblocks (o más bien "e2fsck -c") en una unidad de 1TB y si el indicador de progreso es una indicación (sin juego de palabras), tardará casi una eternidad en completarse.

En este momento dice 0.01% done, 30:20 elapsedlo que significaría que la cosa tardaría aproximadamente 17 semanas en completarse, lo que parece bastante excesivo en mi libro.

¿Es una cantidad de tiempo normal para que se lleve a cabo tal verificación o simplemente que mis sospechas son correctas en el sentido de que la unidad está fallando, lo que hace que la verificación demore un poco más que la eternidad?

Encontré esta pregunta aquí, pero eso se refiere a la cantidad de pases realizados.

Para responder a su pregunta, lo más que puedo ofrecer es con un 3 TB que probé para esto. Aquí están las pruebas 3 veces que hice, solo cambiando los valores de los parámetros -cy solo haciéndolos hasta un 10% ya que tomaron MUCHO tiempo. Cada uno se hizo 3 veces para obtener un promedio.

badblocks -svn /dev/sdb

Para llegar al 1%: 1 hora
Para llegar al 10%: 8 horas 40 minutos

badblocks -svn -b 512 -c 32768 /dev/sda

Para llegar al 1%: 35 minutos
Para llegar al 10%: 4 horas 10 minutos

badblocks -svn -b 512 -c 65536 /dev/sda

Para llegar al 1%: 16 minutos
Para llegar al 10%: 2 horas 35 minutos

Entonces, sí, el -cparámetro tiene una gran influencia en el tiempo que lleva verificar la unidad. Supongo que para un disco duro de 1 TB, suponiendo que mantenga el mismo marco de tiempo que el de 3 TB, sería 1/3 del tiempo mencionado aquí, por lo que para llegar al 10% con -c 65536el disco duro de 1 TB sería aproximadamente 50 minutos

Badblocks hace 4 carreras. En una HD externa de 1 TB, generalmente demora alrededor de 70 horas.

Intente aumentar la cantidad de bloques procesados ​​juntos, como en badblocks -svn -b 512 -c 65536 /dev/sda. De esta manera, puedo hacer que comprueben una unidad de disco duro de 1 TB en 8 horas.

Estoy ejecutando badblocks en unidades WD Red de 4 TB. Como son unidades de sector 4k (comprobadas usando lsblk -o NAME,PHY-SeC), lo estoy ejecutando -b 4096. Quería darle a cada una de las instancias de badblocks ~ 800Mb de RAM, así que utilicé lo -c 200000que te da 4096 bytes * 200,000 blocks = 800,000 Kb. Comenzaron con alrededor de 800Mb cada uno, pero eso se incrementó con el tiempo. Sin embargo, esta configuración proporciona una aceleración significativa sobre la configuración estándar.

Funcionó 1% en 3min 56sec pero eso es 1% de 4 patrones. También parece tomar más tiempo cuanto más te acercas al final de una carrera. Verificó el disco con el primer patrón en aproximadamente 17 horas, por lo que debería completar 4 TB en aproximadamente 68 horas .

MANDO A CONTINUACIÓN CORRE UNA ESCRITURA DESTRUCTIVA

El comando que estoy usando es: badblocks -svw -b 4096 -c 200000 /dev/sdc -o bb_sdc.txt

Ejecuté esto anteayer en una unidad fallida de 1 TB en mi 6TB RAID 6 (¡MODO DE ESCRITURA DESTRUCTIVA!):

# badblocks -svw -b 4096 -c 65536 /dev/sdb

La placa base es un ASRock Rack C2550D4I (lo sé ...) con 8x Samsung SpinPoint M8 HN-M101MBB (lo sé ...) conectado a los puertos SATA3. Las unidades son unidades 4K de "Formato avanzado", de ahí el tamaño de bloque 4K.

badblocks tardó unas 28 horas en terminar, sin errores.

Las unidades individuales hacen ~ 105 MB / seg (tiempo promedio de hdparm -tTlectura almacenado en el búfer), 200–230 MB / seg cuando se prueba toda la matriz. Nada superior, hoy en día, pero agradable para un montón de unidades de portátiles antiguas.

Espero que esto ayude tanto como este hilo me ayudó a encontrar una manera rápida de ejecutar un bloque defectuoso en el disco. Sé que su uso es dudoso en estos días, pero cuando un smartctl -t longerror anterior se debió a errores de lectura, decidí tocar y reescribir todos los sectores varias veces para ver cómo cambiarían los valores SMART. Otra smartctlprueba está pendiente, si eso falla nuevamente, compraré una nueva unidad.

Algunas observaciones de rendimiento:

Estoy corriendo e2fsck -c -c -v /dev/sda2, que reside en este dispositivo:

/dev/sda2  77056 976754431 976677376  3.7T Linux filesystem

El tiempo de ejecución actual para 63.5% es 53:28:40; 53,5 horas. La tasa de progreso es 1.186% / hora. A este ritmo, tardará 31 horas adicionales en completarse, con un tiempo de ejecución total estimado de 85 horas. Este es un dispositivo USB 3.0. iotop indica que la velocidad promedio de lectura / escritura es de aproximadamente 25 MB / s. Hasta ahora, se han encontrado cero bloques defectuosos.

La línea de comando subyacente que ejecuta e2fsckes:

sh -c badblocks -b 4096 -X -s -n /dev/sda2 976677375

Publicaciones en el estado de StackOverflow es seguro interrumpir bloques defectuosos con ^ C (SIGTERM). Debo hacerlo, no veo el inconveniente de detener esta prueba y reanudarla en el futuro más adelante, ya que esta es una operación a nivel de bloque de disco. Debo desmontar este sistema de archivos antes de continuar con el análisis porcentual completado.