NAS RAIDZ1, complément : qui planifie vraiment scrub et trim

🌐 Aussi en: English · Deutsch · Español

Un court complément à l’article sur la construction du NAS RAIDZ1. L’aide-mémoire de cet article vous donnait zpool scrub storage comme une commande que vous pouvez lancer. Ce qu’il ne disait pas, c’est si quelque chose la lance à votre place – et, puisqu’un scrub n’a d’intérêt que si vous apprenez qu’il a trouvé quelque chose, si le système vous prévient le cas échéant. Les deux questions ont fini par avoir des réponses plus intéressantes que « oui, évidemment ».

Table of Contents

🔍 Scrub et trim, un paragraphe chacun

zpool scrub lit chaque bloc alloué du pool et le compare à sa somme de contrôle enregistrée. Une divergence – un bit qui a discrètement basculé quelque part sur le support physique – est reconstruite à partir de la parité RAIDZ et réécrite automatiquement. C’est tout le mécanisme qui rend ZFS immunisé contre le problème de corruption silencieuse (le fameux bit rot) auquel l’article d’origine consacrait plusieurs paragraphes : ce n’est pas que la corruption ne puisse pas arriver, c’est que le scrub transforme « une corruption que personne ne remarquera jamais » en « une corruption réparée avant que quiconque ne la remarque ». zpool trim est propre aux SSD. Il indique au firmware du disque quels blocs ZFS n’utilise plus (fichiers supprimés, données écrasées), pour que le SSD puisse effacer et préparer cet espace à l’avance au lieu de s’en occuper en catastrophe en pleine écriture. Négligez-le assez longtemps et les performances en écriture se dégradent sans bruit, à mesure que le disque manque de blocs pré-effacés – l’équivalent SSD de ne jamais sortir les poubelles et de se demander pourquoi on avance de plus en plus lentement dans la cuisine. Aucun des deux n’a d’intérêt en opération ponctuelle. Tout l’intérêt, c’est qu’ils tournent selon un planning.

📅 Qui appuie vraiment sur la détente ?

Je suis allé chercher la réponse au lieu de la supposer, et heureusement – l’endroit évident où regarder était le mauvais. Sous Debian, OpenZFS livre deux mécanismes de planification côte à côte, et un seul des deux faisait quoi que ce soit :

$ systemctl list-unit-files | grep zfs-scrub
zfs-scrub-monthly@.timer   disabled   enabled
zfs-scrub-weekly@.timer    disabled   enabled

Tous les deux désactivés. Si je m’étais arrêté là, la réponse honnête aurait été « non, rien ne le lance ». Mais zfsutils-linux dépose aussi un simple fichier cron, indépendant de ces timers, et celui-là est actif :

# /etc/cron.d/zfsutils-linux

# TRIM the first Sunday of every month.
24 0 1-7 * * root if [ $(date +\%w) -eq 0 ] && [ -x /usr/lib/zfs-linux/trim ]; then /usr/lib/zfs-linux/trim; fi

# Scrub the second Sunday of every month.
24 0 8-14 * * root if [ $(date +\%w) -eq 0 ] && [ -x /usr/lib/zfs-linux/scrub ]; then /usr/lib/zfs-linux/scrub; fi

Trim le premier dimanche, scrub le deuxième, tous deux à 00:24. Le script /usr/lib/zfs-linux/scrub qu’il appelle n’est pas non plus un zpool scrub $everything aveugle – il parcourt chaque pool, vérifie que son état est ONLINE et lit, pour chaque pool, une propriété définie par l’utilisateur nommée org.debian:periodic-scrub afin de décider s’il faut l’inclure :

$ zfs get -H -o value org.debian:periodic-scrub storage
-

- signifie non défini, ce que le script traite comme auto – le scrub a lieu. La passer à disable sur un pool donné exclurait ce pool sans toucher au job cron lui-même, ce qui est un levier plus propre que de modifier le script. Bref : deux systèmes de planification sont installés, seul l’ancien, basé sur cron, est activé, et la vraie décision par pool est une propriété, pas un nom de pool codé en dur. Rien de tout cela n’apparaît dans zpool status – il faut aller voir directement systemctl, /etc/cron.d et la propriété, et c’est exactement ce que j’ai fini par faire après qu’on m’a posé la question très légitime : « Est-ce que c’est vraiment automatisé, ou est-ce que tu m’as juste montré la commande manuelle ? » Mensuel est d’ailleurs le bon intervalle ici – ce sont des SSD, et un scrub hebdomadaire relève plutôt d’un réglage par défaut de l’ère des disques durs, qui sur de la flash ajoute surtout de l’usure sans bénéfice supplémentaire.

🔔 Est-ce que quelque chose vous prévient quand le scrub trouve un problème ?

C’est la partie qui m’a vraiment surpris. L’infrastructure pour vous avertir existe, est installée et tourne :

$ systemctl status zfs-zed
● zfs-zed.service - ZFS Event Daemon (zed)
     Active: active (running)

ZED (le ZFS Event Daemon) surveille les événements du pool – un scrub qui se termine, un resilver qui s’achève, un périphérique qui change d’état – et sa configuration nomme même un destinataire :

# /etc/zfs/zed.d/zed.rc
ZED_EMAIL_ADDR="root"
ZED_NOTIFY_INTERVAL_SECS=3600

Ça a l’air configuré. Et ça l’est – du point de vue de ZED lui-même. Mais le vrai mécanisme d’envoi, enfoui dans zed-functions.sh, n’a rien de glorieux :

: "${ZED_EMAIL_PROG:="mail"}"

