Mise à niveau du zpool ZFS : quand mettre à niveau et quand attendre

décembre 15, 2025 • février 3, 2026 • Lecture : 31 min • Views: 11

Cet article vous a aidé ?

Mettre à niveau un pool ZFS est l’une de ces opérations qui ressemble à de la maintenance de routine — jusqu’à ce que vous vous rappeliez ce que c’est réellement : une porte sans retour. zpool upgrade ne « patch » pas votre pool. Il modifie l’ensemble des fonctionnalités sur disque qui définissent quels logiciels pourront lire ce pool à l’avenir. Si vous exploitez ZFS en production, ce n’est pas un détail. C’est l’essentiel.

Ce texte vise à vous aider à prendre cette décision comme un professionnel en astreinte. Nous couvrirons ce qui change réellement, ce que gagne l’option « attendre », comment les mises à niveau interagissent avec les pools de démarrage et la réplication, et comment exécuter les commandes avec suffisamment de contexte pour comprendre leur sortie. Vous aurez des listes de vérification réelles, des étapes de diagnostic rapides et les erreurs que les gens répètent parce que « ça fonctionnait en labo ».

Ce que fait vraiment `zpool upgrade`

OpenZFS moderne ne tourne plus autour de l’ancien « numéro de version du pool » comme avant. Il tourne autour des drapeaux de fonctionnalités. Un pool peut annoncer qu’il prend en charge certaines fonctionnalités sur disque (par exemple, spacemap_histogram ou extensible_dataset). Lorsqu’une fonctionnalité est activée sur un pool et réellement utilisée, les implémentations anciennes qui ne la comprennent pas peuvent refuser d’importer le pool — ou l’importer en lecture seule, ou se comporter de manière imprévisible selon l’époque et la plateforme.

zpool upgrade est l’outil qui active les nouvelles fonctionnalités sur un pool existant (et dans certains environnements met aussi à niveau l’ancienne version legacy). C’est généralement rapide, et c’est le piège : les conséquences sur disque peuvent être lentes et permanentes, car les fonctionnalités ne sont parfois réellement activées que lorsqu’une nouvelle métadonnée est écrite.

Voici une manière pratique d’y penser :

Mettre à niveau le logiciel ZFS (paquets, module noyau) est réversible : vous pouvez démarrer un ancien noyau ou réinstaller une ancienne version du paquet.
Mettre à niveau l’ensemble des fonctionnalités du pool est effectivement irréversible : une fois que des drapeaux de fonctionnalité sont actifs et utilisés, vous ne pouvez pas « rétrograder » le pool pour que l’ancien ZFS le comprenne à nouveau.

Une blague, parce qu’on en aura besoin : mettre à niveau un pool, c’est comme se faire tatouer le visage — techniquement réversible, mais « réversible » demande beaucoup de travail.

Qu’est-ce qui change sur le disque ?

Les drapeaux de fonctionnalités concernent les formats et la sémantique sur disque : comment les cartes d’espace sont stockées, quelles structures de métadonnées existent, comment les checksums sont suivis, quelles propriétés existent et si elles nécessitent de nouvelles structures, etc. Certaines fonctionnalités sont « activées » mais ne vous affectent pas tant que vous n’utilisez rien qui en dépend. D’autres sont effectivement utilisées immédiatement une fois activées parce que ZFS commence à écrire des métadonnées de façon nouvelle.

Nuance importante : zpool upgrade peut activer des fonctionnalités, mais des fonctionnalités peuvent aussi être activées en définissant des propriétés ou en créant des jeux de données qui les utilisent. Vous pouvez parfois mettre à niveau un pool mais l’importer quand même sur des systèmes plus anciens si les fonctionnalités sont activées mais pas encore actives — cependant c’est une stratégie fragile qui dépend du comportement des fonctionnalités. Traitez « activé » comme « considérez-vous prévenu ».

Faits intéressants et contexte historique

Les discussions sur le stockage s’émoussent quand on remet les événements dans la chronologie. Voici quelques faits concrets qui expliquent pourquoi zpool upgrade est encore un sujet en 2025 :

