ZFS zfs list -o space : la vue qui explique « Où est-il passé ? »

décembre 22, 2025 • février 3, 2026 • Lecture : 27 min • Views: 7

Cet article vous a aidé ?

Tout administrateur ZFS finit par rencontrer le même fantôme : le pool qui est « soudainement » plein. Vous vérifiez le dataset évident, le répertoire évident, vous lancez même un du vite fait et vous vous sentez brièvement rassuré—jusqu’à ce que ZFS insiste calmement que le pool manque quand même d’espace. Ce n’est pas que ZFS fasse le malin. C’est ZFS qui vous dit que vous regardez au mauvais niveau.

zfs list -o space est ce niveau. C’est la vue « grand livre de la comptabilité d’espace » qui rapproche datasets, snapshots, reservations, refreservations et les types de consommations invisibles qui rendent les astreintes piquantes. En production, c’est la différence entre deviner et savoir—et entre supprimer la mauvaise chose et corriger la cause réelle.

Ce que `zfs list -o space` affiche réellement

La plupart des discussions « où est passé mon espace ? » avec ZFS arrivent parce que nous mélangeons deux perspectives valides mais distinctes :

Perspective système de fichiers (ce que rapporte du) : compte les données vivantes accessibles depuis un point de montage, ignore généralement les snapshots, omet souvent les métadonnées, et trompe fréquemment par omission lorsque la compression, les fichiers sparse ou les clones sont impliqués.
Perspective allocateur du pool (ce que ZFS doit gérer) : compte les blocs réellement alloués, plus l’espace effectivement retenu par les snapshots, plus l’espace réservé pour des promesses faites à d’autres datasets (reservations/refreservations), plus l’overhead.

zfs list -o space est une carte organisée de cette seconde perspective. Il décompose le « USED » en compartiments significatifs : données, snapshots, datasets enfants, reservations, refreservation, et métadonnées. Si vous n’avez jamais regardé que zfs list avec les colonnes par défaut, il vous manque les justificatifs.

Une remarque opérationnelle : le raccourci space n’est pas magique ; c’est un ensemble de colonnes nommé. Sur beaucoup de systèmes, il s’étend en quelque chose comme :

name, avail, used, usedbysnapshots, usedbydataset, usedbychildren, usedbyrefreservation, usedbyreservation

Selon l’implémentation et la version de ZFS, vous pouvez aussi voir usedbyrefquota ou devoir demander d’autres propriétés explicitement. Le principe reste : arrêtez de traiter USED comme un unique nombre.

Faits intéressants et contexte historique

Parce que ça aide de savoir quel type de bête vous administrez :

ZFS est né chez Sun Microsystems au début des années 2000 comme système de fichiers et gestionnaire de volumes combinés, ce qui explique pourquoi il peut faire des snapshots au niveau bloc sans une couche LVM séparée.
La conception originale de ZFS a mis en avant le checksum de bout en bout et le copy-on-write comme fonctionnalités de première classe, ce qui fait que « supprimer un fichier » ne signifie pas nécessairement « libérer de l’espace tout de suite » si des snapshots référencent encore les blocs.
Les datasets ZFS sont peu coûteux et conçus pour être nombreux ; le design suppose que vous allez découper le stockage par application/locataire et gérer le comportement par dataset via des propriétés.
La comptabilité d’espace dans ZFS distingue intentionnellement l’espace « référencé » de l’espace « utilisé » ; les clones et snapshots rendent la « propriété » non évidente, donc ZFS la trace.
Reservations et refreservations existent parce que le stockage « best effort » n’est pas acceptable dans de nombreuses charges d’entreprise ; ce sont des promesses appuyées par le comportement de l’allocateur.
Les zvols (dispositifs bloc fournis par ZFS) ont été introduits pour servir des images de VM et des consommateurs iSCSI/FC ; ils compliquent l’intuition d’espace parce que les outils système de fichiers ne voient pas à l’intérieur.
La compression a été ajoutée tôt et est devenue répandue car c’est l’une des rares optimisations de performance qui peut aussi réduire l’amplification d’écriture et améliorer l’efficacité du cache—quand les données se compressent.
La déduplication est célèbre pour être à la fois brillante et financièrement ruineuse quand elle est activée sans précautions ; beaucoup d’opérateurs ont une histoire « on a essayé la dédup une fois » et la traitent désormais comme un pistolet chargé.

Les colonnes d’espace, démystifiées

Commencez par le modèle mental : « qui détient les blocs ? »

