Si los discos duros dentro de una carcasa USB como la TerraMaster D4-320 nunca entran en suspensión en ZimaOS, separa el antiguo error de activación de smartd del comportamiento propio de espera de USB a SATA de la carcasa. ZimaOS 1.6.0 corrigió la activación periódica de los discos por parte de smartd, pero varios usuarios siguieron informando que determinados modelos de DAS USB permanecían girando incluso con la versión 1.6.0.
Esto significa que el diagnóstico actual es específico de la carcasa: demuestra si el puente USB reenvía los comandos ATA de espera, si los discos pueden entrar manualmente en espera y si ZimaOS u otro proceso los reactiva de inmediato. No des por hecho que un contenedor Dockerizado de hd-idle sea una solución universal.
Actualiza primero para superar el error de activación de smartd
ZimaOS 1.6.0 corrigió oficialmente el problema por el que smartd activaba los discos de forma intermitente e impedía la suspensión normal.
Las notas de la versión de ZimaOS 1.6.0 actuales deben ser tu referencia de versión.
Por qué las carcasas USB se comportan de forma diferente al SATA directo
Un DAS contiene un controlador puente USB a SATA entre Linux y cada disco. Algunos puentes reenvían correctamente los comandos de gestión de energía ATA; otros los filtran o traducen de forma diferente. Las carcasas de varias bahías añaden otra capa de firmware y pueden presentar los discos de maneras inusuales.
Paso 1: Confirma que cada disco se expone individualmente
lsblk -o NAME,MODEL,SERIAL,TRAN
lsusb
Si todos los discos aparecen individualmente como dispositivos de bloques conectados por USB, anota sus identificadores estables antes de probar cualquier comando de espera.
Paso 2: Prueba comprobaciones de estado que no reactiven los discos
Cuando el puente admita el paso directo SAT, un comando como:
smartctl -d sat -n standby /dev/sdX
puede comprobar si el disco ya está dormido sin reactivarlo deliberadamente. No todos los puentes admiten el mismo modo -d.
Paso 3: Prueba cuidadosamente la espera manual
Si es compatible, utiliza el método de espera documentado por el fabricante del disco o de la carcasa, o una herramienta de Linux conocida por funcionar con ese puente. Un comando de espera manual que funciona una vez demuestra más que cambiar repetidamente el temporizador de la interfaz gráfica.
Si el disco entra en suspensión y se reactiva de inmediato, otro proceso está accediendo a él. Si se niega a entrar en suspensión, la compatibilidad del puente es el principal sospechoso.
Por qué hd-idle en Docker resulta complicado
hd-idle necesita acceso directo a los dispositivos de bloques y debe coordinarse con un sistema anfitrión que monta y utiliza activamente esos discos. Pasar discos sin procesar a un contenedor privilegiado debilita el aislamiento y puede volverse frágil cuando cambien los nombres de los dispositivos.
Cuando esté disponible, utiliza una solución nativa y actual de ZimaOS en lugar de crear un contenedor permanente de control de dispositivos sin procesar únicamente para la espera.
Las soluciones alternativas de la comunidad no equivalen a la compatibilidad nativa
Un usuario de la D4-320 creó un temporizador de systemd que ejecutaba periódicamente smartctl -s standby,now. Puede funcionar como solución alternativa, pero forzar la espera mediante un temporizador sin comprobar la E/S activa es arriesgado. Una copia de seguridad, una operación de limpieza, una descarga o una copia de archivos nunca deben interrumpirse solo porque hayan transcurrido cinco minutos.
Comprueba el firmware de la carcasa y sus funciones nativas de energía
Si la misma D4-320 entra correctamente en suspensión en Windows o macOS, pero no en Linux, compara si esos sistemas operativos utilizan comandos o utilidades USB específicos del fabricante. ZimaOS no siempre puede replicar el comportamiento propietario de una carcasa mediante comandos ATA genéricos de gestión de energía.
Cuándo es mejor utilizar SATA directo
Si el bajo consumo y una espera predecible de los discos son importantes, el SATA directo suele exponer los comandos de gestión de energía de los discos de forma más transparente que un puente USB de varias bahías.
La guía de resolución de problemas de almacenamiento ofrece una estructura de diagnóstico más segura.
Preguntas frecuentes
¿ZimaOS 1.6.0 corrigió todos los problemas de suspensión de los discos?
No. Corrigió un problema específico de activación provocado por smartd. La compatibilidad del puente USB todavía puede impedir o interrumpir la espera en algunas carcasas.
¿Por qué mi TerraMaster entra en suspensión en Windows, pero no en ZimaOS?
Es posible que la carcasa dependa de un comportamiento de gestión de energía específico del puente o del fabricante que difiera en Linux.
¿Debería ejecutar hd-idle en Docker?
Es posible con acceso a dispositivos sin procesar, pero añade complejidad en cuanto a privilegios y asignación de dispositivos. No es la primera opción más limpia.
¿Es seguro forzar la espera cada pocos minutos?
Solo si puedes garantizar que el disco está inactivo. Un temporizador ciego puede entrar en conflicto con escrituras activas, copias de seguridad, operaciones de limpieza o acceso multimedia.
