Si les disques durs internes d’un boîtier USB tel que le TerraMaster D4-320 ne passent jamais en veille sur ZimaOS, distinguez l’ancien bug de réveil de smartd du comportement de mise en veille USB-SATA propre au boîtier. ZimaOS 1.6.0 a corrigé le réveil périodique des disques par smartd, mais plusieurs utilisateurs ont néanmoins signalé que certains modèles de DAS USB continuaient de tourner, même sous la version 1.6.0.
Le diagnostic actuel est donc spécifique au boîtier : vérifiez si le pont USB relaie les commandes ATA de mise en veille, si les disques peuvent passer manuellement en veille et si ZimaOS ou un autre processus les réveille immédiatement. Ne partez pas du principe qu’un conteneur Docker hd-idle constitue une solution universelle.
Mettez d’abord ZimaOS à jour au-delà du bug de réveil de smartd
ZimaOS 1.6.0 a officiellement corrigé le problème par lequel smartd réveillait intermittence les disques et empêchait leur mise en veille normale.
Les notes de version de ZimaOS 1.6.0 actuelles doivent servir de référence pour votre version.
Pourquoi les boîtiers USB se comportent différemment du SATA direct
Un DAS intègre un contrôleur pont USB-SATA entre Linux et chaque disque. Certains ponts relaient correctement les commandes de gestion de l’alimentation ATA ; d’autres les filtrent ou les traduisent différemment. Les boîtiers à plusieurs baies ajoutent une couche supplémentaire de micrologiciel et peuvent présenter les disques de manière inhabituelle.
Étape 1 : confirmez que chaque disque est exposé individuellement
lsblk -o NAME,MODEL,SERIAL,TRAN
lsusbSi tous les disques apparaissent individuellement comme des périphériques de bloc connectés en USB, notez leurs identifiants stables avant de tester une commande de mise en veille.
Étape 2 : testez des vérifications d’état qui ne réveillent pas les disques
Lorsque le pont prend en charge le relais SAT, une commande telle que :
smartctl -d sat -n standby /dev/sdXpeut vérifier si le disque est déjà en veille sans le réveiller délibérément. Tous les ponts ne prennent pas en charge le même mode -d.
Étape 3 : testez prudemment la mise en veille manuelle
Si cette fonction est prise en charge, utilisez la méthode de mise en veille documentée par le fabricant du disque ou du boîtier, ou un outil Linux reconnu comme compatible avec ce pont. Une commande de mise en veille manuelle qui réussit une fois est plus probante que des modifications répétées du délai dans l’interface graphique.
Si le disque passe en veille puis se réveille immédiatement, un autre processus y accède. S’il refuse totalement de se mettre en veille, la compatibilité du pont est probablement en cause.
Pourquoi hd-idle est problématique dans Docker
hd-idle nécessite un accès direct aux périphériques de bloc et doit fonctionner avec un hôte qui monte et utilise activement ces disques. La transmission de disques bruts à un conteneur privilégié réduit l’isolation et peut devenir fragile lorsque les noms des périphériques changent.
Lorsqu’une solution native actuelle de ZimaOS est disponible, utilisez-la plutôt que de créer un conteneur permanent contrôlant les périphériques bruts uniquement pour gérer la mise en veille.
Les solutions de la communauté ne constituent pas une prise en charge native
Un utilisateur du D4-320 a créé un minuteur systemd qui exécutait périodiquement smartctl -s standby,now. Cette méthode peut servir de solution de contournement, mais forcer la mise en veille avec un minuteur sans vérifier les entrées-sorties actives est risqué. Une sauvegarde, une opération de vérification, un téléchargement ou une copie de fichiers ne doit jamais être interrompu simplement parce que cinq minutes se sont écoulées.
Vérifiez le micrologiciel du boîtier et ses fonctions natives de gestion de l’alimentation
Si le même D4-320 se met correctement en veille sous Windows ou macOS, mais pas sous Linux, vérifiez si ces systèmes d’exploitation utilisent des commandes USB ou des utilitaires propres au fabricant. ZimaOS ne peut pas toujours reproduire le comportement propriétaire d’un boîtier au moyen de commandes ATA génériques de gestion de l’alimentation.
Quand le SATA direct constitue un meilleur choix
Si la faible consommation et une mise en veille prévisible des disques sont importantes, le SATA direct expose généralement les commandes de gestion de l’alimentation des disques de manière plus transparente qu’un pont USB à plusieurs baies.
Le guide de dépannage du stockage propose une structure de diagnostic plus sûre.
FAQ
ZimaOS 1.6.0 a-t-il corrigé tous les problèmes de mise en veille des disques ?
Non. Cette version a corrigé un problème spécifique de réveil par smartd. La compatibilité du pont USB peut toujours empêcher ou perturber la mise en veille de certains boîtiers.
Pourquoi mon TerraMaster se met-il en veille sous Windows, mais pas sous ZimaOS ?
Le boîtier peut dépendre d’un comportement de gestion de l’alimentation propre au pont ou au fabricant, qui diffère sous Linux.
Dois-je exécuter hd-idle dans Docker ?
C’est possible avec un accès aux périphériques bruts, mais cela ajoute une complexité liée aux privilèges et au mappage des périphériques. Ce n’est pas le premier choix le plus propre.
Est-il sûr de forcer la mise en veille toutes les quelques minutes ?
Uniquement si vous pouvez garantir que le disque est inactif. Un minuteur aveugle peut entrer en conflit avec des écritures actives, des sauvegardes, des opérations de vérification ou un accès multimédia.