ZFS a commencé comme une fonctionnalité Solaris où la pile de stockage (ZFS + outils) était verticalement intégrée ; l’histoire « mettre à niveau le pool » supposait moins de permutations d’OS.
Les premiers ZFS utilisaient des numéros de version de pool (par ex. version 28) plutôt que de nombreux drapeaux de fonctionnalités indépendants ; on passait à une version et on acceptait tout ce qui était empaqueté dedans.
Les drapeaux de fonctionnalités sont apparus pour résoudre le problème du « verrouillage de version » : les vendeurs et les implémentations open-source pouvaient ajouter des fonctionnalités sans se battre autour d’un numéro de version monotone.
OpenZFS est devenu le centre de gravité pour de nombreuses plateformes, mais pas toutes les plateformes livrent le même niveau OpenZFS en même temps — en particulier les appliances et les distributions d’entreprise conservatrices.
Les pools de démarrage sont particuliers : votre pool de données peut s’importer correctement avec un nouvel ensemble de fonctionnalités, mais votre chargeur de démarrage peut ne pas être capable de lire le pool racine si vous activez certaines fonctionnalités là-bas.
Les drapeaux de fonctionnalités sont granulaires, pas anodins : certains n’affectent que des capacités optionnelles ; d’autres affectent des chemins d’allocation/métadonnées centraux et deviennent effectivement obligatoires une fois utilisés.
La réplication est votre machine à remonter le temps — jusqu’à ce qu’elle ne le soit plus : zfs send/receive peut franchir de nombreux changements, mais toutes les fonctionnalités sur disque ne sont pas représentables dans un stream comme on l’attend, et tous les récepteurs ne peuvent pas les accepter.
« Ça marche sur mon poste » est particulièrement dangereux avec ZFS parce que les laboratoires ont souvent une seule implémentation ZFS et une seule cible d’import, alors que la production possède des sites DR, des spare froids, des ISOs de récupération et des appliances vendeurs.

Quand mettre à niveau vs quand attendre

La plupart des gens encadrent cela comme « nouvelles fonctionnalités vs risque ». Ce n’est pas faux, mais c’est incomplet. Le vrai compromis est entre la flexibilité opérationnelle et la dette technique.

Bonnes raisons de mettre à niveau

Mettez à niveau l’ensemble des fonctionnalités du pool quand au moins une des conditions suivantes est vraie :

Vous avez besoin d’une fonctionnalité qui résout un problème réel (pas une curiosité). Exemple : activer des fonctionnalités qui améliorent la scalabilité des spacemaps si vous êtes proche du seuil de surcharge métadonnée, ou des fonctionnalités requises par un flux de réplication/gestion plus récent.
Vous vous êtes standardisé sur un niveau ZFS sur toutes les cibles d’import : chaque système susceptible d’importer le pool (production, DR, hôte de restauration de test, environnement « casser la vitre ») exécute un niveau ZFS qui prend en charge les mêmes fonctionnalités.
Vous avez une stratégie de migration qui ne repose pas sur l’import du pool ancien sur des systèmes plus anciens. En d’autres termes, vous avez accepté la porte sans retour et construit une rampe de l’autre côté (réplication, sauvegardes ou les deux).
Votre environnement de démarrage est validé si le pool est un pool racine. Si ce n’est pas un pool racine, la vie est plus simple, mais pas toujours.

Bonnes raisons d’attendre

Attendre n’est pas de la lâcheté ; c’est une stratégie. Vous devriez attendre lorsque :

Vous exploitez une flotte mixte et n’importe quel hôte pourrait être contraint d’importer le pool pendant un incident. Le jour où vous mettez à niveau est celui où vous supprimez un échappatoire dont vous ne connaissiez pas l’utilité.
Votre plan DR dépend d’environnements plus anciens (par exemple, une image de récupération fournie par un vendeur, un OS d’appliance avec ZFS figé, ou un hôte de récupération hors ligne qui est rarement mis à jour).
Vous n’avez pas besoin des fonctionnalités. « Le plus récent » n’est pas une exigence métier, et pour le stockage ce n’est rarement un impératif de performance par lui-même.
Vous manquez de temps pour répéter. Les mises à niveau de pool sont rapides ; l’analyse du rayon d’impact ne l’est pas.

Le compromis « attendre, mais avancer »

La meilleure posture opérationnelle que j’ai vue est : mettre à niveau le logiciel ZFS régulièrement, mais mettre à niveau les fonctionnalités du pool de manière délibérée et peu fréquente.

Cela vous apporte des corrections de bugs, des améliorations de performance dans le code et des correctifs de sécurité — sans brûler vos ponts de compatibilité. Vous pouvez exécuter un nouvel OpenZFS sur un ancien ensemble de fonctionnalités ; vous ne pouvez pas exécuter un ancien OpenZFS sur un nouvel ensemble de fonctionnalités.

Compatibilité : OS, chargeurs de démarrage et « flottes mixtes »

Si vous exécutez ZFS sur un seul serveur, la compatibilité est une note. Si vous exécutez ZFS dans toute une entreprise, la compatibilité est une politique.

Targets d’import mixtes (l’exigence cachée)

Dressez la liste de chaque système susceptible d’importer le pool :

Hôtes de production principaux
Paires HA de basculement
Hôtes de récupération DR
Machines d’expertise ou de récupération hors ligne
VM temporaires de « restauration » utilisées lors d’incidents
Environnements de support fournisseur (oui, ça arrive)

Si n’importe lequel d’entre eux ne peut pas importer après la mise à niveau, vous réduisez votre fenêtre de réponse aux incidents. En période calme, cela ressemble à une « architecture propre ». En crise, c’est « pourquoi le pool ne s’importe pas ? »

Les pools racine sont là où l’optimisme meurt