Dans ZFS, les blocs sont partagés. Un snapshot n’est pas une copie ; c’est un signet. Quand vous modifiez un bloc après qu’un snapshot existe, ZFS écrit le nouveau bloc ailleurs (copy-on-write), et le snapshot continue de pointer sur l’ancien. Donc le snapshot « maintient » les anciens blocs en vie. C’est pourquoi supprimer des fichiers ne rend pas toujours de l’espace : vous avez supprimé la référence vivante, mais le snapshot référence encore les données.

zfs list -o space répond : combien de cet USED du dataset est détenu pour chaque raison ?

Interprétation colonne par colonne (les suspects habituels)

`USED`

L’espace total consommé par le dataset et tout ce qui est « en dessous » de lui, selon le contexte. Pour un dataset, USED inclut typiquement ses propres données et métadonnées, les snapshots (dans le sens d’espace unique attribuable), et les enfants, plus les impacts des reservations/refreservations. C’est côté allocateur. C’est ce qui fait remplir les pools.

`AVAIL`

Espace disponible pour ce dataset, en tenant compte de l’espace libre du pool et des quotas/reservations (et parfois de règles spéciales comme l’« slop space »). AVAIL est le nombre que votre application expérimente lors d’écritures.

`USEDBYDATASET`

Espace utilisé par le système de fichiers vivant du dataset (et les métadonnées) en excluant les snapshots et les enfants. Si ce chiffre est élevé, vos données vivantes sont volumineuses. S’il est faible mais que USED est énorme, votre fantôme est ailleurs.

`USEDBYSNAPSHOTS`

Espace retenu à cause des snapshots. Ce n’est pas « la taille des snapshots » au sens humain ; c’est l’espace unique qui ne peut pas être libéré parce que des snapshots le référencent. Un USEDBYSNAPSHOTS élevé signifie souvent « nous avons beaucoup de churn sur un dataset avec snapshots activés ». Pensez bases de données, images de VM, caches d’artefacts CI, ou tout ce qui réécrit de gros fichiers en place.

`USEDBYCHILDREN`

Espace utilisé par les datasets descendants et les volumes. Un parent peut sembler « plein » alors qu’il agit simplement comme conteneur. C’est le nombre qui vous empêche d’accuser le mauvais dataset.

`USEDBYRESERVATION`

Espace consommé à cause d’une reservation sur le dataset (ou, dans certaines implémentations, à cause d’une réservation affectant la comptabilité). Une reservation est une garantie : ce dataset pourra écrire cette quantité même si le pool devient serré.

`USEDBYREFRESERVATION`

Espace consommé à cause de refreservation. Contrairement à reservation, refreservation s’applique typiquement au dataset lui-même (pas à ses enfants) et est courant avec les zvols servant de stockage pour VMs. Cela peut être la « taxe invisible » qui fait qu’un pool semble plein alors que les données réelles ne le sont pas.

Blague n°1 (parce qu’on l’a mérité) : Les reservations sont comme des invitations à une réunion—une fois acceptées, elles bloquent votre agenda même si personne ne vient.

Propriétés associées qui complètent souvent le tableau

zfs list -o space est la lentille la plus rapide, mais vous voudrez souvent des propriétés adjacentes pour répondre au « pourquoi » :

referenced : combien d’espace les données vivantes de ce dataset référencent (sans compter les snapshots). Idéal pour « quelle est sa vraie taille ? »
logicalused / logicalreferenced : combien de données existeraient sans compression (et parfois avant copies/dedup). Idéal pour repérer les gains/pertes de compression.
compressratio : indice rapide pour savoir si la compression aide.
written : combien de données ont été écrites depuis le dernier snapshot (ou la création du dataset). Idéal pour analyser le churn.
volsize / volblocksize : pour le comportement des zvols.
copies, dedup : les interrupteurs « multiplient-ils les blocs ? ».

Manuel de diagnostic rapide

Ceci est la version « il est 03:17, le pool est à 92% et le pager chante ». L’objectif n’est pas d’être élégant ; c’est d’éviter d’empirer la situation.

1) Confirmez la vérité au niveau du pool

Première question : s’agit-il vraiment d’un problème d’espace ou d’un problème de fragmentation/allocation/métadonnées qui se présente comme un manque d’espace ?

cr0x@server:~$ zpool list
NAME   SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
tank  10.9T  9.80T  1.10T        -         -    43%    89%  1.00x  ONLINE  -

Interprétation : Un CAP proche de 90% est dangereux pour beaucoup de pools, surtout si FRAG est élevé et que la charge est fortement en écriture aléatoire. Si CAP est bas mais que AVAIL des datasets est bas, vous avez probablement affaire à des quotas/reservations.

2) Trouvez les plus gros coupables selon la comptabilité de l’allocateur

