¿Machaca el S.O. de QNap los SSD dañando sectores o generando bloques defectuosos?

[Josus]

Hola compañeros,
 
Tengo la sospecha de que el Sistema Operativo de QNap tiene procesos poco eficientes y perjudiciales para los SSD en que se ejecuta, realizando bucles de escritura que acaban por dañar sectores, o mejor dicho bloques de los SSD, que no están diseñados para esta forma de trabajo, con memorias con limitado número de escrituras.
 
Quería por tanto preguntar a otros usuarios que tengan un NAS QNap con S.O. QTS en SSD, es decir uno o más discos SSD de sistema si en las tablas SMART de los mismos les aparece algún número de sectores dañados, reflejándose con un valor mayor de cero en los siguientes campos:
            1 - Retired_Block_Count
            179 - Used_Rsvd_Blk_Cnt_Tot
            183 - Runtime_Bad_Block
 
Los SSD son dos Samsung EVO 870 de 2 TB en RAID 1 con el sistema, uno con menos de 1 año y el otro con menos de 2 y ambos con vida útil restante estimada aún al 100%. Estos SSD ocupan las bahías 1 y 2 del NAS, en el resto hay HDD.
 
Los bloques dañados en el SSD 1 son 5 y en el 2 son 26.
 
Para consultar la tabla SMART: Almacenamiento e instantáneas > Discos > Condición del disco > Información SMART > Disco 1 / Disco 2
 
El NAS es un TS-431P3 con la última versión del SO: QTS 5.0.1.2248, aunque en estos casi 2 años ha pasado también por las versiones anteriores correspondientes.
 
Decir que no parece afectar al funcionamiento del NAS, y de hecho no se ha corrompido ningún archivo y ni siquiera ha enviado ningún tipo de notificación al respecto; más aún, aunque se supere el umbral que Samsung marca para los mencionados campos SMART, que es de 10, QTS lo etiqueta y considera como “Bueno” y en verde.
 
¿Será que QNap sabe del problema y por eso lo deja en verde, o es sencillamente un descuido?
 
El que no se corrompan ficheros probablemente es que al estar en RAID1, cuando un sector de uno de los SSD queda dañado, los ficheros que eventualmente resultan afectados se restauran automáticamente desde el otro SSD, y por su parte el disco afectado retira ese bloque quedando por tanto en “perfecto” estado de funcionamiento, tanto que en realidad los primeros sectores dañados aparecieron antes de un año aunque no puedo precisar si fue cosa de meses, semanas o tal vez días, pues hasta que no leí un fichero corrupto cuando aún no tenía los SSD en RAID 1 no me percaté del problema.
 
De manera que con esta configuración hay que mirar las tablas SMART y hacer seguimiento para comprobar si se están dañando los SSD de sistema. Y eso es lo que quisiera saber, si alguno de vosotros con el sistema en SSD tiene bloques dañados en SMART.
 
Me llama mucho la atención que se estén generando estos bloques dañados porque conozco bien estos SSD, de los que tengo la mejor opinión, dispongo de unos cuantos en varios PC, todos con más tiempo y más carga de trabajo, algunos con menos del 80% de vida útil restante, y todos, absolutamente todos se mantienen sin ni un solo sector defectuoso, es decir, con esos campos SMART a cero, y hablo igualmente de SSD con el S.O. en su mayoría, en marcha 24 horas y sin nada de paso a reposo temporizado.
 
Si se confirma que los SSD son machacados sistemáticamente e innecesariamente en los equipos de QNap cabe plantearse o cambiar de marca, tal vez irse a un modelo de gama más alta si es que no tuviera este problema, o sencillamente no usar SSD sino HDD pues al fin y al cabo de poco sirve en cuanto a velocidad de acceso si se tienen HDD en modo reposo, ya que aunque se trate de acceder a datos en un SSD el sistema lo retrasará hasta poner en marcha los HDD en reposo, y por otro lado en cuanto a velocidad de transferencia, si se tiene conexión Gigabit hace que esta limitación del ancho de banda trabaje a la misma velocidad con SSD que con HDD, y no olvidemos que los HDD siguen siendo mucho más baratos además de no tener el problema de la limitación tan acusada del número de escrituras o vida útil de sus bloques o sectores.
 