Mettre à niveau un pool de données est généralement simple. Mettre à niveau un pool racine est une négociation avec votre chargeur de démarrage, les outils initramfs et la façon dont votre distribution intègre ZFS.

Même lorsque le système en cours d’exécution peut importer le pool racine mis à niveau, vous devez tout de même prouver que votre chemin de démarrage peut :

Lire les métadonnées du pool
Lire le dataset contenant le kernel/initramfs (ou le chaîner)
Gérer les drapeaux de fonctionnalités que vous avez activés

Deuxième blague (et dernière) : le support de démarrage ZFS, c’est comme le « petit-déjeuner continental » d’un hôtel — techniquement il existe, mais ne planifiez pas toute votre journée dessus.

Réplication et drapeaux de fonctionnalités

zfs send/receive peut répliquer des jeux de données entre systèmes même lorsque les ensembles de fonctionnalités de pool diffèrent, mais il y a des mises en garde :

Si le côté récepteur ne prend pas en charge une fonctionnalité de dataset intégrée dans le flux, le receive échoue.
Certaines propriétés et comportements spéciaux de vdev ne sont pas « portables » comme les gens le supposent ; vous pouvez répliquer les données mais pas la forme opérationnelle du pool.
Même si la réplication de jeux de données fonctionne, les opérations au niveau du pool (comme importer l’ensemble de disques du pool sur un autre hôte) requièrent toujours la compatibilité des fonctionnalités du pool.

Tâches pratiques : commandes + interprétation

Voici les commandes que j’exécute réellement avant et après une décision de mise à niveau de pool. Pas de la théorie — juste ce qui vous dit ce que vous êtes sur le point de casser.

Task 1: See the current pool feature state

cr0x@server:~$ sudo zpool get -H -o name,property,value all tank | egrep 'feature@|version'
tank  version  5000
tank  feature@async_destroy  enabled
tank  feature@empty_bpobj  active
tank  feature@lz4_compress  active
tank  feature@spacemap_histogram  enabled
tank  feature@project_quota  disabled

Interprétation : Concentrez-vous sur les fonctionnalités qui sont active (déjà utilisées sur disque) et enabled (peuvent devenir actives). disabled est inerte. Si vous voyez encore un champ version legacy, votre plateforme peut le garder pour le reporting de compatibilité ; ce sont les drapeaux de fonctionnalités qui comptent.

Task 2: Ask ZFS what upgrades are available

cr0x@server:~$ sudo zpool upgrade
This system supports ZFS pool feature flags.

All pools are formatted using feature flags.

Some supported features are not enabled on the following pools.
Note that once a feature is enabled the pool may become incompatible with
software that does not support the feature. See zpool-features(7) for details.

POOL  FEATURE
tank  spacemap_histogram
tank  device_removal

Interprétation : C’est la vue « ce qui pourrait changer ». Si vous voyez une longue liste, ce n’est pas forcément mauvais — mais c’est un indice que vous êtes en retard et que vous devriez planifier un événement de mise à niveau unique et délibéré plutôt que la mort par mille fonctionnalités.

Task 3: Dry-run your compatibility list by checking ZFS versions across the fleet

cr0x@server:~$ for h in zfs-a zfs-b dr-restore; do
>   echo "== $h ==";
>   ssh $h "zfs version 2>/dev/null || modinfo zfs 2>/dev/null | head -n 5"
> done
== zfs-a ==
zfs-2.2.4-1
zfs-kmod-2.2.4-1
== zfs-b ==
zfs-2.2.2-1
zfs-kmod-2.2.2-1
== dr-restore ==
zfs-2.1.12-1
zfs-kmod-2.1.12-1

Interprétation : Si un hôte susceptible d’importer le pool est en retard, votre décision de mise à niveau est déjà prise : mettez d’abord à jour l’hôte ou ne mettez pas le pool à niveau. « On corrigera le DR plus tard » est la façon dont le DR devient fan fiction.

Task 4: Confirm pool health before touching anything

cr0x@server:~$ sudo zpool status -x
all pools are healthy

Interprétation : Ne mettez pas à niveau un pool déjà dégradé à moins que vous ne soyez en train de sacrifier l’optionnalité pour la stabilité (rare). Réparez d’abord les problèmes de disque ; sinon vous déboguerez deux catégories de problèmes en même temps.

Task 5: Check ongoing scrubs/resilvers and I/O saturation

cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: ONLINE
  scan: scrub in progress since Mon Dec 23 01:12:40 2025
        4.12T scanned at 1.05G/s, 2.31T issued at 604M/s, 8.20T total
        0B repaired, 28.17% done, 0 days 02:41:18 to go
config:
        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          raidz2-0  ONLINE       0     0     0
            sda     ONLINE       0     0     0
            sdb     ONLINE       0     0     0
            sdc     ONLINE       0     0     0
            sdd     ONLINE       0     0     0