cr0x@server:~$ zfs list -o space -S used -r tank
NAME              AVAIL   USED  USEDSNAP  USEDDS  USEDCHILD  USEDREFRESERV  USEDRESERV
tank              1.10T  9.80T     3.20T    900G      5.70T            0B          0B
tank/vm           1.10T  6.10T     2.60T    400G      3.10T         80.0G          0B
tank/home         1.10T  2.90T     400G     2.30T     200G            0B          0B
tank/backup       1.10T  800G     200G      580G       20G            0B          0B

Interprétation : Vous avez maintenant une carte : le pool est plein en grande partie parce que tank/vm est volumineux ; à l’intérieur, ce sont les snapshots qui dominent (USEDSNAP), et il y a aussi un impact de refreservation.

3) Décidez quel levier est sûr : snapshots, reservations, ou données réelles

Par ordre de risque décroissant :

Émondez les snapshots selon la politique de rétention connue (surtout les automatiques). C’est généralement le rendement le plus élevé avec le plus faible rayon d’explosion.
Réduisez/enlevez les refreservations seulement si vous comprenez le consommateur (VM/zvol) et pouvez accepter le risque de surallocation.
Supprimez/déplacez les données vivantes seulement si vous êtes sûr que les snapshots ne sont pas les détenteurs réels et que vous ne cassez pas une attente métier.

4) Validez avec une autre vue de comptabilité avant d’agir

cr0x@server:~$ zfs get -o name,property,value -H used,referenced,logicalused,logicalreferenced,compressratio tank/vm
tank/vm	used	6.10T
tank/vm	referenced	410G
tank/vm	logicalused	7.90T
tank/vm	logicalreferenced	520G
tank/vm	compressratio	1.92x

Interprétation : Les données vivantes référencées ne sont qu’environ 410G ; le reste est snapshots/enfants/reservations. Si vous commencez à supprimer des fichiers VM « vivants », vous ne récupérerez pas grand-chose. Les snapshots sont le levier.

Tâches pratiques (commandes + interprétation)

Ce sont les mouvements quotidiens qui transforment -o space de trivia en économies et prévention d’incidents. Tous les exemples supposent le pool tank ; adaptez en conséquence.

Tâche 1 : Afficher la répartition d’espace d’un arbre de dataset

cr0x@server:~$ zfs list -o space -r tank
NAME        AVAIL   USED  USEDSNAP  USEDDS  USEDCHILD  USEDREFRESERV  USEDRESERV
tank        1.10T  9.80T     3.20T    900G      5.70T            0B          0B
tank/vm     1.10T  6.10T     2.60T    400G      3.10T         80.0G          0B
tank/home   1.10T  2.90T     400G     2.30T     200G            0B          0B

Interprétation : Utilisez ceci pour répondre « est-ce des snapshots, des enfants, ou le dataset lui-même ? » sans deviner.

Tâche 2 : Trier par espace détenu par les snapshots pour trouver les hotspots

cr0x@server:~$ zfs list -o name,usedbysnapshots,usedbydataset,usedbychildren -S usedbysnapshots -r tank
NAME        USEDSNAP  USEDDS  USEDCHILD
tank/vm       2.60T    400G     3.10T
tank/home      400G   2.30T      200G
tank/backup     200G    580G       20G

Interprétation : L’élagage des snapshots doit commencer par tank/vm. C’est aussi un indice pour revoir la fréquence des snapshots sur les datasets à fort churn.

Tâche 3 : Lister les snapshots et leur empreinte « used » (incrémentale)

cr0x@server:~$ zfs list -t snapshot -o name,used,referenced -S used -r tank/vm | head
NAME                              USED  REFERENCED
tank/vm@auto-2025-12-24-2300       48G        410G
tank/vm@auto-2025-12-24-2200       41G        409G
tank/vm@auto-2025-12-24-2100       39G        409G
tank/vm@weekly-2025-w51            22G        405G

Interprétation : Le USED d’un snapshot est l’espace additionnel consommé par rapport à l’état du snapshot précédent. Les grands nombres signifient un fort réécriture entre snapshots.

Tâche 4 : Voir rapidement le churn des snapshots depuis le dernier snapshot avec `written`

cr0x@server:~$ zfs get -o name,property,value -H written tank/vm
tank/vm	written	312G

Interprétation : Si written est énorme et que les snapshots sont fréquents, la croissance d’espace due aux snapshots sera massive. Les bases de données et images VM sont des coupables classiques.

Tâche 5 : Identifier les mines antipersonnel de refreservation (fréquent avec zvol-backed VM)