Pues eso, ¿alguien con SSD de sistema? ¿Bloques dañados en SMART?
 
 
Un saludo a todos y gracias de antemano!

[Ganekogorta]

Hola

El sistema operativo en sí, está en unas particiones en todos y cada uno de los discos. Incluso en los de caché.

Digamos que es una raid 1 “especial”
La idea de esto es que en caso de rotura de un disco, la nas va a poder arrancar ya que usará datos del resto de los discos.

Otra cosa es que en lo que QTS denomina sistema, haya ciertas aplicaciones que sólo están ahí.
Por ejemplo la carpeta Public, la base de datos de mariaDB,…

Si a la nas le retiras el disco o el conjunto de sistema, está arrancará pero tardará más y recreará nuevas carpetas Public, … lo del “sistema”

Resumiendo, cuando se hacen cambios en el sistema operativo, estos se hacen en todos los discos.

[Josus]

Hola Ganekogorta,

Ciertamente es así como está implementado el S.O. en los discos del NAS, y particularmente en aquellos etiquetados como “Sistema” tiene sus peculiaridades e implicaciones.

Ahora que recordabas esta cuestión el problema podría ser aún mayor si también se escribiera continuamente en el resto de discos aunque no tengan el sistema activo en ellos. No obstante como apuntaba sólo afectaría a los SSD y de todos modos me atrevo a afirmar que no se da este problema en los discos “no de sistema” pues constato que esos discos, en mi caso HDD, entran en reposo, o sea que dejan de girar, y por lo tanto no están siendo escritos de forma continua; imagino que la actualización de la partición del S.O. se actualiza sólo cuando haya cambios sustanciales pues cuestiones como determinados ficheros temporales no tiene sentidos sean mantenidos en las copias y mucho menos en tiempo real, y son precisamente estos ficheros en el SSD con el sistema activo los que intuyo podrían estar machacando los bloques que acaban dañándose.

Sería muy interesante que compartieras si en tu caso tienes SSD dañados, o sea si alguno de esos campos de tus SSD de sistema no están a cero, eso claro está si en tus NAS tienes SSD de sistema.

Gracias por responder y esperemos que otros usuarios vayan compartiendo también esta información por la importancia que tiene y las implicaciones al menos en cuanto a seguridad e integridad de los datos almacenados, uno de los principales aspectos que debe cuidar un dispositivo como es el NAS.


Un saludo a todos!

[adrolmar]

Yo no uso SSDs, pero te puedo garantizar por experiencia propia que la herramienta SMART de QNAP es bastante imprecisa. En mi caso decía que tenía sectores defectuosos "irreversibles" en uno de mis HDs y tras una reinicialización desaparecieron para siempre.

Si puedes, yo sacaría ese SSD del NAS y lo pincharía en un sistema donde se pudiese pasar otro tipo de herramientas más fiables. No sé si será posible esto que comento.

[Josus]

Hola adrolmar,

Coincido contigo en que el manejo de SMART por QNap no es el mejor, algo parecido a lo que comentas me ocurrió también con un HDD, y fue precisamente entonces cuando vi que el SDD, que sólo tenía uno al principio, aparecía con 6 bloques retirados en la tabla SMART.

En aquella ocasión saqué el SDD (tras pasar la información y demás) y le hice un buen estudio desde Windows, todo tipo de pruebas con un buen arsenal de programas, incluyendo el propio de Samsung (Magician) y se vino a confirmar que efectivamente había 6 bloques que se habían retirado y que con eso el disco estaba perfectamente en todos los sentidos. No aparecieron nuevos bloques defectuosos en un par de semanas, lo di por bueno y olvidé el asunto tras devolverlo a su bahía del NAS y ponerle un 2º SSD en RAID 1 por si acaso, porque se queda uno mosqueado con estas cosas.

