¿Cómo reparo fácilmente un solo bloque ilegible en un disco Linux?

22

Mi sistema Linux ha comenzado a arrojar errores SMART en el syslog. Lo rastreé y creo que el problema es un solo bloque en el disco. ¿Cómo hago para que el disco reasigne ese bloque fácilmente? Me gustaría saber qué archivo se destruyó en el proceso. (Soy consciente de que si un bloque falla en un disco, es probable que otros lo sigan; tengo una buena copia de seguridad en curso y solo quiero tratar de mantener este disco funcionando).

La búsqueda en la web conduce al Bad block HOWTO , que describe un proceso manual en un disco desmontado. Parece complicado y propenso a errores. ¿Existe una herramienta para automatizar este proceso en Linux? Mi única otra opción es la herramienta de diagnóstico del fabricante , pero supongo que golpeará el bloque defectuoso sin ningún informe sobre lo que se destruyó. En el peor de los casos, podrían ser metadatos del sistema de archivos.

El disco en cuestión es la partición primaria del sistema. Usando ext3fs y LVM. Aquí está el registro de errores de syslog y el bit relevante de smartctl.

smartd[5226]: Device: /dev/hda, 1 Currently unreadable (pending) sectors

Error 1 occurred at disk power-on lifetime: 17449 hours (727 days + 1 hours)
... Error: UNC at LBA = 0x00d39eee = 13868782

Hay un volcado de smartctl completo en pastebin .

Nelson
fuente
Pensé que el firmware del disco volvería a asignar automáticamente el bloque defectuoso en la lectura, por lo que, en teoría, ya se ha hecho. Como se indica a continuación, ejecute fsck (o el equiv correcto para su FS) para asegurarse de que el FS superpuesto sigue siendo estable.
BuildTheRobots
2
Tengo entendido que el firmware del disco solo reasignará el bloque en escritura , no en lectura. Entonces realmente necesito forzar una escritura en el bloque en cuestión.
Nelson
1
Finalmente retiré este disco. Funcionó bien durante varios meses, pero después del quinto error de lectura, me di por vencido.
Nelson

Respuestas:

12

Podrías intentarlo hdparm --write-sector <LBA> /dev/ice.

No conozco ninguna otra forma de hacerlo: debe convertir manualmente el LBA en bloques del sistema de archivos (como ya ha encontrado)

James
fuente
Ooh, esa es una nueva bandera! Eso definitivamente se encargará de reasignar el bloque malo. Ahora todo lo que necesito es una manera fácil de encontrar lo que golpeará.
Nelson
3
Habiendo usado este método para arreglar un disco, puedo decir que este es el método correcto. Forzar una escritura en el sector en cuestión obligará a la unidad a enfrentar el sector y (a) obtener una escritura exitosa, o (b) terminar con un segundo mal permanente junto con una reasignación.
Avery Payne
¡Excelente! Y mucho más fácil que smartmontools.sourceforge.net/badblockhowto.html
Janning
¡Es extraño que este proceso iterativo (de buscar el próximo sector defectuoso a través de SMART y obligarlo a reasignarse) no esté automatizado con una simple utilidad! ..
imz - Ivan Zakharyaschev
32

Solía ​​escribir firmware de disco para WD, y una vez escribí el firmware que reasignaba bloques defectuosos.

Primero, la mayoría de los bloques defectuosos se detectan en lecturas, no en escrituras. Las escrituras se realizan a ciegas, lo que significa que los datos se escriben sin ser verificados. Por lo tanto, en una escritura, si los medios son malos, no lo sabrá hasta que el host lea el sector. Hay una pequeña parte del sector (el encabezado del sector) que se lee en las escrituras para localizar el sector correcto, de modo que si hay un error al leer el encabezado del sector, la unidad reasignará el sector y lo escribirá con los datos recibidos del comando de escritura. Pero la gran mayoría de los bloques defectuosos se detectan en las lecturas, y solo porque una escritura tenga éxito en un sector no significa que los medios sean buenos o que el sector haya sido reasignado.

