Un sector ilegible pendiente es aquel que devolvió un error de lectura y que la unidad ha marcado para reasignación en la primera oportunidad posible. Sin embargo, no puede reasignar hasta que ocurra una de estas dos cosas:
- El sector se relee con éxito
- El sector se reescribe
Hasta entonces, el sector sigue pendiente. Así que tienes dos formas correspondientes de lidiar con esto:
- Sigue intentando releer el sector hasta que tengas éxito
- Sobrescribir ese sector con nuevos datos
Obviamente, (1) no es destructivo, por lo que probablemente debería probarlo primero, aunque tenga en cuenta que si la unidad comienza a fallar de manera grave, es probable que la lectura continua desde un área defectuosa haga que falle mucho más rápido. . Si tiene muchos sectores pendientes y otros errores, y le preocupan los datos en el disco, le recomiendo ponerlo fuera de servicio y usar la excelente herramienta ddrescue para recuperar la mayor cantidad de datos posible. Luego deseche la unidad.
Si el sector en cuestión contiene datos que no le interesan o puede restaurar desde una copia de seguridad, sobrescribirlos es probablemente la solución más rápida y sencilla. A continuación, puede ver los recuentos reasignados y pendientes de la unidad para asegurarse de que se ha atendido el sector.
¿Cómo saber a qué corresponde el sector en el sistema de archivos? Encontré un excelente artículo sobre smartmontools sitio web, aquí, aunque es bastante técnico y es específico para los sistemas de archivos ext2/3/4 y reiser.
Un enfoque más simple, que usé en una de mis unidades (Mac), es usar find / -xdev -type f -print0 | xargs -0 ... para leer todos los archivos del sistema. Tome nota del conteo pendiente antes de ejecutar esto. Si el sector está dentro de un archivo, recibirá un mensaje de error de la herramienta que usó para leer los archivos (por ejemplo, md5sum) que le mostrará la ruta. A continuación, puede centrar su atención en volver a leer solo este archivo hasta que se lea correctamente. A menudo, esto resolverá el problema, si se trata de un archivo que se usa con poca frecuencia y que solo necesita volver a leerse unas cuantas veces. Si el error desaparece o no encuentra ningún error al leer todos los archivos, verifique el conteo pendiente para ver si ha disminuido. Si es así, el problema se resolvió leyendo.
Si el archivo no se puede leer correctamente después de varios intentos (por ejemplo, 20), entonces debe sobrescribir el archivo, o el bloque dentro del archivo, para permitir que la unidad reasigne el sector. Puede usar ddrescue en el archivo (en lugar de la partición) para sobrescribir solo un sector, copiándolo en un archivo temporal y luego volviendo a copiarlo. Tenga en cuenta que simplemente eliminar el archivo en este punto es una mala idea, porque el sector defectuoso irá a la lista libre donde será más difícil de encontrar. Sobrescribirlo por completo también es malo, porque nuevamente los sectores irán a la lista libre. Necesitas reescribir los bloques existentes. El notrunc opción de dd es una manera de hacer esto.
Si no encuentra errores y el conteo pendiente no disminuyó, entonces el sector debe estar en la lista libre o en parte de la infraestructura del sistema de archivos (por ejemplo, una tabla de inodos). Puedes intentar llenar todo el espacio libre con cat /dev/zero >tempfile y, a continuación, compruebe el recuento pendiente. Si se cae, el problema estaba en la lista libre y ahora desapareció.
Si el sector está en la infraestructura, tiene un problema más serio y probablemente encontrará errores simplemente caminando por el árbol de directorios. En esta situación, creo que la única solución sensata es reformatear el disco, opcionalmente usando ddrescue para recuperar datos si es necesario.
Vigila muy de cerca el disco. La reasignación de sectores es un canario muy bueno en la mina de carbón, ya que puede brindarle una advertencia temprana de una unidad que está fallando. Al tomar medidas tempranas, puede evitar un deslizamiento de tierra catastrófico y muy doloroso posterior. No estoy sugiriendo que algunas reasignaciones de sector sean una indicación de que deba descartar la unidad. Todas las unidades modernas deben reasignarse. Sin embargo, si la unidad no es muy antigua (menos de 1 año) o recibe nuevas reasignaciones con frecuencia (más de una vez por mes), le recomiendo que la reemplace lo antes posible.
No tengo evidencia empírica para probarlo, pero mi experiencia sugiere que los problemas del disco se pueden reducir leyendo todo el disco de vez en cuando, ya sea por un dd del disco sin procesar o leyendo cada archivo usando find . Casi todos los problemas de disco que he experimentado en los últimos años han surgido primero en archivos que rara vez se usan o en máquinas que no se usan mucho. Esto también tiene sentido desde el punto de vista heurístico, ya que si un sector se vuelve a leer con frecuencia, la unidad tiene la posibilidad de reasignarlo cuando detecta por primera vez un problema menor con ese sector en lugar de esperar hasta que el sector sea completamente ilegible. La unidad no puede hacer nada con un sector a menos que el host acceda a él de alguna manera, ya sea leyéndolo o escribiéndolo o realizando una de las pruebas SMART.
Me gustaría experimentar con la idea de un trabajo cron nocturno o semanal que lea todo el disco. Actualmente estoy usando un "RAID del hombre pobre" en el que tengo un segundo disco duro en la máquina y hago una copia de seguridad del disco principal todas las noches. De alguna manera, esto es mejor que la duplicación de RAID, porque si me equivoco y elimino un archivo por error, puedo obtener la versión anterior inmediatamente del disco de respaldo. Por otro lado, creo que un controlador RAID de hardware hace un gran trabajo en segundo plano para monitorear, informar y solucionar problemas de disco a medida que surgen. Mi script de respaldo actual usa rsync para evitar copiar datos que no han cambiado, pero en vista de la necesidad de volver a leer todos los sectores, tal vez sería mejor copiar todo, o tener un script separado que lea todo el disco sin formato cada semana.