ZimaOS 1.6.0 corrigió un problema real del modo de espera de los discos, pero esta fuente demuestra que la solución no resolvió todas las carcasas USB. Las notas oficiales de la versión 1.6.0 de IceWhale indican que smartd había estado despertando intermitentemente los discos e impidiendo el reposo normal. Tras actualizar a la versión final 1.6.0, los usuarios con carcasas TerraMaster D5-300C y D4-320 siguieron informando de que sus discos duros USB no entraban en reposo.
La conclusión correcta es más específica: la versión 1.6.0 solucionó una fuente de activación del sistema; el comportamiento del puente o la carcasa USB seguía dependiendo de la configuración.
El modo de espera de los discos es una función real de ZimaOS
ZimaOS introdujo una opción de modo de espera de los discos en versiones anteriores. Los usuarios de la fuente no preguntaban si el modo de espera existía; informaban de que los discos conectados por USB lo ignoraban o no lograban mantenerlo.
ZimaOS 1.6.0 solucionó oficialmente el problema de smartd que despertaba los discos en reposo
Las notas oficiales de la versión 1.6.0 indican explícitamente que se solucionó el problema que impedía que los discos entraran en reposo normal porque smartd los despertaba intermitentemente.
Consulta la solución oficial para el modo de espera de los discos en la versión 1.6.0.
El autor original seguía sin lograrlo después de actualizar a la versión final 1.6.0
alexstamos actualizó de la versión beta a la versión final 1.6.0 e informó de que el problema persistía. Su TerraMaster D5-300C contenía tres discos miembros de RAID 5 más un disco independiente, y ninguno entraba en reposo.
Otro usuario de TerraMaster D4-320 reprodujo el mismo problema
jumpingflash dijo que el D4-320 se detenía correctamente en otros ordenadores, pero no con ZimaOS 1.6.0. Posteriormente, otro propietario de un D4-320 hizo la misma comparación con otras distribuciones de Linux.
Otros discos duros USB sí entraban en reposo con normalidad
isanto1306 informó de que tres discos duros USB WD entraban en reposo correctamente. Esta también es una prueba importante, porque evita afirmar lo contrario: que ZimaOS no puede detener los discos USB.
hd-idle fue una solución alternativa de la comunidad
El autor original dijo que consiguió que los discos entraran en reposo después de unos diez minutos experimentando con hd-idle. No publicaron un procedimiento completo y reproducible para instalar ZimaOS.
Otro usuario forzó el modo de espera con smartctl y un temporizador de systemd
ssimon publicó un script que se ejecutaba periódicamente smartctl -s standby,now contra los discos USB y lo programó mediante systemd.
Este es código de la comunidad, no la implementación oficial del modo de espera de IceWhale. Forzar el modo de espera cada pocos minutos también puede interferir con las cargas de trabajo activas si el script no comprueba primero la E/S.
No fuerces la suspensión de un disco ocupado.
- Confirma que no haya ninguna copia de seguridad ni migración en curso.
- Confirma que no haya ninguna reconstrucción ni depuración de RAID activa.
- Comprueba las aplicaciones de Docker y las tareas de indexación.
- Verifica que la carcasa sea compatible con el comando de espera.
No afirmes que existe una solución específica para D4-320 sin pruebas actuales
La versión actual de ZimaOS es más reciente que la 1.6.0, pero las notas públicas de la 1.7.1 no incluyen una solución específica para la suspensión de discos en TerraMaster D4-320/D5-300C. Vuelve a probar la versión estable actual y el firmware exacto de la carcasa antes de aplicar un temporizador antiguo.
El firmware del puente USB-SATA puede cambiar el comportamiento del modo de espera
Una carcasa USB de varias bahías no es idéntica, ni eléctrica ni lógicamente, a un disco SATA conectado directamente. El puente USB puede traducir, ignorar o reinterpretar los comandos ATA de espera, y algunas carcasas consultan los discos internamente.
Eso explica por qué el mismo disco duro puede entrar correctamente en suspensión cuando se conecta de otra forma, pero permanecer activo detrás de un puente DAS concreto.
Distingue entre «nunca entra en suspensión» y «entra en suspensión y luego se reactiva»
Un disco que nunca entra en espera apunta a comandos no compatibles, actividad de E/S constante o al comportamiento de la carcasa. Un disco que entra en suspensión y se reactiva cada 30–60 minutos apunta a consultas periódicas o a servicios como las comprobaciones de SMART o de almacenamiento.
La versión 1.6.0 smartd la solución aborda el segundo patrón, no todos los posibles casos del primero.
Mide el estado de espera sin activar el disco
Algunas consultas de estado pueden activar por sí mismas un disco en suspensión o informarse incorrectamente a través de un puente USB. Cuando sea posible, utiliza comprobaciones compatibles con la carcasa que no activen el disco y compara el comportamiento físico —ruido de giro, consumo eléctrico y temperatura— con el estado indicado por el software.
No conviertas la frecuencia de suspensión en una fórmula universal para la vida útil de las unidades
Es comprensible que los usuarios de las fuentes estuvieran preocupados por el consumo y el desgaste, pero afirmaciones como «los discos duros no durarán un año» no estaban respaldadas por pruebas sobre el estado de las unidades en el hilo. Los ciclos frecuentes de arranque y parada y el funcionamiento continuo las 24 horas tienen distintas ventajas y desventajas según el diseño de la unidad y la carga de trabajo.
Elige un intervalo de espera que se adapte a tu uso en lugar de forzar ciclos muy cortos simplemente para minimizar el tiempo de giro.
Preguntas frecuentes sobre la suspensión de discos duros USB
¿Solucionó ZimaOS 1.6.0 un error del modo de espera de los discos?
Sí. IceWhale solucionó el problema por el que smartd activaba intermitentemente los discos en suspensión.
¿Solucionó eso el problema en todas las carcasas USB de TerraMaster?
No. Varios usuarios de distintas fuentes siguieron informando que los discos no entraban en suspensión en el hardware D5-300C y D4-320 después de la versión final 1.6.0.
¿Eran soluciones oficiales los temporizadores de hd-idle y smartctl?
No. Eran soluciones alternativas de la comunidad y deben probarse cuidadosamente en la carcasa exacta.
