16-07-2022, 03:45 PM
-SOLUCIONADO-
Comento la solución y la correspondiente explicación para quien le pueda ser de utilidad.
Recordar que en resumen el problema era que tras fallos de lectura por bloques defectuosos en el SSD quedaba etiquetado con Error y en rojo en el administrador de almacenamiento del NAS a pesar de aparecer en estado Preparado tras su recuperación. Asimismo si intentaba volver a leer los ficheros que fallaron volvía a estado Sólo Lectura. La información SMART revelaba 6 bloques retirados por errores.
Preguntaba si formateando el volumen correspondiente volvería a poder seguir usando el SSD normalmente y quedaría marcado en verde sin etiqueta de Error en el historial de acceso al disco, y si haciendo esta operación no se activaría como volumen de sistema otro disco, cosa que quería evitar.
La SOLUCIÓN es bastante sencilla y es la siguiente:
1. Eliminar los archivos que fallaron en su lectura.
2. Ejecutar una búsqueda de bloques con errores (Almacenamiento > Disco > Acción…).
No se encuentran esta vez bloques con errores y el SSD pasa a representarse en verde, desaparece la etiqueta de error, que se sustituye por Bueno, e indica también Bueno en Historial de acceso al disco.
El disco funciona perfectamente en lectura/escritura y a pleno rendimiento, y pasa con éxito todas las pruebas, la rápida, la completa, y la comprobación del sistema de archivos del volumen.
La explicación de por qué funciona este procedimiento es la siguiente:
Por algún motivo, en lo que prefiero no entrar, falló la lectura de 6 bloques del SSD, y éste los retiró, es decir los marcó como defectuosos y los ocultó a través de su interfaz hacia el exterior, como si nunca hubieran existido. De esta manera el disco está perfectamente operativo, como si fuera un disco nuevo (con 6 bloques menos) que nunca hubiera fallado.
No obstante, al retirar 6 bloques el SSD afectó lógicamente a los archivos que estaban haciendo uso de ellos, que fueron concretamente 10… curioso este dato…
Esos 10 ficheros quedaron corruptos para el NAS pues evidentemente al intentar leer lo que quedaba de ellos la comprobación de integridad CRC fallaba, y como el sistema de archivos ignora que parte del fichero falta sencillamente da por bloques defectuosos todos los que forman parte de esos ficheros, nada menos que 178 bloques (no confundir con los bloques dañados del SSD).
Esto es llamativo pues si bien los bloques que ahora quedaban de esos ficheros se corresponden con información incompleta o corrupta, los bloques en sí no son defectuosos sino todo lo contrario, son todos buenos ya que el SSD retiró los malos.
Aquí es donde se genera realmente el problema, en mi opinión por un tratamiento incorrecto y una información errónea o cuanto menos confusa del S.O. de QNap, pues NO, no hay 178 bloques dañados como dice literalmente, hay 10 ficheros dañados, que es algo muy distinto, y de paso podría indicar que deben eliminarse o sustituirse por una copia buena de ellos y realizar una posterior búsqueda de bloques defectuosos o comprobar la estructura de archivos para retornar el disco a su estado operativo normal.
Al eliminar los archivos que no podían ser leídos por estar incompletos desaparece todo problema real o físico con el SSD y efectivamente toda prueba lógica resulta con éxito al no formar ya parte del disco los 6 supuestos bloques dañados.
Nadie me dio la información, tampoco figura en la documentación de QNap, pero pensé que si no había correspondencia entre los bloques que el SSD retiró y los que QTS identificó como dañados era por todo esto, por lo que deduje que ya no había en realidad bloques dañados, sólo ficheros corruptos, y que quitándolos todo estaría bien, y que por tanto si hacía búsqueda de bloques con errores ya no saldría ninguno, y así fue, y de paso resultó que esta prueba cuando sale con éxito cambia la etiqueta y el color del disco en su visualización en el gestor de almacenamiento, cosa que tampoco está documentada ni encontré que nadie lo comentara en los foros.
Mal trabajo de los desarrolladores de QNap en esta materia, pues ante por ejemplo 1 sólo bloque defectuoso en un SSD te hace entender que ese disco prácticamente hay que tirarlo, cuando en esta tecnología y en algunas de las marcas (aunque hasta ahora no lo había visto en Samsung), es de lo más normal, puede ocurrir con el disco casi recién estrenado y asimismo seguir funcionando luego perfectamente por muchos años.
No digo que no estaría de más que conservara una advertencia de que en su día falló, pero de ahí a etiquetarlo como Error y en rojo es excesivo, y más cuando el umbral de fallo, como reflejan los datos SMART, todos en verde, está por debajo de lo que el fabricante indica como aceptable, y que figura igualmente en los datos SMART que maneja el NAS.
Por otra parte, dudo que esos 6 bloques del SSD estén defectuosos, lo mismo alguien probó a recuperarlos, si es que hay utilidades para hacerlo con SSD tal como se hace con HDD. Lo digo, sólo como comentario final, porque cuando saltó el problema no fue con el SSD, fue según el NAS con el HDD1, indicando sectores dañados y dejando desmontados los volúmenes, que tras recuperarlos y entrar en SMART vi que no estaban ¡! Todo volvió a estar perfecto con el HDD y me quedé perplejo cuando ahora era el SSD, que no había dado ningún error, el que aparecía en rojo…
Sabemos por qué acaban fallando las memorias NAND, básicamente por el uso, tienen vida limitada, fundamentalmente en escritura, y esos 10 ficheros que fallaron se escribieron hace casi un año y tras el primer backup resulta que nunca más se habían vuelto ni siquiera a leer hasta ahora… no parece que esos bloques puedan estar deteriorados por escrituras continuadas, todo lo contrario, esos ficheros podemos decir que han protegido esos bloques del disco evitando que se escriban…
Tampoco he encontrado relación alguna entre los 6 bloques supuestamente dañados, ni espacial, ni lógicas, ni de direccionamiento, parece demasiada casualidad que fallen 6 bloques inconexos entre sí en el mismo instante, después de casi un año de no fallar ninguno, y tampoco por ahora se ha producido ningún nuevo bloque defectuoso…
En fin, no hace falta formatear, esa es la respuesta a mi pregunta inicial de este hilo, y por tanto tampoco hay riesgo de que el sistema pase a estar activo en otro disco, como quería evitar, cosa que sigo sin saber si ocurre si formateamos el volumen de sistema.
Dicho sea de paso, tampoco sé, ni he encontrado nada en los foros, de cómo se sustituye el disco de sistema, de quererse hacer sin que el sistema se pase a otro disco. Y cuando digo se pase me refiero a que se active, pues ya sabemos que el sistema está en todos los discos; y no es lo mismo que esté en uno o en otro, y sólo por citar un detalle, no se puede desmontar o usar el comando de separar de forma segura en el disco con el sistema activo.
Un saludo a todos y gracias a este foro, que tantas veces nos ayuda.
Comento la solución y la correspondiente explicación para quien le pueda ser de utilidad.
Recordar que en resumen el problema era que tras fallos de lectura por bloques defectuosos en el SSD quedaba etiquetado con Error y en rojo en el administrador de almacenamiento del NAS a pesar de aparecer en estado Preparado tras su recuperación. Asimismo si intentaba volver a leer los ficheros que fallaron volvía a estado Sólo Lectura. La información SMART revelaba 6 bloques retirados por errores.
Preguntaba si formateando el volumen correspondiente volvería a poder seguir usando el SSD normalmente y quedaría marcado en verde sin etiqueta de Error en el historial de acceso al disco, y si haciendo esta operación no se activaría como volumen de sistema otro disco, cosa que quería evitar.
La SOLUCIÓN es bastante sencilla y es la siguiente:
1. Eliminar los archivos que fallaron en su lectura.
2. Ejecutar una búsqueda de bloques con errores (Almacenamiento > Disco > Acción…).
No se encuentran esta vez bloques con errores y el SSD pasa a representarse en verde, desaparece la etiqueta de error, que se sustituye por Bueno, e indica también Bueno en Historial de acceso al disco.
El disco funciona perfectamente en lectura/escritura y a pleno rendimiento, y pasa con éxito todas las pruebas, la rápida, la completa, y la comprobación del sistema de archivos del volumen.
La explicación de por qué funciona este procedimiento es la siguiente:
Por algún motivo, en lo que prefiero no entrar, falló la lectura de 6 bloques del SSD, y éste los retiró, es decir los marcó como defectuosos y los ocultó a través de su interfaz hacia el exterior, como si nunca hubieran existido. De esta manera el disco está perfectamente operativo, como si fuera un disco nuevo (con 6 bloques menos) que nunca hubiera fallado.
No obstante, al retirar 6 bloques el SSD afectó lógicamente a los archivos que estaban haciendo uso de ellos, que fueron concretamente 10… curioso este dato…
Esos 10 ficheros quedaron corruptos para el NAS pues evidentemente al intentar leer lo que quedaba de ellos la comprobación de integridad CRC fallaba, y como el sistema de archivos ignora que parte del fichero falta sencillamente da por bloques defectuosos todos los que forman parte de esos ficheros, nada menos que 178 bloques (no confundir con los bloques dañados del SSD).
Esto es llamativo pues si bien los bloques que ahora quedaban de esos ficheros se corresponden con información incompleta o corrupta, los bloques en sí no son defectuosos sino todo lo contrario, son todos buenos ya que el SSD retiró los malos.
Aquí es donde se genera realmente el problema, en mi opinión por un tratamiento incorrecto y una información errónea o cuanto menos confusa del S.O. de QNap, pues NO, no hay 178 bloques dañados como dice literalmente, hay 10 ficheros dañados, que es algo muy distinto, y de paso podría indicar que deben eliminarse o sustituirse por una copia buena de ellos y realizar una posterior búsqueda de bloques defectuosos o comprobar la estructura de archivos para retornar el disco a su estado operativo normal.
Al eliminar los archivos que no podían ser leídos por estar incompletos desaparece todo problema real o físico con el SSD y efectivamente toda prueba lógica resulta con éxito al no formar ya parte del disco los 6 supuestos bloques dañados.
Nadie me dio la información, tampoco figura en la documentación de QNap, pero pensé que si no había correspondencia entre los bloques que el SSD retiró y los que QTS identificó como dañados era por todo esto, por lo que deduje que ya no había en realidad bloques dañados, sólo ficheros corruptos, y que quitándolos todo estaría bien, y que por tanto si hacía búsqueda de bloques con errores ya no saldría ninguno, y así fue, y de paso resultó que esta prueba cuando sale con éxito cambia la etiqueta y el color del disco en su visualización en el gestor de almacenamiento, cosa que tampoco está documentada ni encontré que nadie lo comentara en los foros.
Mal trabajo de los desarrolladores de QNap en esta materia, pues ante por ejemplo 1 sólo bloque defectuoso en un SSD te hace entender que ese disco prácticamente hay que tirarlo, cuando en esta tecnología y en algunas de las marcas (aunque hasta ahora no lo había visto en Samsung), es de lo más normal, puede ocurrir con el disco casi recién estrenado y asimismo seguir funcionando luego perfectamente por muchos años.
No digo que no estaría de más que conservara una advertencia de que en su día falló, pero de ahí a etiquetarlo como Error y en rojo es excesivo, y más cuando el umbral de fallo, como reflejan los datos SMART, todos en verde, está por debajo de lo que el fabricante indica como aceptable, y que figura igualmente en los datos SMART que maneja el NAS.
Por otra parte, dudo que esos 6 bloques del SSD estén defectuosos, lo mismo alguien probó a recuperarlos, si es que hay utilidades para hacerlo con SSD tal como se hace con HDD. Lo digo, sólo como comentario final, porque cuando saltó el problema no fue con el SSD, fue según el NAS con el HDD1, indicando sectores dañados y dejando desmontados los volúmenes, que tras recuperarlos y entrar en SMART vi que no estaban ¡! Todo volvió a estar perfecto con el HDD y me quedé perplejo cuando ahora era el SSD, que no había dado ningún error, el que aparecía en rojo…
Sabemos por qué acaban fallando las memorias NAND, básicamente por el uso, tienen vida limitada, fundamentalmente en escritura, y esos 10 ficheros que fallaron se escribieron hace casi un año y tras el primer backup resulta que nunca más se habían vuelto ni siquiera a leer hasta ahora… no parece que esos bloques puedan estar deteriorados por escrituras continuadas, todo lo contrario, esos ficheros podemos decir que han protegido esos bloques del disco evitando que se escriban…
Tampoco he encontrado relación alguna entre los 6 bloques supuestamente dañados, ni espacial, ni lógicas, ni de direccionamiento, parece demasiada casualidad que fallen 6 bloques inconexos entre sí en el mismo instante, después de casi un año de no fallar ninguno, y tampoco por ahora se ha producido ningún nuevo bloque defectuoso…
En fin, no hace falta formatear, esa es la respuesta a mi pregunta inicial de este hilo, y por tanto tampoco hay riesgo de que el sistema pase a estar activo en otro disco, como quería evitar, cosa que sigo sin saber si ocurre si formateamos el volumen de sistema.
Dicho sea de paso, tampoco sé, ni he encontrado nada en los foros, de cómo se sustituye el disco de sistema, de quererse hacer sin que el sistema se pase a otro disco. Y cuando digo se pase me refiero a que se active, pues ya sabemos que el sistema está en todos los discos; y no es lo mismo que esté en uno o en otro, y sólo por citar un detalle, no se puede desmontar o usar el comando de separar de forma segura en el disco con el sistema activo.
Un saludo a todos y gracias a este foro, que tantas veces nos ayuda.