Cette source est plus solide qu’une plainte générique du type « mes disques ne se mettent jamais en veille », car IceWhale a répondu à la fois avec un plan de correction produit et une méthode de diagnostic. Les six disques durs RAID5 sont restés actifs même après l’arrêt des applications Docker ; l’enquête s’est donc orientée vers les services de stockage et d’état de santé de ZimaOS, ainsi que vers une éventuelle activité au niveau du noyau.
ZimaOS 1.3.2 a ensuite réduit les requêtes inutiles adressées aux disques et amélioré leur comportement en veille. Bien plus tard, ZimaOS 1.6.0 a corrigé un autre problème précis : smartd réveillait intermittement les disques en veille. Ces versions éliminent des sources de réveil connues, mais un disque qui reste actuellement actif peut encore être sollicité par une autre application, une sauvegarde, un indexeur, une tâche du système de fichiers, un pont USB ou un service du noyau.
IceWhale a modifié l’interrogation du stockage dans ZimaOS 1.3.2
orca-zhang a décrit trois optimisations précises prévues pour la version 1.3.2 :
- une logique de vérification de l’état de santé simplifiée ;
- l’actualisation du cache des données du disque uniquement lorsqu’une modification du disque est détectée ;
- ne plus tenter de récupérer des informations telles que la température ou le temps de fonctionnement auprès d’un disque déjà en veille.
La raison est importante : certains disques durs ou contrôleurs ne peuvent pas répondre à ces requêtes à partir du cache ; la demande de données d’état de santé réveille donc le disque physique.
Les notes de version actuelles de la version 1.3.2 résument cette évolution comme une réduction des activités de lecture/écriture inutiles et une amélioration de la mise en veille des disques.
IceWhale a fourni une commande pour interroger les processus accédant au stockage
La réponse officielle de la source recommandait d’identifier les processus qui ont actuellement un système de fichiers ou un périphérique ouvert :
for pid in $(fuser -m <device_path> 2>/dev/null); do
ps -p $pid -o comm=
done | uniqRemplacez <device_path> par le chemin réel du disque ou du stockage monté. Cette commande est destinée au diagnostic et n’est pas destructive.
IceWhale a également suggéré d’arrêter temporairement les services de stockage et de fichiers
Pour le dépannage, la source suggérait de tester la mise en veille après avoir arrêté les services suivants :
systemctl stop zimaos-local-storage
systemctl stop icewhale-filesIceWhale a averti que certaines fonctions des paramètres et de l’application Fichiers cesseraient de fonctionner pendant l’arrêt de ces services. Utilisez cette procédure uniquement comme test contrôlé, puis redémarrez les services ou la machine.
ZimaOS 1.6.0 a corrigé une autre source de réveil connue
Le journal des modifications officiel de la version 1.6.0 a ensuite ajouté une correction distincte : les disques ne pouvaient pas entrer en veille normale, car le service smartd les réveillait par intermittence.
Consultez la correction officielle de la mise en veille liée à smartd.
Déplacer AppData vers un disque NVMe ne garantit pas que les disques durs resteront inactifs
L’utilisateur à l’origine de la source avait déjà migré les bases de données Docker vers un disque NVMe. Les disques durs peuvent néanmoins être sollicités par l’analyse des médias, Backup, la génération de miniatures, des clients SMB, des vérifications SMART, des tâches RAID/de parité, l’indexation de Fichiers ou un processus qui maintient un chemin ouvert.
Appuyez-vous sur des preuves d’accès réelles plutôt que de supposer que « toutes les applications sont sur le NVMe » signifie que la baie n’effectue aucune E/S.
Le RAID5 peut générer sa propre activité en arrière-plan
Les vérifications de parité, les reconstructions, les opérations de nettoyage, l’activité sur les métadonnées du système de fichiers et la surveillance peuvent légitimement accéder à chaque disque membre. Vérifiez que le RAID n’effectue pas une opération de maintenance de longue durée avant de diagnostiquer la mise en veille.
Testez la version actuelle de ZimaOS avant d’appliquer d’anciennes solutions de contournement liées aux services
La version actuelle de ZimaOS est la 1.7.1 et comprend plusieurs années d’améliorations de la gestion du stockage depuis ce rapport de janvier 2025. Commencez par reproduire le problème sur la version actuelle, puis identifiez la source du réveil. Ne désactivez pas définitivement les services d’état de santé ou de stockage uniquement pour forcer l’arrêt des disques.
FAQ sur la mise en veille des disques
IceWhale a-t-il reconnu le problème de mise en veille dans la source ?
Oui. Le personnel a indiqué que le problème faisait l’objet d’une enquête et a documenté les optimisations de la version 1.3.2.
La vérification de la température ou de l’état de santé d’un disque peut-elle réveiller certains disques ?
Oui. IceWhale a indiqué précisément que certains disques dépourvus d’informations en cache pouvaient se réveiller lorsqu’ils étaient interrogés.
smartd a-t-il ensuite été identifié comme une autre source de réveil ?
Oui. ZimaOS 1.6.0 a explicitement corrigé les réveils intermittents provoqués par smartd, qui empêchaient la mise en veille normale.