cr0x@server:~$ zfs list -o name,type,usedbyrefreservation,refreservation,volsize -r tank/vm
NAME              TYPE   USEDREFRESERV  REFRESERVATION  VOLSIZE
tank/vm           filesystem       80.0G             none        -
tank/vm/zvol0     volume          200G              200G      500G
tank/vm/zvol1     volume          300G              300G      300G

Interprétation : USEDREFRESERV vous dit combien d’espace est mis de côté. Si le pool est serré, ces blocs « mis de côté » peuvent faire la différence entre stabilité et panne.

Tâche 6 : Trouver les datasets où les quotas rendent AVAIL plus petit que le libre du pool

cr0x@server:~$ zfs get -o name,property,value -H quota,refquota,reservation,refreservation tank/home tank/vm
tank/home	quota	2.5T
tank/home	refquota	none
tank/home	reservation	none
tank/home	refreservation	none
tank/vm	quota	none
tank/vm	refquota	none
tank/vm	reservation	none
tank/vm	refreservation	none

Interprétation : Un quota peut faire qu’un dataset rapporte un AVAIL faible même lorsque le pool a de l’espace libre. C’est un problème de politique, pas du pool.

Tâche 7 : Comparer la vue système de fichiers vivante vs la vue allocateur ZFS (et détecter le décalage)

cr0x@server:~$ df -h /tank/vm
Filesystem      Size  Used Avail Use% Mounted on
tank/vm          11T  410G   11T   4% /tank/vm

cr0x@server:~$ zfs list -o name,used,referenced,usedbysnapshots tank/vm
NAME     USED  REFERENCED  USEDSNAP
tank/vm  6.10T       410G    2.60T

Interprétation : df rapporte ce qui est accessible dans le dataset vivant. ZFS rapporte ce que l’allocateur du pool doit conserver. Quand ils divergent massivement, les snapshots/clones/reservations sont généralement impliqués.

Tâche 8 : Attraper les clones qui retiennent de l’espace (le « j’ai supprimé l’image de base » surprise)

cr0x@server:~$ zfs list -o name,origin,used,referenced -r tank/vm
NAME                 ORIGIN                          USED  REFERENCED
tank/vm/base         -                               60G        60G
tank/vm/base@golden   -                               0B        60G
tank/vm/clone01       tank/vm/base@golden            80G        75G
tank/vm/clone02       tank/vm/base@golden            95G        88G

Interprétation : Les clones dépendent de leur snapshot d’origine. Supprimez l’origine sans précaution et vous serez bloqué—ou pire, vous planifierez mal la capacité parce que l’origine ne peut pas encore disparaître.

Tâche 9 : Vérifier l’efficacité de la compression quand logique et physique divergent

cr0x@server:~$ zfs get -o name,property,value -H logicalused,used,compressratio compression tank/home
tank/home	logicalused	3.40T
tank/home	used	2.90T
tank/home	compressratio	1.17x
tank/home	compression	lz4

Interprétation : La compression aide un peu, pas énormément. Si logicalused est bien plus grand que used, vous avez de vrais gains ; si c’est proche, ne comptez pas sur la compression pour la planification de capacité.

Tâche 10 : Trouver les datasets avec un metadata unexpectedly high (indirectement)

cr0x@server:~$ zfs list -o name,used,referenced,recordsize,special_small_blocks -r tank | head -n 10
NAME       USED  REFERENCED  RECORDSIZE  SPECIAL_SMALL_BLOCKS
tank       9.80T      900G     128K      0
tank/home  2.90T     2.30T     128K      0
tank/vm    6.10T      410G     128K      0

Interprétation : ZFS n’expose pas « metadata used » comme une simple propriété dans la sortie de zfs list, mais des écarts entre referenced et used, plus le type de charge (milliers de petits fichiers) et le réglage de vdev spécial peuvent fortement indiquer un problème. Si les métadonnées sont suspectes, confirmez au niveau du pool avec d’autres outils et considérez les stratégies de vdev spéciales avec précaution.

Tâche 11 : Utiliser `zfs list -p` pour des unités scriptables et non-humaines

cr0x@server:~$ zfs list -o space -p -r tank/vm | head -n 3
NAME	AVAIL	USED	USEDSNAP	USEDDS	USEDCHILD	USEDREFRESERV	USEDRESERV
tank/vm	1209462790553	6713214521344	2858730235904	429496729600	3420000000000	85899345920	0
tank/vm/zvol0	1209462790553	650000000000	0	650000000000	0	214748364800	0

Interprétation : Utilisez ceci quand vous construisez des alertes ou des rapports. Les unités lisibles sont pour les humains ; l’automatisation veut des entiers.