Interprétation : Si un scrub/resilver est en cours, terminez-le d’abord sauf si vous avez une raison particulière de ne pas le faire. Aussi : les chiffres vous indiquent si le pool est déjà sous pression. Les mises à niveau de fonctionnalités sont généralement légères, mais votre fenêtre de changement ne devrait pas chevaucher l’opération de maintenance la plus lourde du pool.

Task 6: Snapshot and validate replication (your rollback substitute)

cr0x@server:~$ sudo zfs snapshot -r tank@pre_pool_upgrade
cr0x@server:~$ sudo zfs list -t snapshot -o name,creation -s creation | tail -n 5
tank@pre_pool_upgrade                     Mon Dec 23 03:22 2025
tank/home@pre_pool_upgrade                Mon Dec 23 03:22 2025
tank/vm@pre_pool_upgrade                  Mon Dec 23 03:22 2025

Interprétation : Les snapshots ne rétablissent pas les drapeaux de fonctionnalités du pool. Ils protègent l’état des données, pas l’état du format. Toujours obligatoire, parce que les mises à niveau et les fenêtres de changement sont quand les humains font des choses humaines.

Task 7: Test a send/receive to a known-good target

cr0x@server:~$ sudo zfs send -R tank@pre_pool_upgrade | ssh backup1 sudo zfs receive -uF backup/tank_test
cr0x@server:~$ ssh backup1 sudo zfs list -o name,used,available -r backup/tank_test | head
NAME                  USED  AVAIL
backup/tank_test      128K  40.2T
backup/tank_test/home  96K  40.2T

Interprétation : C’est un contrôle de confiance : vous pouvez toujours déplacer vos données ailleurs avec votre chaîne d’outils actuelle. Si cela échoue avant la mise à niveau, ça ne réussira pas magiquement après.

Task 8: Identify whether you’re dealing with a root pool

cr0x@server:~$ findmnt -no SOURCE /
tank/ROOT/default

Interprétation : Si / vit sur ZFS, vous êtes en territoire « chaîne de démarrage ». Cela n’interdit pas une mise à niveau ; cela exige une répétition et un plan de restauration qui inclut le démarrage d’un environnement alternatif.

Task 9: See what’s actually mounted and where (catch surprises)

cr0x@server:~$ sudo zfs mount | head -n 10
tank                             /tank
tank/home                        /home
tank/home/cr0x                   /home/cr0x
tank/vm                          /vm

Interprétation : Les pools accumulent des « bernacles ». Cette sortie vous rappelle quels services dépendent du pool et ce qui pourrait casser si vous redémarriez après une mise à niveau (surtout pour les pools racine).

Task 10: Run the actual upgrade (pool-wide) deliberately

cr0x@server:~$ sudo zpool upgrade tank
This pool is currently formatted using feature flags.
All supported features are enabled.

Interprétation : Vous n’aurez pas de feux d’artifice. Vous aurez une ligne de texte, et une nouvelle frontière de compatibilité. Suivez immédiatement avec des commandes de vérification, parce que « il a dit OK » n’est pas un système de supervision.

Task 11: Verify which features are now enabled/active

cr0x@server:~$ sudo zpool get -H -o property,value all tank | egrep '^feature@' | head -n 12
feature@async_destroy  enabled
feature@bookmarks  enabled
feature@embedded_data  active
feature@empty_bpobj  active
feature@enabled_txg  active
feature@extensible_dataset  active
feature@filesystem_limits  enabled
feature@hole_birth  active
feature@large_blocks  enabled
feature@lz4_compress  active
feature@spacemap_histogram  active
feature@userobj_accounting  enabled

Interprétation : Toute fonctionnalité désormais active est une revendication de compatibilité forte : importer ce pool sur un ancien ZFS risque d’échouer. Les fonctionnalités simplement enabled restent une préoccupation de compatibilité, car elles peuvent devenir actives plus tard précisément quand vous ne le souhaitez pas.

Task 12: Confirm nothing obvious regressed (latency + errors)

cr0x@server:~$ sudo zpool iostat -v tank 2 3
                                 capacity     operations     bandwidth
pool                           alloc   free   read  write   read  write
-----------------------------  -----  -----  -----  -----  -----  -----
tank                           3.21T  4.99T     72    190  9.10M  41.2M
  raidz2-0                      3.21T  4.99T     72    190  9.10M  41.2M
    sda                             -      -     18     49  2.30M  10.4M
    sdb                             -      -     17     47  2.20M  10.2M
    sdc                             -      -     18     48  2.30M  10.3M
    sdd                             -      -     19     46  2.30M  10.3M
-----------------------------  -----  -----  -----  -----  -----  -----

Interprétation : Les mises à niveau de pool changent rarement les statistiques I/O immédiates, mais c’est ici que vous attrapez « on a mis à niveau pendant le pic et maintenant tout est lent » avant que ça devienne un déluge de tickets. Surveillez la latence d’écriture et les erreurs de checksum en hausse.

Task 13: Export/import rehearsal (non-root pool) to validate import on the same host

