Esta fuente es más sólida que una queja genérica de «mis discos nunca entran en suspensión», porque IceWhale respondió con un plan de solución del producto y un método de diagnóstico. Los seis discos duros RAID5 permanecían activos incluso después de detener las aplicaciones de Docker, por lo que la investigación se centró en los servicios de almacenamiento y estado de ZimaOS, así como en una posible actividad a nivel del kernel.
ZimaOS 1.3.2 redujo posteriormente las consultas innecesarias a los discos y mejoró el comportamiento del modo de espera. Mucho después, ZimaOS 1.6.0 solucionó otro problema específico por el que smartd despertaba intermitentemente los discos en reposo. Estas versiones resuelven fuentes de activación conocidas, pero un disco actual que todavía permanece activo podría estar siendo accedido por otra aplicación, una copia de seguridad, un indexador, una tarea del sistema de archivos, un puente USB u otro servicio del kernel.
IceWhale modificó la consulta de almacenamiento en ZimaOS 1.3.2
orca-zhang describió tres optimizaciones específicas previstas para la versión 1.3.2:
- una lógica de comprobación del estado más sencilla;
- actualizar la caché de datos del disco solo cuando se detecte un cambio en el disco;
- dejar de intentar obtener información como la temperatura o el tiempo de funcionamiento de un disco que ya está en modo de espera.
El motivo es importante: algunos discos duros o controladores no pueden responder a esas consultas desde la caché, por lo que solicitar datos de estado despierta el disco físico.
Las notas de la versión 1.3.2 resumen este trabajo como una reducción de la actividad innecesaria de lectura y escritura, además de una mejora del modo de espera de los discos.
IceWhale proporcionó una consulta para identificar procesos con acceso
La respuesta oficial de la fuente sugirió identificar los procesos que tienen abierto actualmente un sistema de archivos o dispositivo:
for pid in $(fuser -m <device_path> 2>/dev/null); do
ps -p $pid -o comm=
done | uniqSustituye <device_path> por la ruta real del disco o del almacenamiento montado. Esto es un diagnóstico y no una acción destructiva.
IceWhale también sugirió detener temporalmente los servicios de almacenamiento y archivos
Para solucionar el problema, la fuente sugirió probar el modo de espera después de detener:
systemctl stop zimaos-local-storage
systemctl stop icewhale-filesIceWhale advirtió que algunas funciones de Ajustes y Archivos dejarían de funcionar mientras estos servicios estuvieran detenidos. Utiliza este procedimiento únicamente como diagnóstico controlado y, después, reinicia los servicios o reinicia el sistema.
ZimaOS 1.6.0 solucionó otra fuente de activación conocida
El registro de cambios oficial de la versión 1.6.0 añadió posteriormente otra solución independiente: los discos no podían entrar en suspensión normal porque el servicio smartd los despertaba intermitentemente.
Consulta la solución oficial para el modo de espera relacionada con smartd.
Mover AppData a NVMe no garantiza que los discos duros permanezcan inactivos
El usuario de la fuente ya había migrado las bases de datos de Docker a NVMe. Aun así, los discos duros pueden ser utilizados por el escaneo de archivos multimedia, Backup, las miniaturas, los clientes SMB, las comprobaciones SMART, las tareas de RAID o paridad, la indexación de Archivos u otro proceso que mantenga abierta una ruta.
Utiliza pruebas reales de acceso en lugar de suponer que «todas las aplicaciones están en NVMe» significa que el conjunto RAID no realiza ninguna operación de E/S.
RAID5 puede generar actividad en segundo plano por sí mismo
Las comprobaciones de paridad, las reconstrucciones, las operaciones de limpieza, la actividad de metadatos del sistema de archivos y la supervisión pueden acceder legítimamente a todos los discos miembros. Confirma que el RAID no esté realizando una operación de mantenimiento prolongada antes de diagnosticar el modo de espera.
Debes probar el ZimaOS actual antes de aplicar soluciones antiguas relacionadas con servicios
La versión actual de ZimaOS es la 1.7.1 e incluye años de cambios en la gestión del almacenamiento posteriores a este informe de enero de 2025. Primero reproduce el problema en la versión actual y, después, identifica la fuente de activación. No desactives permanentemente los servicios de estado o almacenamiento solo para forzar la detención de los discos.
Preguntas frecuentes sobre el modo de espera de los discos
¿IceWhale reconoció el problema del modo de espera en la fuente?
Sí. El personal indicó que estaba investigándolo y documentó las optimizaciones de la versión 1.3.2.
¿Comprobar la temperatura o el estado de una unidad puede despertar algunos discos?
Sí. IceWhale indicó específicamente que algunos discos sin información almacenada en caché podían despertarse al ser consultados.
¿Se identificó posteriormente smartd como otra fuente de activación?
Sí. ZimaOS 1.6.0 solucionó explícitamente los despertares intermitentes causados por smartd que impedían la suspensión normal.