Tâche 12 : Vérifier ce qui serait libéré en supprimant un snapshot (mode réflexion, dry-run)

cr0x@server:~$ zfs list -t snapshot -o name,used -S used -r tank/vm | head -n 5
NAME                              USED
tank/vm@auto-2025-12-24-2300       48G
tank/vm@auto-2025-12-24-2200       41G
tank/vm@auto-2025-12-24-2100       39G
tank/vm@weekly-2025-w51            22G

Interprétation : Si vous supprimez tank/vm@auto-2025-12-24-2300, la borne supérieure de récupération immédiate est d’environ 48G—souvent moins si des blocs sont partagés avec des clones ou d’autres snapshots. Ce classement vous dit néanmoins quoi élaguer en priorité.

Tâche 13 : Montrer ce qui consomme un parent : dataset vs enfants

cr0x@server:~$ zfs list -o name,usedbydataset,usedbychildren,usedbysnapshots -r tank | grep -E 'tank$|tank/vm$|tank/home$'
tank       900G      5.70T     3.20T
tank/vm    400G      3.10T     2.60T
tank/home  2.30T      200G      400G

Interprétation : Idéal pour « quelle sous-arborescence est le problème ? » et pour éviter l’erreur classique de supprimer depuis le parent alors que l’enfant est le gros consommateur.

Tâche 14 : Confirmer que les reservations sont la raison d’un AVAIL faible

cr0x@server:~$ zfs get -o name,property,value -H reservation,refreservation tank/vm/zvol1
tank/vm/zvol1	reservation	none
tank/vm/zvol1	refreservation	300G

cr0x@server:~$ zfs list -o name,avail,usedbyrefreservation -r tank/vm | grep zvol1
tank/vm/zvol1  1209462790553  322122547200

Interprétation : Si le pool est serré, la refreservation est de l’espace « dépensé » du point de vue de l’allocateur. Si vous la supprimez, vous changez le contrat avec cette VM ou ce consommateur bloc.

Blague n°2 : La comptabilité d’espace, c’est comme un budget—tout va bien jusqu’à ce que vous catégorisiez vos dépenses.

Trois mini-histoires du monde de l’entreprise

1) Incident causé par une mauvaise hypothèse : « On a supprimé les données, donc l’espace doit être libre »

Le ticket est arrivé comme une alerte de capacité routinière : pool à 88%, en hausse. Le propriétaire du service jurait qu’aucun changement majeur n’avait eu lieu. L’admin a fait la première passe habituelle : du -sh sur le point de montage, a vu quelques centaines de gigaoctets, a haussé les épaules et a supposé que l’alerte était bruyante. Ce n’était pas le cas.

Deux heures plus tard, les écritures ont commencé à échouer de façon non évidente. Les applications n’étaient pas à court de disque à l’intérieur du système de fichiers (selon df), mais ZFS a commencé à retourner ENOSPC pendant les rafales. C’est le genre de défaillance qui fait perdre confiance au stockage—et ils n’avaient pas tort.

La cause racine : churn élevé sur un dataset d’images VM plus des snapshots agressifs. Un système CI générait de gros artefacts, les copiait dans des disques VM, puis les supprimait et recommençait. Le dataset vivant restait petit parce que le pipeline nettoyait après lui. Mais les snapshots retenaient les versions précédentes de ces blocs comme un musée qui refuse de désaffecter quoi que ce soit.

zfs list -o space a rendu la situation embarrassante en quelques secondes : USEDBYSNAPSHOTS eclipsait tout le reste. La solution n’était pas « supprimer plus de fichiers », mais « élaguer les snapshots pour coller à la réalité » et « arrêter de snapshotter les données à churn élevé à une cadence prévue pour les bases de données ». Ils ont ajusté la rétention, déplacé les workloads éphémères vers un dataset avec une politique de snapshot différente, et l’alerte a disparu définitivement.

La leçon est restée : les outils système de fichiers vous disent ce qui est visible ; ZFS vous dit ce qui est alloué. Si vous n’écoutez qu’un seul côté, vous prendrez la mauvaise décision sous pression.

2) Optimisation qui s’est retournée contre eux : « Augmentons la fréquence des snapshots pour améliorer le RPO »

Une équipe voulait des points de reprise plus serrés pour une flotte de services avec stockage VM. Ils ont augmenté la fréquence des snapshots d’horaires à toutes les cinq minutes et gardé la même fenêtre de rétention. Sur le papier, ça semblait être un gain gratuit : les snapshots sont « bon marché », non ?