cr0x@server:~$ sudo zpool export tank
cr0x@server:~$ sudo zpool import -d /dev/disk/by-id tank
cr0x@server:~$ sudo zpool status -x tank
pool 'tank' is healthy

Interprétation : Cela ne valide pas la compatibilité inter-hôtes, mais valide que le pool s’importe proprement et que vos chemins de périphériques sont cohérents. Ne faites pas cela sur un pool racine à moins d’apprécier reconstruire l’initramfs à 2h du matin.

Task 14: Capture a “forensics bundle” after upgrade (baseline)

cr0x@server:~$ sudo sh -c '{
>   date;
>   uname -a;
>   zfs version;
>   zpool status;
>   zpool get all tank;
>   zfs get -r all tank | head -n 50;
> } > /root/tank-post-upgrade-baseline.txt'

Interprétation : C’est ennuyeux. C’est aussi le fichier que vous utiliserez pour prouver ce qui a changé quand quelqu’un débarque trois semaines plus tard en disant « les performances sont différentes ».

Playbook de diagnostic rapide (chasse au goulot)

Voici la séquence « on a mis à niveau quelque chose et maintenant ça semble mauvais ». L’objectif n’est pas de trouver un métrique magique. L’objectif est de classifier rapidement le goulot : CPU, disque, métadonnées, pression mémoire, ou un changement de charge de travail qui a coïncidé avec votre fenêtre de changement.

1) Premier contrôle : santé du pool et erreurs

cr0x@server:~$ sudo zpool status -xv
all pools are healthy

Si vous voyez des erreurs : arrêtez l’analyse de performance et traitez cela comme un incident de fiabilité. Les erreurs de checksum après une mise à niveau sont généralement une coïncidence (câbles, HBA, secteur défectueux) mais la coïncidence casse quand même les données.

2) Deuxième contrôle : ZFS est-il bloqué sur I/O ou sur CPU ?

cr0x@server:~$ sudo zpool iostat -v tank 1 5

Interprétation : Si les disques sont saturés (ops/bande passante élevées sur les vdevs) et que la latence augmente, vous êtes lié par l’I/O. Si les disques semblent calmes mais que le système est lent, vous êtes probablement lié par le CPU, l’ARC/mémoire ou la contention sur des verrous.

3) Troisième contrôle : pression ARC et reclaim mémoire

cr0x@server:~$ cat /proc/spl/kstat/zfs/arcstats | egrep '^(size|c_max|c_min|hits|misses|memory_throttle_count) ' | head
size 4 1234567890
c_max 4 34359738368
c_min 4 4294967296
hits 4 987654321
misses 4 123456789
memory_throttle_count 4 0

Interprétation : Un taux de misses en hausse n’est pas automatiquement mauvais ; cela dépend de la charge. Mais si vous voyez du throttling mémoire, du churn de reclaim ou un ARC qui rétrécit de façon inattendue, vous avez peut‑être un problème au niveau hôte plutôt qu’au niveau pool.

4) Quatrième contrôle : latence au niveau bloc

cr0x@server:~$ iostat -x 1 5

Interprétation : Si await et svctm (ou équivalents modernes) grimpent, votre chemin disques/HBA est mécontent. Si la couche bloc semble correcte mais que ZFS est lent, suspectez les métadonnées ou le CPU.

5) Cinquième contrôle : identifier les datasets chauds

cr0x@server:~$ sudo zfs list -o name,used,refer,compressratio,recordsize,logbias -r tank | head -n 20

Interprétation : Les changements de caractéristiques de charge apparaissent souvent ici : un dataset VM avec un grand recordsize, un ratio de compression qui a changé après une mise à jour logicielle, ou un logbias qui ne correspond pas à la réalité.

6) Sixième contrôle : vérifier un scrub/resilver ou un trim oublié

cr0x@server:~$ sudo zpool status tank | sed -n '1,25p'

Interprétation : La cause la plus courante de « lenteur post-change » est une tâche en arrière-plan qui a démarré pendant la fenêtre. Les humains se rappellent la mise à niveau ; ZFS se rappelle qu’il doit encore scruber 60 % du pool.

Trois micro-récits du monde professionnel

Micro-récit 1 : L’incident causé par une mauvaise hypothèse

Ils avaient deux centres de données, une paire HA dans chacun, et un plan de réplication inter-site. L’équipe de stockage a fait la chose responsable : garder ZFS patché. Ils ont fait la chose irresponsable : supposer que « patché » impliquait « compatible ».

Un vendredi, un administrateur senior a mis à jour les paquets ZFS du site primaire et, en voyant une liste de fonctionnalités disponibles, a exécuté zpool upgrade pour « garder propre ». Le pool est revenu en ligne. Les charges étaient contentes. Personne n’a remarqué — parce que ZFS ne fait pas de fête quand vous activez de nouveaux formats sur disque.

