
Mi sistema Linux ha comenzado a arrojar errores SMART en el syslog. Lo localicé y creo que el problema es un solo bloque en el disco. ¿Cómo hago para que el disco reasigne fácilmente ese bloque? 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 intentar que este disco siga funcionando).
La búsqueda en la web lleva ael bloque malo COMO, que describe un proceso manual en un disco desmontado. Parece complicado y propenso a errores. ¿Existe alguna herramienta para automatizar este proceso en Linux? Mi única otra opción esla herramienta de diagnóstico del fabricante, pero supongo que eso destruirá el bloque defectuoso sin informar 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 completo de smartctlen pastbin.
Respuesta1
Tu podrías intentar hdparm --write-sector <LBA> /dev/ice
.
No conozco otra forma de hacer esto: debes convertir manualmente el LBA en bloques del sistema de archivos (como ya has descubierto).
Respuesta2
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 el medio es malo, no lo sabrá hasta que el host lea ese sector. Hay una pequeña parte del sector (el encabezado del sector) que se lee y se escribe para ubicar 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 lecturas, y el hecho de que 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 incorrectos (también llamada reasignación). Sí, normalmente la unidad intentará reasignar un sector si el error es lo 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 ECC. Normalmente esto se hace automáticamente. La única excepción es que el host podría haberle dicho previamente a la unidad que no realizara reasignaciones automáticas, pero esto rara vez se hace.
Entonces, ¿qué sucede si la unidad realiza una lectura y no puede recuperar los datos? Nada. El error se informa al anfitrión, 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 recién reasignado. Si simplemente escribiera un montón de ceros, por ejemplo, y luego se leyera el sector nuevamente, devolvería todos los ceros sin ninguna indicación de que los datos no eran 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 diversas razones (por ejemplo, ¿qué pasa 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 no pueden. t ser recuperado.
Sin embargo, las unidades modernas guardarán la ubicación del sector defectuoso cuando no se pueda reasignar. La cantidad de sectores defectuosos que esperan 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 a un sector malo lo reasignará, en realidad eso es sólo la mitad de la historia. Primero se debe leer la unidad 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 reasignación, pero no necesariamente ha borrado todos los sectores defectuosos de la unidad. Entonces, si realmente desea limpiar una unidad de todos los sectores defectuosos, lo mejor es leer primero la unidad completa y luego escribir toda la unidad (por supuesto, esto destruirá todos los datos anteriores en la unidad).
Hay otras formas de lidiar con bloques defectuosos que no se pueden reasignar. Si la unidad forma parte de una configuración RAID redundante (es decir, cualquier cosa que no sea 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 de nivel bastante bajo.
Respuesta3
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
para realizar una prueba de lectura y escritura no destructiva (más lenta). Aún habrá que desmontarlo. Sin embargo, no creo que esto le brinde detalles sobre los datos perdidos.
Respuesta4
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.
Yo 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 haya terminado, no tendrá nada de qué preocuparse.
Una vez que inicie MHDD, elija el tipo de unidad en el comando BORRAR y confirme su elección.
Consíguete un café, esto puede llevar un tiempo.
Después de poner a cero la unidad, ejecute scan(f4) con Remap configurado en ON (el valor predeterminado está desactivado). 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 constante hacia abajo), esta opción los "solucionará" asignando el área dañada a partes sanas de la unidad.
Si no hay errores UNC, felicidades, usted y su unidad podrán seguir siendo amigos en los años venideros.