Ahora sobre la reasignación de bloques defectuosos (también llamada reasignación). Sí, normalmente la unidad intentará reasignar un sector si el error es suficientemente grave (es decir, la falla de ECC es lo suficientemente grave) pero la unidad aún podría recuperar los datos después de la corrección de ECC. Por lo general, esto se hace automáticamente. La única excepción es que el host podría haberle dicho previamente a la unidad que no hiciera reasignaciones automáticas, pero esto rara vez se hace.

Entonces, ¿qué sucede si la unidad lee y no puede recuperar los datos? Nada. El error se informa al host, pero no se realiza ninguna reasignación. El problema es que la unidad podría reasignar el sector, pero no tiene la menor idea de qué datos escribir en el sector recientemente reasignado. Si solo escribiera un montón de ceros, digamos, y luego el sector se volviera a leer, devolvería todos los ceros sin ninguna indicación de que los datos no fueran válidos. Esto es esencialmente lo mismo que la corrupción de datos. La unidad no puede contar con que el host realice un seguimiento de los errores por una variedad de razones (por ejemplo, ¿qué sucede si la unidad se movió a un nuevo host?), Por lo que el mejor curso de acción es no hacer nada cuando los datos pueden ' t ser recuperado.

Sin embargo, las unidades modernas guardarán la ubicación del sector defectuoso cuando no se pueda reasignar. El número de sectores defectuosos que esperan la reasignación se puede encontrar en los datos SMART. Lo que sucede es que si se realiza una escritura en uno de los sectores defectuosos en espera de reasignación, la reasignación se realiza porque la unidad ahora tiene datos válidos para escribir después de la reasignación. Por lo tanto, cuando la gente dice que escribir en un sector malo lo reasignará, eso es realmente solo la mitad de la historia. La unidad debe leerse primero para que pueda descubrir todos los sectores defectuosos que no se pueden reasignar automáticamente. Por lo tanto, puede escribir una unidad completa, y los datos SMART dirán que no hay sectores defectuosos esperando la reasignación, pero no necesariamente ha borrado la unidad de todos los sectores defectuosos. Entonces, si realmente desea borrar una unidad de todos los sectores defectuosos

Hay otras formas de lidiar con bloques defectuosos que no se pueden reasignar. Si la unidad es parte de una configuración RAID redundante (es decir, cualquier cosa menos RAID 0), el software RAID debería recuperar automáticamente los datos de un sector defectuoso de las otras unidades y escribirlos en el sector reasignado. Los discos SCSI tienen un comando explícito de reasignación de bloques que el host puede usar para forzar la reasignación incluso cuando no hay datos válidos para escribir en el bloque, pero su uso es bastante bajo.

tenner
fuente
1
También vale la pena mencionar que al menos algunos HDD de Seagate son compatibles con Write-Read-Verify, que se puede activar usando hdparm -R(suponiendo un hdparm razonablemente reciente). Esto conlleva una penalización significativa del rendimiento de escritura (aproximadamente reducir a la mitad el rendimiento de escritura y escribir IOPS, porque cada escritura ahora incurre en una lectura posterior), pero si su hardware lo admite y su carga de trabajo es de lectura pesada, esta puede ser una medida preventiva muy viable .
un CVn
2

Creo que todo lo que tienes que hacer es:

e2fsck -c /dev/hda1

suponiendo que / dev / hda1 es la partición (desmontada). O:

e2fsck -c -c /dev/hda1

hacer una prueba de lectura / escritura no destructiva (más lenta). Todavía tendrá que desmontarse. Sin embargo, no creo que esto le dé detalles sobre los datos perdidos.

Matthew Flaschen
fuente
Pero es una pena que eso no parezca utilizar la información de SMART sobre los bloques defectuosos. Me pregunto por qué no hay una herramienta fsck que use la información de bloque incorrecta de SMART e intente evitarlos o reparar los archivos afectados como se describe en smartmontools.sourceforge.net/badblockhowto.html o serverfault.com/a/106130/68972 . ..
imz - Ivan Zakharyaschev
2