Deux semaines plus tard, le site primaire a eu un incident réseau qui a forcé un basculement contrôlé. Les hôtes DR étaient toujours sur un niveau ZFS plus ancien à cause d’une politique de verrouillage du noyau par un vendeur. Quand l’équipe DR a essayé d’importer les disques répliqués pour un workflow de récupération spécifique, l’import du pool a échoué avec une erreur de fonctionnalité non supportée.

L’erreur n’était pas d’avoir mis à niveau. L’erreur était l’hypothèse que « on réplique, donc on est en sécurité ». La réplication protégeait les données, mais le runbook de récupération de cette charge dépendait de la portabilité de l’ensemble de disques. Ils ont fini par restaurer depuis la réplication au niveau jeu de données au lieu d’importer le pool, ce qui a fonctionné — mais a coûté des heures parce que les outils et l’automatisation attendaient la voie d’import.

Après l’incident, leur politique a changé : les mises à niveau des fonctionnalités de pool exigeaient une approbation de compatibilité de chaque cible d’import, plus un hôte « casser la vitre » mis à jour en premier et conservé comme plateforme de récupération. C’était ennuyeux, et cela a arrêté complètement cette classe de panne.

Micro-récit 2 : L’optimisation qui a mal tourné

Une autre entreprise avait un problème de performance : charges lourdes en métadonnées sur un pool qui avait grandi pendant des années. Quelqu’un a remarqué de nouveaux drapeaux de fonctionnalités dans une nouvelle version OpenZFS et a conclu — raisonnablement, mais incorrectement — qu’activer tout moderniserait le comportement d’allocation et améliorerait les performances.

Ils ont mis à niveau le pool pendant une fenêtre de changement. Les performances semblaient similaires juste après. Puis, au cours du mois suivant, ils ont repris des opérations normales : création et destruction de datasets, rotation de snapshots, rotation de sauvegardes. Progressivement, les temps d’import ont augmenté et quelques opérations de maintenance ont pris plus de temps. Rien n’était catastrophique. C’était pire que catastrophique : c’était ambigu.

La cause racine n’était pas « les drapeaux de fonctionnalités sont mauvais ». La cause racine était qu’ils ont confondu mise à niveau de pool et tuning de performance, puis ont aussi changé les modèles de charge au même trimestre. Dans le post-mortem, trois changements indépendants se sont chevauchés : un changement de politique de rétention de sauvegarde (plus de snapshots), une augmentation de densité VM (plus de petites I/O aléatoires), et une mise à niveau de pool qui a activé des fonctionnalités changeant le comportement des métadonnées.

Le retour de bâton était opérationnel : ils ne pouvaient pas prouver la causalité. Chaque équipe avait une histoire plausible. Il a fallu des semaines pour isoler, car ils n’avaient pas capturé de baseline et n’avaient pas mis en scène les changements.

La correction a été presque embarrassante : ils ont annulé la politique de rétention, déplacé quelques VMs, et les performances se sont normalisées. La mise à niveau du pool n’était pas le méchant ; le manque d’expériences contrôlées l’était. Lors de leur prochaine fenêtre ils ont remis à niveau à nouveau — cette fois avec une baseline, une seule variable modifiée et un indicateur de succès clair.

Micro-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une organisation de services financiers utilisait ZFS pour les répertoires personnels et les artefacts de build internes. Pas glamour. Très occupé. Leur équipe stockage avait une règle qui énervait tout le monde : chaque trimestre, ils réalisaient une répétition d’import DR sur un hôte mis en quarantaine. Même layout de pool, mêmes runbooks, même exercice « simuler la panique ». La répétition incluait la vérification que l’hôte DR pouvait importer les pools tels qu’ils existent aujourd’hui, pas tels que quelqu’un les se souvenait.

Quand le moment est venu d’adopter un OpenZFS plus récent, ils ont mis à jour les paquets sur toute la flotte d’abord, puis ont laissé les fonctionnalités du pool tranquilles pendant un mois. Pendant ce mois, ils ont exécuté la répétition DR deux fois : une fois sur l’ensemble de fonctionnalités ancien, une fois après avoir activé sélectivement un petit ensemble de fonctionnalités sur une copie de staging du pool.

Lors de la répétition numéro deux, leur environnement de démarrage n’a pas pu importer le pool racine sur une image de récupération plus ancienne qu’ils conservaient pour les urgences. Cette image de récupération n’était plus censée être utilisée, mais elle restait dans le classeur « casser la vitre » — parce que les entreprises sont des musées avec une masse salariale.

Parce qu’ils l’ont trouvé en répétition, la correction a été propre : mettre à jour l’image de récupération, valider à nouveau, puis planifier la mise à niveau des fonctionnalités du pool. Quand un vrai incident est arrivé des mois plus tard (une panne d’hôte nécessitant l’import des pools sur le matériel DR), la récupération s’est déroulée sans accroc. Personne n’a célébré, ce qui est le plus grand compliment pour une équipe stockage.

Erreurs courantes, symptômes et correctifs

