J’ai configuré le spindown mais mes disques ne se mettent jamais en veille, pourquoi ?

Le timer de standby ATA se réarme à la moindre commande vers le disque — lecture comme écriture. Sur un NAS où l’OS (root, swap) partage les mêmes disques physiques que les données, la moindre écriture de métadonnées système réveille aussi la partition « data ». Tant qu’un processus touche le disque plus souvent que le délai de spindown, il ne s’endort jamais.

Une sonde de température qui lit les disques peut-elle empêcher le spindown ?

Oui, c’est un piège classique. Lire la température via smartctl est une commande ATA qui réarme le timer de standby. L’option -n standby évite de réveiller un disque déjà endormi, mais ne l’aide pas à s’endormir : si la sonde tourne toutes les 5 min et le spindown est à 30 min, le disque est réveillé avant d’y arriver. Espacez la sonde au-delà du délai de spindown.

laptop_mode et l’option de montage commit aident-ils au spindown ?

Ils diffèrent les écritures. vm.laptop_mode et vm.dirty_expire_centisecs retardent le writeback du page-cache ; l’option de montage ext4 commit= retarde les commits du journal jbd2 (indépendant de dirty_expire). Utile pour éliminer un goutte-à-goutte d’écritures, mais au prix d’une fenêtre de perte de données en cas de coupure — à réserver à un fs peu critique, pas au volume de données.

Faut-il vraiment chercher à endormir les disques d’un NAS ?

Pas forcément. Un disque qui tourne en continu accumule 0 cycle Start/Stop, donc aucune usure mécanique — seuls le bruit et la consommation sont en jeu. Pire, raccourcir le délai de spindown sur un système qui écrit régulièrement provoque des cycles d’arrêt/redémarrage répétés, eux réellement usants. La rotation continue est souvent le choix le plus sain.

Spindown impossible : le monitoring réveille vos disques

Objectif modeste : que les disques d’un NAS s’endorment après 30 min d’inactivité, pour le bruit et la conso. Le spindown est configuré proprement (hdparm -S, smartd avec -n standby). Et pourtant, les disques restent obstinément éveillés. L’enquête est plus subtile qu’il n’y paraît.

Règle n°1 : tout réarme le timer

Le timer de standby ATA se remet à zéro à la moindre commande vers le disque — pas seulement une écriture, une lecture aussi. Et sur ce NAS, root, swap et data vivent sur les mêmes disques physiques :

sda2 → md/root     sda3 → md/swap     sda4 → md/data

Conséquence : une écriture de métadonnées sur le fs root réveille aussi la partition « data ». Il suffit d’un processus qui touche root plus souvent que le délai de spindown pour tout maintenir éveillé.

Le premier coupable : une sonde qui écrit

Une mesure de 60 s montre le fs root qui reçoit ~24 Ko/min, alors que find ne voit… presque aucun fichier changé. Le vrai writer :

$ find / -xdev -mmin -3 -type f
/var/lib/nas-temp-monitor/state              ← état d'une sonde température
/var/lib/systemd/timers/stamp-nas-temp-monitor.timer

Un moniteur de température écrivait son état sur disque toutes les 5 min. Correction propre : état en RAM (/dev/shm) via un drop-in systemd, et Persistent=false sur le timer pour supprimer l’écriture du stamp. Écritures de la sonde : éliminées.

Différer ce qui reste

Il restait un goutte-à-goutte de métadonnées. On peut le repousser :

$ sysctl vm.laptop_mode=5
$ sysctl vm.dirty_expire_centisecs=210000     # page-cache différé
$ mount -o remount,commit=3600 /              # journal ext4 différé

⚠️ vm.dirty_expire ne concerne que le page-cache ; le journal jbd2 a son propre intervalle (commit=, 5 s par défaut). Il faut agir sur les deux. Résultat : 40 minutes sans la moindre écriture. Et pourtant…

Le paradoxe : la sonde qui empêche de dormir

…toujours pas de standby. Le compteur d’écritures est figé à zéro pendant 40 min, mais le disque reste éveillé. Ce ne sont donc plus les écritures — ce sont les lectures, invisibles dans ce compteur.

Le moniteur de température lit les disques via smartctl toutes les 5 min. Et une lecture SMART réarme le timer. L’option -n standby ne skippe qu’un disque déjà endormi — d’où un magnifique problème de l’œuf et de la poule :

Le disque ne peut pas s’endormir parce qu’on le lit sans cesse pour vérifier sa température. Mais on ne le lit que parce qu’il est réveillé.

Espacer la sonde au-delà du délai de spindown casse la boucle (le disque atteint 30 min, s’endort, et la sonde le skippe ensuite). Mais une écriture OS sporadique (~toutes les 20-40 min, un fsync d’un démon) suffit encore à réarmer par intermittence.

La vraie leçon

Sur un système où l’OS tourne 24/7 sur les mêmes disques que les données, le sommeil total est souvent inatteignable proprement — et vouloir le forcer en raccourcissant le délai est contre-productif : le disque s’endort puis se fait réveiller quelques minutes plus tard par une écriture, encore et encore. Ces cycles Start/Stop répétés, eux, usent vraiment. À l’inverse, un disque qui tourne en continu accumule 0 cycle = aucune usure mécanique.

Le gain réel n’était pas le spindown parfait : c’était de supprimer les écritures inutiles (l’état de la sonde en RAM), sans compromettre les données, et d’assumer la rotation continue.

Lessons learned

Le timer de standby se réarme sur toute I/O, lecture comprise — pas seulement les écritures.
root/swap/data sur les mêmes disques : une écriture système empêche la « data » de dormir.
Une sonde de température qui lit les disques empêche leur spindown. -n standby protège un disque endormi, mais ne l’aide pas à s’endormir. Espacez la sonde au-delà du délai de veille.
vm.dirty_expire ≠ commit= : le page-cache et le journal jbd2 ont chacun leur intervalle ; il faut différer les deux.
Un disque qui tourne en continu ne s’use pas (0 cycle Start/Stop). Le vrai risque, c’est le cyclage à répétition. Parfois, le bon réglage est de ne pas endormir du tout.