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

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 .

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)

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.

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.

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.

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.

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