Lo que no sé con certeza es cómo funciona esto de retirar bloques dañados, quién determina que falla, el S.O. o el propio FW del disco, ni cómo se quita del direccionamiento; por lo que recuerdo que hace tiempo leí, los discos tienen sectores de repuesto que sustituyen a los que se dañan, en teoría sustituyendo su direccionamiento, pero incluso así serán limitados, y se sustituyan o sólo se marquen, la cosa es que en el proceso afectará a los archivos que usen estos bloques, si los hay.

Ese primer SSD que tenía 6 bloques retirados es el que ahora tiene 26, y el nuevo que puse, lógicamente con 0 defectuosos ahora tiene 5, y claro, si ya lo primero fue extraño ahora que los dos SSD tengan estos datos SMART es preocupante, y apuntando todo a que efectivamente están cayendo sectores haciéndose un uso en escritura muy bajo, sin otros problemas y trabajando en temperaturas en torno a 31º, es por lo que sólo se me ocurre como causa lo del S.O. que tenga algún tipo de escritura cíclica continuada, que es en principio la forma habitual en que un bloque se daña en un SDD con poco uso y TDW alto (todavía al 100% que será en realidad 99’xxx).

Tampoco entiendo que caigan 31 bloques en 2 SDD, uno tras otro y no se reporte nada de nada, ni siquiera la recuperación de los ficheros eventualmente corrompidos restaurados en el RAID 1, y a pesar de que tengo programada semanalmente prueba SMART en ambos discos. Más inquietante resulta ver que en uno de los SDD se sobrepasaron los umbrales en esos 3 campos SMART y como si nada; vaya, que lo mismo hasta que el disco no esté hecho una ruína no saltará alguna notificación con la que poco ya se pueda hacer…

En fin, imagino que no soy el único con SSD de sistema en el NAS, a ver si los compañeros con esta configuración se animan a publicar el estado de esos campos SMART, que creo será útil también para quien piense incorporar SSD o ponerlos de sistema para acelerar el funcionamiento, o incluso simplemente por saberlo y en su caso trasladarlo a QNap para que corrijan el problema.


Saludos!

[Josus]

Muy buenos días,

¿En serio que nadie por aquí con SSD de sistema en el NAS?

Que alguien se anime a compartir si su SSD tiene bloques dañados y los valores de los campos SMART 1, 179 y 183.

En estos días me han vuelto a aumentar en el 2º SSD que tengo como RAID 1 del 1º, de sistema.

Buen fin de semana a todos!

[Josus]

Hola compañeros,

Ya pude solucionar el problema y quería compartir la información al respecto ya que nadie comentó nada ni sobre los problemas de sectores mal en SSD de sistema ni sobre cómo solventar el caos que provoca:

Sobre los sectores mal.

Finalmente el origen del problema no es de QNap, es decir, no se trata de que QTS machaque los SSD hasta provocar dañar sectores, sino que se debe a que los discos Samsung SSD 870 EVO fabricados en 2021 presentan este problema. No me han concretado lotes concretos a los que afecta ni si se extiende antes o después de 2021, pero son muy numerosos los casos y el fabricante ya cambió de chips de memoria NAND en este modelo (MZ-77E2T0) así como el firmware que lo gestiona.

Decir que Samsung no puso ninguna pega para atender la garantía de 5 años de estos discos, aunque en mi caso la solución fue más rápida acudiendo al vendedor al estar aún dentro de los 2 años de garantía que correspondía (ahora serían ya 3 con la nueva legislación).

Concretamente en mis dos discos afectados figuran serigrafiadas como fechas de fabricación 2021.04 y 2021.08, y los campos SMART que acaban mostrando valores anormales son los siguientes (en mensajes anteriores confundí el número del primero de ellos), que nombro según aparecen en QTS (ligeramente diferente en Samsung Magician):

   5 - Retired_Block_Count
   179 - Used_Rsvd_Blk_Cnt_Tot
   183 - Runtime_Bad_Block
   187 - Reported_Uncorrect_Error
   195 - ECC_On-The-Fly_Error

Los 3 primeros presentan el mismo valor correspondiente al número de bloques defectuosos, y los 2 últimos también aparecen con un valor común pero diferente a los anteriores.