Mistake 1: Treating `zpool upgrade` like a normal package upgrade

Symptôme : Après la mise à jour, un hôte ou environnement de récupération ancien ne peut plus importer le pool ; l’import échoue avec « unsupported feature(s). »

Correctif : Mettez à jour l’implémentation ZFS sur toutes les cibles d’import potentielles avant d’activer les fonctionnalités du pool. Si vous ne pouvez pas, ne mettez pas le pool à niveau. Si vous l’avez déjà fait, votre « correctif » pratique est la migration : répliquez les jeux de données vers un pool compatible ou reconstruisez l’hôte de récupération vers un ZFS compatible.

Mistake 2: Upgrading the root pool without proving the boot chain

Symptôme : Le système importe le pool à l’exécution, mais ne démarre pas après un reboot ; il tombe dans le shell initramfs ou ne trouve pas le dataset root.

Correctif : Validez le support du chargeur de démarrage + initramfs pour l’ensemble de fonctionnalités cible. Conservez un environnement de démarrage connu correct et testez un redémarrage en fenêtre de maintenance. Si possible, séparez le pool de démarrage du pool de données et mettez d’abord à niveau le pool de données de façon conservatrice.

Mistake 3: Assuming snapshots are a rollback for feature flags

Symptôme : Quelqu’un dit « on peut juste rollback au snapshot si ça tourne mal » lors de la revue de changement.

Correctif : Corrigez le modèle : les snapshots restaurent l’état des datasets, pas le format du pool. Le plan de retour arrière pour les fonctionnalités du pool est « restaurer sur un autre pool » (réplication/sauvegarde), pas « zfs rollback ».

Mistake 4: Upgrading during scrub/resilver or while the pool is degraded

Symptôme : La mise à niveau coïncide avec des resilvers plus lents, des timeouts ou des erreurs supplémentaires de périphérique. La corrélation crée de la confusion.

Correctif : Stabilisez d’abord. Terminez les resilvers/scrubs, corrigez le câblage/HBA, confirmez que zpool status -x est propre, puis mettez à niveau.

Mistake 5: Enabling features “because they’re there”

Symptôme : Des mois plus tard vous découvrez qu’une cible d’import précédemment compatible ne peut plus importer le pool parce qu’une fonctionnalité est devenue active suite à un changement de propriété ou d’usage d’un dataset.

Correctif : N’activez que les fonctionnalités que vous avez l’intention d’utiliser, dans la mesure du possible. Si le zpool upgrade de votre plateforme active tout par défaut, traitez cela comme une rupture de compatibilité délibérée et alignez la flotte d’abord.

Mistake 6: Not capturing a baseline

Symptôme : Rapports flous : « ça semble plus lent après la mise à niveau », sans métriques pré‑changement.

Correctif : Capturez une baseline minimale : zpool status, zpool get all, zpool iostat, statistiques ARC et métriques de latence applicatives. Conservez-la avec le ticket de changement.

Listes de contrôle / plan étape par étape

Checklist de décision : devons-nous mettre à niveau l’ensemble des fonctionnalités du pool ?

Dressez la liste de chaque hôte/environnement susceptible d’importer ce pool (y compris DR, VM de restauration, ISOs de récupération, appliances vendeurs).
Vérifiez les versions ZFS sur cette liste ; confirmez qu’elles prennent en charge les fonctionnalités que vous prévoyez d’activer.
Confirmez que le pool est sain (zpool status -x), sans resilver actif sauf si explicitement accepté.
Confirmez que les sauvegardes et/ou la réplication sont à jour et testées (un vrai receive, pas une croyance).
Si c’est un pool racine : confirmez le support du chargeur de démarrage/initramfs et répétez un redémarrage en maintenance.
Définissez des métriques de succès (compatibilité d’import, succès du reboot, bornes de latence, fonctionnement sans erreur).

Étape par étape : plan de mise à niveau conservateur en production

Mettre à niveau le logiciel d’abord, pas le pool. Déployez les mises à jour OpenZFS sur la flotte ; redémarrez si nécessaire ; conservez les pools sur les fonctionnalités existantes.
Exécuter une répétition de compatibilité. Choisissez une cible d’import non productive qui correspond à votre pire hôte de récupération ; confirmez qu’elle peut importer un pool représentatif.
Capturer la baseline. Conservez : zpool get all, zpool status, zpool iostat, statistiques ARC et un échantillon de latence de service.
Snapshotter les datasets. Ce n’est pas pour le rollback de format ; c’est pour le rollback humain et la sécurité des données.
Effectuer la mise à niveau. Lancez zpool upgrade POOL pendant une fenêtre de faible écriture si possible.
Vérifier fonctionnalités et santé. Confirmez l’état des fonctionnalités et que le pool reste sans erreur.
Répéter l’import. Pour les pools non racine, export/import sur le même hôte ; pour les pools racine, faire un reboot contrôlé.
Observer. Surveillez la latence I/O, les compteurs d’erreurs et la planification des scrubs. Ne déclarez pas victoire avant d’avoir traversé au moins un cycle normal de sauvegarde et de rotation de snapshots.