En pratique, la charge réécrivait constamment de gros fichiers. Les images VM font ça : logs à l’intérieur des guests, pages de base de données, mises à jour de paquets, fichiers temporaires. Le copy-on-write signifiait que chaque snapshot gelait un ensemble de pointeurs de blocs, donc la réécriture suivante devait allouer de nouveaux blocs. Multipliez cela par douze snapshots par heure et tout d’un coup l’allocateur du pool faisait du cardio toute la journée.

Puis est venu l’effet de second ordre : réplication. Les incrémentaux sont devenus plus gros et plus fréquents. Le réseau et l’I/O côté récepteur ont augmenté. Les jobs de destruction de snapshot ont ralenti parce qu’il y avait plus de snapshots et plus de comptabilité de blocs à défaire. Les gens ont remarqué « ZFS est lent » et ont commencé à proposer des changements drastiques, y compris désactiver les checksums ailleurs et acheter des disques d’urgence. Spirale classique de mauvais diagnostic.

Ils ont reculé, mais pas en revenant strictement à une fréquence horaire. Ils ont scindé les datasets : les données critiques à faible churn ont eu des snapshots fréquents ; les caches et espaces disque VM à fort churn ont eu moins de snapshots. Ils ont aussi repensé la rétention : beaucoup de snapshots de cinq minutes pendant quelques heures, moins d’horaires pour la journée, puis des dailies. Le pool s’est stabilisé sans perdre le RPO réel requis.

La leçon opérationnelle : la fréquence des snapshots n’est pas une vertu morale. C’est une fonction de coût. zfs list -o space est comment vous voyez la facture.

3) Une pratique ennuyeuse mais correcte qui a sauvé la mise : « Réservez toujours une marge et mesurez par ZFS, pas par impressions »

Dans un environnement—grand, multi-tenant, beaucoup d’équipes internes—les incidents de stockage étaient rares. Pas parce que le hardware était magique, mais parce que l’équipe stockage était obstinée sur des règles ennuyeuses.

Premièrement : ils refusaient d’exploiter les pools « à chaud ». Les alertes de capacité se déclenchaient à des seuils qui semblaient conservateurs pour les équipes applicatives. Les réactions étaient prévisibles : « On a payé les disques ; pourquoi ne pas les utiliser ? » L’équipe stockage a répondu avec la réalité opérationnelle : le comportement de l’allocateur se dégrade, la pression de resilver augmente, et les suppressions d’urgence sont l’endroit où naissent les erreurs. Ils voulaient de la marge, pas du drame.

Deuxièmement : ils ont construit des tableaux de bord à partir de zfs list -o space -p, pas à partir de du ou des chiffres rapportés par les applications. Les tableaux affichaient explicitement USEDBYSNAPSHOTS et USEDBYREFRESERVATION, si bien que « croissance mystère » devenait « inadéquation de rétention des snapshots » ou « dérive des refreservations » au lieu d’un jeu de reproches.

Troisièmement : ils ont rendu la politique de snapshot explicite par classe de dataset et l’ont revue trimestriellement. Rien de fancy—juste assez pour attraper les cas où « le dataset cache CI a hérité de la politique de base de données ».

Quand une équipe d’app s’est retrouvée à déployer une tempête de logs qui réécrivait un énorme disque VM en boucle, le pool a commencé à monter. Les tableaux ont montré les snapshots comme détenteurs en quelques minutes. Ils ont élagué prudemment, ajusté la politique pour ce dataset, et sont passés à autre chose. Pas d’all-hands, pas d’achat d’urgence, pas de folklore « ZFS hanté ». Ennuyeux, correct, efficace.

Erreurs courantes, symptômes, corrections

Erreur 1 : Faire confiance à `du` pour expliquer l’allocation du pool

Symptôme : du montre une petite utilisation ; le pool est presque plein ; supprimer des fichiers n’aide pas.

Pourquoi ça arrive : Les snapshots, clones, zvols, la compression et les métadonnées ne sont pas représentés comme vous l’imaginez dans un parcours de répertoire.

Correction : Utilisez d’abord la comptabilité ZFS.

cr0x@server:~$ zfs list -o space -S used -r tank

Erreur 2 : Supprimer le mauvais dataset parce que vous avez regardé le USED du parent

Symptôme : Vous supprimez depuis le point de montage de tank, rien ne change, ou vous cassez quelque chose d’indépendant.

Pourquoi ça arrive : Le USED du parent inclut les enfants via USEDBYCHILDREN.

Correction : Comparez USEDDS vs USEDCHILD avant d’agir.

cr0x@server:~$ zfs list -o name,usedbydataset,usedbychildren,usedbysnapshots -r tank

Erreur 3 : Supposer que la « taille » d’un snapshot égale le « used » du snapshot