Solución de problemas provocados.

He de decir que me sorprende y mucho lo mal que está resuelto el asunto por QNap, casi que resulta difícil hacerlo peor, y máxime cuando hablamos de un sistema de almacenamiento que se supone está orientado a la seguridad de los datos.

Pues bien, cuando el SSD detecta un sector malo lo sustituye por uno de repuesto quedando el disco en principio como nuevo, pero QTS ni se entera y lógicamente si contenía información afectará a la integridad del sistema de almacenamiento, lo que se traducirá en que fallarán las pruebas de bloques defectuosos y de estructura de ficheros.

QTS es incapaz de solucionar nada salvo indicar que si persiste el problema se cambie el disco, ¡Alucinante!, de manera que toca armarse de paciencia, dedicar tiempo y hacer a mano lo que no han hecho los desarrolladores de QNap.

En la mayoría de casos basta localizar los ficheros corruptos, tal vez sólo un par, y borrarlos para que las pruebas sean superadas y se puedan revertir las dificultades añadidas de QTS poniendo el sistema en sólo lectura, error, degradado, etc. Pero claro, para identificar esos ficheros habrá que copiar todo en otro lugar e ir anotando los nombres de los ficheros que fallen para luego buscarlos, ya que puede haber varios ficheros con igual nombre en carpetas diferentes, y proceder a eliminarlos, que puede que tampoco resulte fácil…

Si el número de sectores es mayor puede que afecte también a información relativa a las carpetas por lo que no bastará con eliminar los ficheros dañados sino que habrá que borrar las carpetas completas que los contengan. Imagino que en casos más graves lo mismo habrá que recurrir a borrarlo todo o formatear.

Ciertamente si nuestro SSD tiene bloques defectuosos, a pesar de que se hayan reemplazado por otros operativos, seguramente la mejor opción es cambiar el disco, pero conviene tener presente que el fabricante es quien determina los umbrales de los mencionados campos SMART para considerar que el disco es defectuoso en su conjunto y procede una sustitución por garantía, de manera que si por ejemplo aparecen 5 sectores mal lo darán por bueno, y podría darse el caso de que no aparezcan nuevos sectores defectuosos, de manera que no nos libraremos de sufrir las consecuencias de la mala programación de QNap.

QTS debería detectar cuándo se reemplazan bloques defectuosos del SSD, cosa que no hace a pesar de tenerle programada la prueba SMART, e igualmente debería identificar a qué afecta esos bloques, y no le costaría nada indicar los ficheros en cuestión, las carpetas en su caso o el volumen o volúmenes si así fuera.

En el caso de ficheros, ya que no se van a poder leer ya jamás, podría directamente eliminarlos y restablecer la integridad del sistema, dejando únicamente al usuario la reposición de los archivos desde backup, aunque igualmente podría ir un paso más allá y hacerlo directamente o preguntando cuando la versión de la copia de seguridad sea más antigua que los ficheros perdidos.

En fin, que vaya chapuza de seguridad nos proporciona QNap, o más bien vaya fantástica forma de fastidiar al usuario, que lleva a perder días completos haciendo pruebas de bloques y estructura de archivos que tardan horas para luego sencillamente informar de que no pudieron completarse…

No sé si en otras marcas de NAS ocurre lo mismo pues en las que pude probar no empleaba SSD, pero desde luego vaya un clamoroso SUSPENSO para QNap en materia de seguridad de los datos en sus dispositivos con QTS y SSD. Y con Samsung, aunque muy mal que no se advierta del problema y se sustituyan directamente todos los discos de los lotes afectados, al menos parece que lo ha solucionado con cierta celeridad y he de decir que no he tenido la menor incidencia de este tipo en otros SSD, incluyendo uno comprado en 2015, tal vez más antiguo pues no figura serigrafiada la fecha de fabricación, y que ha aguantado de todo y ahí sigue sin un solo sector defectuoso.

Espero que esta información pueda ser de utilidad a alguien y ojalá QNap se ponga las pilas porque de seguir así no será esta la marca a la que confíe mis datos ni la que recomiende a nadie.


Un saludo a todos.