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.