Symptôme : Les snapshots semblent petits individuellement, mais USEDBYSNAPSHOTS est énorme.

Pourquoi ça arrive : Beaucoup de petits incrémentaux s’additionnent ; aussi, une longue rétention + churn accumule des blocs.

Correction : Triez les snapshots par USED et élaguez selon la politique de rétention, pas selon l’esthétique des noms.

cr0x@server:~$ zfs list -t snapshot -o name,used -S used -r tank/dataset

Erreur 4 : Oublier les refreservations sur les zvols

Symptôme : Le pool semble inexplicablement serré ; supprimer des données ne libère pas autant que prévu ; les datasets de stockage VM montrent un USEDREFRESERV élevé.

Pourquoi ça arrive : refreservation pré-alloue de l’espace « garanti » et apparaît comme consommé dans la comptabilité de l’allocateur.

Correction : Auditez les refreservations et décidez si vous avez vraiment besoin de garanties ou si vous pouvez tolérer la surallocation.

cr0x@server:~$ zfs list -o name,usedbyrefreservation,refreservation -r tank/vm

Erreur 5 : Confondre `quota` avec l’espace libre du pool

Symptôme : L’application dit « plus d’espace », mais zpool list montre beaucoup de libre ; AVAIL du dataset est faible.

Pourquoi ça arrive : Les quotas limitent la croissance d’un dataset indépendamment de l’espace libre du pool.

Correction : Vérifiez quota/refquota et ajustez en connaissance de cause.

cr0x@server:~$ zfs get -o name,property,value -H quota,refquota tank/app

Erreur 6 : Considérer que « supprimer des snapshots » est toujours sûr

Symptôme : La destruction de snapshot échoue ou est bloquée ; l’espace n’est pas récupéré comme prévu.

Pourquoi ça arrive : Les clones dépendent des snapshots d’origine ; des blocs partagés entre snapshots peuvent réduire le reclaim.

Correction : Vérifiez les clones via origin et planifiez une promotion de clone ou des changements de cycle de vie.

cr0x@server:~$ zfs list -o name,origin -r tank | grep -v '^-'

Check-lists / plan étape par étape

Plan étape par étape : « Le pool se remplit plus vite que prévu »

Confirmez l’état du pool et la tendance de capacité.
```
cr0x@server:~$ zpool list
cr0x@server:~$ zpool status
```
Interprétation : Assurez-vous de ne pas confondre un problème de capacité avec un vdev dégradé / problème de resilver.
Trouvez les datasets principaux par USED puis par espace détenu par les snapshots.
```
cr0x@server:~$ zfs list -o space -S used -r tank | head -n 30
cr0x@server:~$ zfs list -o name,usedbysnapshots,usedbydataset,usedbychildren -S usedbysnapshots -r tank | head -n 30
```
Interprétation : Identifiez si la croissance vient des données vivantes, des snapshots, des enfants ou des reservations.
Si les snapshots dominent, localisez la politique de snapshot et le churn.
```
cr0x@server:~$ zfs list -t snapshot -o name,used -S used -r tank/offender | head
cr0x@server:~$ zfs get -o name,property,value -H written tank/offender
```
Interprétation : Gros written + beaucoup de snapshots = pression d’espace prévisible.
Si la refreservation domine, inventorie les zvols et contrats.
```
cr0x@server:~$ zfs list -o name,type,usedbyrefreservation,refreservation,volsize -r tank/offender
```
Interprétation : Décidez si les garanties sont requises ou si vous pouvez réduire l’espace réservé en toute sécurité.
Si les enfants dominent, creusez récursivement et évitez de supprimer au mauvais niveau.
```
cr0x@server:~$ zfs list -o space -S used -r tank/offender
```
Interprétation : Trouvez la vraie sous-arborescence ; ne faites pas de « nettoyage » aléatoire.
Après tout changement, revérifiez la répartition d’espace et le CAP du pool.
```
cr0x@server:~$ zfs list -o space tank/offender
cr0x@server:~$ zpool list
```
Interprétation : Assurez-vous que le levier que vous avez actionné a bien fait bouger les chiffres attendus.

Checklist : avant de supprimer des snapshots en production

Confirmez le dataset et la nomenclature/la politique de rétention des snapshots (évitez de supprimer le dernier point de restauration valable).
Vérifiez les clones qui dépendent de ces snapshots (origin).
Privilégiez la suppression des snapshots les plus anciens en premier pour améliorer la prévisibilité du reclaim (sauf si la politique exige le contraire).
Mesurez la récupération attendue en ordonnant les snapshots par USED (en sachant que c’est une borne supérieure).

Checklist : avant de modifier reservation/refreservation

