Solución 1:
Solía escribir firmware de disco para WD y una vez escribí el firmware que reasignaba bloques defectuosos.
En primer lugar, 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 comprobarlos. Por lo tanto, en una escritura, si el medio es malo, no lo sabrá hasta que el host realice una lectura en ese sector. Hay una pequeña parte del sector (el encabezado del sector) que se lee y 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 las lecturas, y el hecho de que una escritura tenga éxito en un sector no significa que el medio sea bueno 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 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 realiza una lectura 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 recién reasignado. Si solo escribiera un montón de ceros, digamos, y luego se volviera a leer el sector, 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 una variedad de razones (por ejemplo, ¿qué sucede si la unidad se trasladó 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. El número de sectores defectuosos en espera de 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 que esperan la 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 defectuoso lo reasignará, eso es solo la mitad de la historia. La unidad debe leerse primero para que la unidad pueda descubrir todos los sectores defectuosos que no se pueden reasignar automáticamente. Por lo tanto, puede escribir un disco completo y los datos SMART dirán que no hay sectores defectuosos esperando reasignación, pero no necesariamente ha limpiado el disco de todos los sectores defectuosos. Entonces, si realmente desea borrar todos los sectores defectuosos de una unidad, 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 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.
Solución 2:
Podrías probar hdparm --write-sector <LBA> /dev/ice .
No conozco otra forma de hacer esto:debe convertir manualmente el LBA en bloques del sistema de archivos (como ya encontró)
Solución 3:
Creo que todo lo que tienes que hacer es:
e2fsck -c /dev/hda1
asumiendo que /dev/hda1 es la partición (desmontada). O:
e2fsck -c -c /dev/hda1
para hacer una prueba de lectura y escritura no destructiva (más lenta). Todavía tendrá que ser desmontado. Sin embargo, no creo que esto le brinde detalles sobre los datos perdidos.
Solución 4:
Michael lo tiene correcto y, en la mayoría de los casos, diría que simplemente reemplace la unidad, son baratos. Sin embargo, si no tiene copias de seguridad y no puede obtener datos importantes de la unidad, o simplemente desea intentar reparar la unidad, puede intentar usar spinrite, en el nivel más alto.
Tenía una unidad de computadora portátil que comenzó a hacer algunos ruidos hace unos años. Badblocks mostró que la unidad tenía aproximadamente 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, badblocks mostró 0 bloques defectuosos y los ruidos cesaron. La unidad había estado funcionando durante más de dos años desde entonces.