zed_notify_email appelle un binaire qui s’appelle littéralement mail. Et sur cette machine :

$ which mail mailx msmtp
$

Rien. Pas de mailutils, pas de msmtp, aucun MTA d’aucune sorte installé. zpool create n’en tire jamais un comme dépendance, donc à moins de penser séparément à installer de quoi envoyer des mails, ZED a un destinataire et aucun moyen de le joindre. Le zedlet scrub_finish-notify.sh se déclencherait correctement au prochain scrub, construirait son message, le passerait à zed_notify_email, qui tenterait de lancer mail, obtiendrait « command not found » et échouerait – en silence, du point de vue de quiconque attend qu’un mail arrive vraiment. journalctl -u zed contiendra l’échec si vous allez le chercher. Rien ne vous le signalera si vous ne le faites pas. J’ai envie de m’attarder une seconde là-dessus, parce que c’est une chute vraiment réussie : tout le premier article parlait d’un système de fichiers qui refuse de laisser passer la corruption inaperçue – des sommes de contrôle au lieu d’une confiance aveugle, l’auto-réparation au lieu de la panne silencieuse. Et la couche posée par-dessus, dont le seul travail est de prévenir un humain quand cette mécanique fait son travail, échouait elle-même exactement de la manière silencieuse que ZFS a été conçu pour empêcher. La leçon du dernier article va plus loin que je ne le pensais : « avoir l’air OK en silence » est une propriété de l’infrastructure, pas seulement des disques.

🛠️ La correction, pour de vrai

Le trou n’est qu’un MTA manquant, pas une mauvaise configuration de ZED, donc la correction tient vraiment en trois étapes : installer un client mail, le faire pointer vers un relais, dire à ZED à qui écrire.

apt-get install -y msmtp msmtp-mta bsd-mailx

msmtp-mta installe msmtp sous forme de lien symbolique /usr/sbin/sendmail, et c’est précisément ce que mail/mailx – et donc ZED – appellent en coulisses. Ce homelab dispose déjà d’un relais sortant fonctionnel (Strato, utilisé ailleurs pour les notifications d’autres hôtes), j’ai donc fait pointer /etc/msmtprc vers le même compte au lieu de monter quelque chose de nouveau :

# /etc/msmtprc — root-owned, chmod 600 (it holds a password)
defaults
auth           on
tls            on
tls_starttls   on
logfile        /var/log/msmtp.log

account        homelab
host           smtp.strato.de
port           587
from           homelab@apt-upgrade.me
user           homelab@apt-upgrade.me
password       ██████████████████

account default : homelab

chown root:root /etc/msmtprc && chmod 600 /etc/msmtprc juste après – ce fichier contient un mot de passe en clair, et zfs-zed.service tourne de toute façon en root, donc « root uniquement » est à la fois correct et suffisant. Même traitement pour le fichier de log. Puis le vrai but de tout l’exercice – dire à ZED d’arrêter d’adresser ses mails à un compte root local que personne ne lira jamais, et de les envoyer là où je les verrai vraiment :

sed -i 's/^ZED_EMAIL_ADDR=.*/ZED_EMAIL_ADDR="you@example.com"/' /etc/zfs/zed.d/zed.rc
systemctl restart zfs-zed

Pas d’alias, pas de spool mail local, pas de règle de transfert à surveiller – ZED_EMAIL_ADDR est littéralement le destinataire avec lequel mail est appelé, donc le faire pointer directement vers une vraie boîte de réception est plus simple que de faire d’abord fonctionner la distribution locale pour empiler ensuite un transfert par-dessus.

✅ Fonctionnement confirmé

Plutôt que d’attendre le deuxième dimanche du mois pour savoir si tout cela marche vraiment, j’ai envoyé un test manuel par exactement le même chemin que ZED – mail, qui se résout en msmtp, qui s’authentifie auprès de Strato :

$ echo "This is a test message from the storage NAS (192.168.10.x) confirming that
msmtp + ZED mail delivery is now working via the Strato relay." | 
\
  mail -s "ZFS ZED delivery check - storage NAS" you@example.com

$ tail -1 /var/log/msmtp.log
host=smtp.strato.de tls=on auth=on user=homelab@apt-upgrade.me from=homelab@apt-upgrade.me
recipients=you@example.com mailsize=436 smtpstatus=250
smtpmsg='250 2.0.0 OK queued with id 990330282JJ9ENX' exitcode=EX_OK

smtpstatus=250 / exitcode=EX_OK signifie que Strato a accepté le message pour livraison – c’est le point de vue de msmtp. Côté boîte de réception, la confirmation est arrivée quelques secondes plus tard :

From:    homelab@apt-upgrade.me
To:      you@example.com
Subject: ZFS ZED delivery check - storage NAS
Date:    Wed, 2 Sep 2026 21:19

This is a test message from the storage NAS (192.168.10.x) confirming that
msmtp + ZED mail delivery is now working via the Strato relay.

De bout en bout, du relais à la boîte de réception, en à peu près le temps qu’il faut pour lire la ligne de log. Toute la correction est vérifiée – pas un « ça devrait marcher maintenant », mais un vrai e-mail vraiment arrivé. Un petit détail, mais qui mérite d’être dit clairement : la vraie correction ici n’est pas « installer msmtp ». C’est de remarquer qu’un composant dont le seul rôle est de donner l’alerte peut tomber en panne aussi silencieusement que ce qu’il est censé surveiller – et que la seule façon de savoir qu’il fonctionne vraiment, c’est de le déclencher et de vérifier, pas de lire la configuration et de supposer.