Identifiez le consommateur (hôte VM, cible iSCSI, exigence applicative).
Confirmez si la garantie est nécessaire pour la correction ou juste pour le confort.
Ajustez par petites étapes pendant des périodes stables ; surveillez le CAP du pool et le comportement de la charge.

FAQ

1) Pourquoi `df` affiche beaucoup d’espace mais ZFS dit que le pool est presque plein ?

df rapporte l’espace visible par le système de fichiers à l’intérieur d’un dataset, généralement en ignorant les blocs détenus par les snapshots et parfois d’autres réalités de l’allocateur. Le remplissage du pool ZFS concerne les blocs alloués. Si les snapshots sont volumineux ou si des reservations sont en jeu, ces chiffres divergent fortement.

2) Quelle est la différence entre `USED` et `REFERENCED` ?

REFERENCED est combien d’espace l’état vivant du dataset référence. USED est côté allocateur et peut inclure l’espace retenu par les snapshots, les enfants, et les impacts des reservations selon le contexte. Quand les snapshots sont lourds, USED peut écraser REFERENCED.

3) Est-ce que `USEDBYSNAPSHOTS` équivaut à la somme des valeurs USED des snapshots ?

Pas toujours, car le partage et les frontières de comptabilité peuvent compliquer les sommes naïves—surtout avec des clones et des blocs partagés. Traitez le USED des snapshots comme « croissance incrémentale par snapshot », et USEDBYSNAPSHOTS comme « espace retenu à cause des snapshots » au niveau du dataset.

4) J’ai supprimé beaucoup de snapshots, mais l’espace n’est pas revenu immédiatement. Pourquoi ?

Raisons courantes : des blocs sont encore référencés par d’autres snapshots, clones ou états de dataset ; la libération asynchrone peut prendre du temps ; ou la pression vient en réalité des reservations/refreservations. Revérifiez zfs list -o space et cherchez des clones via origin.

5) Les reservations et refreservations sont-elles une « vraie utilisation » ?

Cela dépend du point de vue : pour l’allocateur, oui, car elles réduisent ce que les autres datasets peuvent utiliser en toute sécurité. Elles peuvent ne pas correspondre à des données vivantes, mais elles affectent absolument la réussite des écritures sous pression.

6) Pourquoi les datasets VM ont-ils souvent une énorme utilisation par snapshots ?

Les disques VM churnent : de petites écritures sur de grands disques virtuels réécrivent constamment des blocs. Avec les snapshots, les anciens blocs restent référencés, donc le churn se traduit par une croissance d’espace. La fréquence et la rétention des snapshots comptent plus pour les datasets VM que pour des charges majoritairement en append.

7) Comment trouver rapidement le plus gros « space hog » ?

Commencez par :

cr0x@server:~$ zfs list -o space -S used -r tank | head -n 30

Puis décidez si le coupable est les snapshots, les enfants, le dataset, ou les reservations en lisant les colonnes de décomposition.

8) Quand dois-je utiliser la sortie `-p` ?

Chaque fois que vous prévoyez de parser les résultats dans des scripts, tableaux de bord ou alertes. Les unités lisibles par l’humain sont ambiguës et sensibles à la locale ; les entiers sont stables.

9) Puis-je « régler » les problèmes d’espace en désactivant les snapshots ?

Désactiver les snapshots futurs ne libérera pas les blocs déjà détenus par des snapshots existants. Vous devez supprimer les snapshots (en sécurité) pour récupérer de l’espace. De plus, désactiver les snapshots peut être une décision de gouvernance—assurez-vous de ne pas troquer la capacité contre un risque de restauration inacceptable.

10) Que faire si `USEDBYDATASET` est énorme mais que l’application assure avoir nettoyé ?

Vous pouvez avoir des données non visibles au point de montage (zvols), des montages masqués, ou un nettoyage effectué à l’intérieur d’un invité (VM) pendant que l’hôte voit un gros fichier disque virtuel qui ne s’est pas réduit. Validez ce que le dataset contient réellement et s’il s’agit d’un volume ou d’un filesystem.

Conclusion

zfs list -o space est la vue de « vérité de capacité » la plus utile dans l’exploitation quotidienne de ZFS parce qu’elle répond à la seule question qui compte pendant un incident : qui tient les blocs ? Une fois que vous pouvez séparer l’espace détenu par les snapshots des données vivantes et des promesses de réservation, le mystère s’évapore—et vos options de remédiation deviennent claires, sûres et rapides.

Si vous exploitez ZFS en production, faites de cette vue une habitude : basez-vous dessus, alertez dessus, et enseignez-la. Le pool n’est pas hanté. Il est comptabilisé.