Étape par étape : si vous devez garder la compatibilité ascendante

Ne lancez pas zpool upgrade pour l’instant.
Mettez à jour les paquets OpenZFS partout ; vérifiez que l’ancien pool s’importe toujours sur tous les hôtes.
Créez un calendrier pour la mise à jour des systèmes en retard (appliances, noyaux figés, images DR).
Seulement après la mise à jour de la dernière cible d’import, planifiez la mise à niveau des fonctionnalités du pool.

FAQ

1) Faut‑il exécuter `zpool upgrade` après l’installation d’un ZFS plus récent ?

Non. Mettre à niveau le logiciel ne nécessite pas de mettre à niveau les fonctionnalités du pool. Beaucoup d’équipes exécutent du nouveau code OpenZFS sur d’anciens ensembles de fonctionnalités pendant des années pour préserver la compatibilité.

2) Puis‑je rétrograder un pool après `zpool upgrade` ?

Pas dans le sens où les gens l’entendent. Il n’y a pas de rollback supporté des drapeaux de fonctionnalités une fois qu’ils sont actifs sur disque. Votre chemin de rétrogradation est la migration : répliquer/restaurer dans un pool créé avec l’ancien ensemble de fonctionnalités sur un système qui le supporte.

3) Quelle est la différence entre fonctionnalités « enabled » et « active » ?

Enabled signifie que le pool est autorisé à utiliser la fonctionnalité ; elle peut devenir active lorsque ZFS écrit les métadonnées pertinentes. Active signifie que la fonctionnalité est déjà utilisée sur disque. Les fonctionnalités actives sont la contrainte de compatibilité la plus forte.

4) L’activation de nouvelles fonctionnalités améliorera‑t‑elle les performances ?

Parfois, indirectement, pour des charges spécifiques. Plus souvent, les changements de performance proviennent d’améliorations logicielles, d’un tuning ou d’un changement de charge. Traitez les mises à niveau de pool d’abord comme une décision de compatibilité, et comme une décision de performance seulement si vous pouvez lier une fonctionnalité à un bénéfice mesurable pour votre charge.

5) Dois‑je mettre à niveau un pool pour utiliser de nouvelles propriétés de dataset ?

Ça dépend. Certaines propriétés sont purement comportement runtime ; d’autres dépendent de fonctionnalités sur disque. Si une propriété requiert un drapeau de fonctionnalité, le pool doit le supporter et les systèmes récepteurs aussi.

6) Est‑il sûr de mettre à niveau un pool de données mais pas le pool de démarrage ?

Oui, et c’est souvent le meilleur compromis. Garder le pool de démarrage/racine conservateur réduit le risque de « ne peut pas démarrer », tout en permettant à votre pool de données d’adopter de nouvelles fonctionnalités une fois que vous avez aligné les cibles d’import.

7) Comment planifier le DR quand les mises à niveau de pool sont sans retour ?

Faites des cibles d’import DR des citoyens de première classe dans votre plan de mise à niveau : gardez‑les à jour, répétez les imports et validez que vos outils de restauration fonctionnent avec l’ensemble de fonctionnalités mis à niveau. Si le DR dépend de l’import physique des disques, la compatibilité est non négociable.

8) Si je réplique des datasets, les fonctionnalités du pool importent‑elles toujours ?

Oui. La réplication vous aide à déplacer les données, mais elle ne garantit pas que chaque récepteur puisse accepter chaque fonctionnalité. De plus, la réplication de datasets ne préserve pas la topologie ou le comportement au niveau du pool. Planifiez des tests de réplication avant de mettre à niveau.

9) Quelle est la façon la plus sûre d’expérimenter `zpool upgrade` ?

Cloner l’environnement : créez un pool de test avec un layout de vdev similaire, restaurez un jeu de datasets représentatif via zfs send, et répétez la mise à niveau et les étapes de récupération. L’essentiel de ce que vous testez est la compatibilité et le comportement opérationnel, pas si la commande se termine.

Conclusion

zpool upgrade n’est pas une simple étape de patch ; c’est une décision de compatibilité dont les conséquences survivent à l’hôte sur lequel vous l’exécutez. En production, le schéma gagnant est constant : mettez à jour le logiciel ZFS régulièrement, mettez à jour les fonctionnalités du pool seulement quand vous en avez une raison, une histoire de récupération répétée, et une flotte capable d’importer ce que vous êtes sur le point de créer.

Si vous ne retenez rien d’autre : traitez les mises à niveau des fonctionnalités du pool comme des migrations de schéma pour votre stockage — testées, graduées et soutenues par un véritable substitut de rollback (réplication/restauration), pas par de l’espoir. Cette approche ne rendra pas les mises à niveau excitantes. Elle les rendra oubliables, ce qui est exactement ce que vous voulez du stockage.