Michael lo tiene correcto y, en la mayoría de los casos, diría que simplemente reemplace el disco, son baratos. Sin embargo, si no tiene copias de seguridad y no puede obtener datos importantes de la unidad, o simplemente quiere intentar reparar la unidad, entonces puede intentar usar spinrite , en el nivel más alto.

Tenía una unidad portátil que comenzó a hacer algunos ruidos hace unos años. Los bloques defectuosos mostraron que la unidad tenía 118 bloques defectuosos visibles para el usuario final. Como ya tenía una copia de SpinRite, decidí probarlo antes de comprar una nueva unidad. Después de ejecutar spinrite en la unidad, los bloques defectuosos mostraron 0 bloques defectuosos y los ruidos se detuvieron. La unidad había estado funcionando durante más de dos años desde entonces.

3dinfluence
fuente
Nelson, ¿vas a rechazar cada respuesta que no es lo que quieres escuchar? Una unidad en buen estado reasignará automáticamente un bloque defectuoso. Si tiene que hacer todo lo posible para forzar esto, la unidad ya no está en buen estado y debe reemplazarse.
3dinfluence el
No, solo rechacé una respuesta porque no respondió mi pregunta. Sugeriste spinrite, gracias! Tengo entendido que una unidad saludable no reasignará un sector defectuoso hasta que se haya escrito. Estoy tratando de encontrar la forma más sencilla de forzar una escritura. Ir a la sugerencia de Matthew y ver si fsck es lo suficientemente inteligente como para hacerlo.
Nelson
Lo siento, llegué a conclusiones allí después de ver que 2 respuestas fueron rechazadas rápidamente y tú respondes a la otra respuesta, supuse que eras tú.
3dinfluence
2
Tiene razón en que la reasignación del sector defectuoso ocurre cuando una escritura falla en un bloque. Si solo tiene un bloque dañado en lo que respecta al sistema de archivos, fsck puede solucionar su problema si el bloque en cuestión es un bloque de metadatos. fsck realmente solo escanea y corrige errores en los metadatos. Por lo tanto, no ofrece garantías sobre los datos en sí. Los sistemas de archivos de próxima generación como BTRFS y ZFS pueden detectar y, si tiene redundancia, corregir los errores de datos. Spinrite también forzaría esto mientras lee, luego escribe los datos invertidos, los vuelve a leer, luego invierte los datos nuevamente en cada bloque como parte de su escaneo.
3dinfluence el
1

Si tiene copias de seguridad y sabe que se trata de un error lógico y no físico, entonces la mejor manera de hacerlo sería poner a cero el disco.

Usaría MHDD, es bastante fácil de usar y siempre que recuerde configurar su HDD en Bios para emulación IDE y luego volver a AHCI cuando termine su trabajo, no tiene nada de qué preocuparse.

Una vez que inicie en MHDD, elija su tipo de unidad en el comando ERASE y confirme su elección.

Consíguete café, esto puede tomar un tiempo.

Después de que la unidad se pone a cero, ejecute el escaneo (f4) con Remap configurado en ON (el valor predeterminado es off). Si todavía hay problemas con la unidad (significaría que hay un daño físico en el plato y la unidad está en una pendiente hacia abajo), esta opción los "arreglará" al mapear el área dañada a las partes saludables de la unidad.

Si no hay errores de UNC, felicidades, usted y su unidad pueden seguir siendo amigos en los próximos años.

Jahith
fuente
-1

Si el disco falla, reemplácelo. No vale la pena el riesgo de que se desmorone más.

Michael Graff
fuente
Fui explícito sobre saber que el disco es malo y tener copias de seguridad para evitar el riesgo.
Nelson
2
Eso solo significa que estás dispuesto a jugar. No creo que eso signifique que no deba reemplazarse, solo que está dispuesto a ignorar ese consejo. Dudo que cualquier copia de seguridad pueda salvar su sistema de sí mismo a medida que el disco se desmorona, y las cosas se volverán muy inestables a medida que las cosas se degraden.
Michael Graff el
3
Esta respuesta debería ser un comentario ... La pregunta es específica y exhaustiva. Y por lo tanto, esto no es una respuesta.
Pitto