ZFS logicalused vs used : les chiffres qui mettent fin aux débats

Toute discussion sur le stockage dans une salle de chat d’entreprise finit inévitablement par une capture d’écran de zfs list et l’affirmation confiante que « ZFS ment ». Il ne ment pas. Il applique simplement des règles de comptabilité différentes de celles que votre cerveau a apprises avec ext4, VMFS, ou cette interface SAN qui arrondit tout en « à peu près beaucoup ».

Ce texte porte sur deux champs qui semblent petits — logicalused et used — et sur pourquoi ils font la différence entre une astreinte calme et un incident escaladé. Nous irons assez loin pour satisfaire la personne qui lit zdb pour le plaisir, mais de façon suffisamment pratique pour que vous puissiez diagnostiquer une crise d’espace pendant que quelqu’un des Finances demande pourquoi « nous payons des disques que nous n’utilisons pas ».

Pourquoi ces deux nombres importent

Dans ZFS, la question « combien d’espace est utilisé ? » n’est pas unique. C’est au moins trois questions :

• Combien d’espace mes données occuperaient-elles si elles étaient stockées sans compression et sans partage de blocs avec des snapshots/clones ?
• Combien d’espace physique est réellement alloué sur le disque en ce moment ?
• Combien d’espace puis-je libérer en supprimant ce dataset, fichier, snapshot ou clone ?

logicalused et used correspondent aux deux premières questions. Les confondre et vous allez :

• Mauvais dimensionnement de pools (acheter trop, ou pire, pas assez).
• Supprimer la mauvaise chose sous pression (classique « nous avons supprimé le dataset mais rien ne s’est libéré »).
• Blâmer ZFS pour votre propre incompréhension (une noble tradition IT).

Une petite plaisanterie, comme l’exige la tradition : les rapports de stockage ZFS ressemblent à l’addition d’un restaurant — si vous ne comprenez pas les lignes, vous accuserez le serveur de vol. Le serveur fait juste des maths que vous n’aviez pas demandé à voir.

Définitions : used vs logicalused

Ce que signifie used

used est la quantité d’espace que le dataset a allouée dans le pool, mesurée en espace réel sur disque. Il inclut les effets de la compression, des copies, du surcoût de parité (indirectement, parce que l’allocation se fait dans l’espace réel du pool), et il inclut les blocs référencés uniquement par ce dataset ainsi que les blocs partagés avec des snapshots/clones en fonction de la propriété que vous lisez.

En termes simples : used est l’allocation physique du pool attribuée à l’espace de noms de ce dataset, telle que ZFS la comptabilise.

Ce que signifie logicalused

logicalused est la taille logique des données stockées dans ce dataset — ce que vous obtiendriez si vous sommiez les tailles des fichiers (ou les tailles logiques des blocs) avant compression. Il est conçu pour répondre : « Quelle est la taille des données, conceptuellement ? » et non « Combien de disque ça a coûté ? »

En termes simples : logicalused est la taille apparente du point de vue de ZFS.

Pourquoi ils divergent

Le delta entre eux s’explique principalement par :

• Compression : logicalused reste « grand », used rétrécit.
• Snapshots et clones : la suppression peut ne pas libérer used si des blocs sont encore référencés ailleurs.
• Réservations : l’espace peut être « indisponible » sans être « utilisé par des données ».
• Copies, recordsize/volblocksize, padding : les frais généraux et la granularité d’allocation peuvent rendre used plus grand que prévu.

Le modèle de comptabilité de l’espace (ce que ZFS compte réellement)

ZFS est un système de fichiers copy-on-write avec un stockage en pool. Cette seule phrase explique pourquoi votre intuition issue des systèmes de fichiers traditionnels échoue.

Blocs, références, et pourquoi la suppression ne libère pas toujours l’espace

Dans ZFS, les blocs sont libérés quand la dernière référence disparaît. Un fichier dans un dataset référence des blocs. Un snapshot référence aussi des blocs (un ensemble de références à un instant T). Un clone référence également des blocs. Tant que chaque objet référent ne lâche pas prise, les blocs restent alloués.

Vous pouvez donc supprimer le fichier — et ne toujours pas libérer un octet — parce que le snapshot conserve les anciens blocs. Ce n’est pas un « surcoût de snapshot », c’est le snapshot qui fait son travail : préserver les données anciennes.

« Used by dataset » vs « used by snapshots » est de la comptabilité, pas de la physique

ZFS expose une famille de propriétés pour détailler l’utilisation. L’essentiel est de comprendre que certaines propriétés répondent à « qu’est-ce qui est attribuable à ce dataset » et d’autres à « qu’est-ce qui est exclusif à ce dataset ».

Si vous retenez une chose pour l’astreinte : used n’est pas équivalent à « espace libéré si je détruis ce dataset ». Pour cela, vous voulez usedbydataset, usedbysnapshots, usedbychildren, usedbyrefreservation, et souvent logicalused plus logicalusedbydataset.

La compression est la raison la plus simple pour laquelle logique et physique diffèrent

La compression change le nombre de secteurs physiques alloués, mais elle ne change pas ce que les applications pensent avoir écrit. Votre base de données a toujours écrit 1 To de pages ; ZFS a peut-être stocké 300 Go parce que la compression a bien fonctionné. C’est exactement pourquoi logicalused existe : il maintient la vue « ce que l’application pense avoir consommé », même quand vous le stockez moins cher.

Contexte historique et faits intéressants

Ce ne sont pas des anecdotes pour le plaisir ; elles expliquent pourquoi ZFS rapporte ce qu’il rapporte.

1. ZFS a été conçu pour mettre fin au rituel de réparation des systèmes de fichiers. Checksums, copy-on-write et intégrité bout en bout étaient des objectifs centraux, et le modèle de comptabilité a suivi : les snapshots immuables et le partage de blocs sont des fonctionnalités, pas des cas limites.
2. Les premiers évangélistes de ZFS ont vanté « les snapshots sont bon marché ». Vrai pour les métadonnées et les blocs non modifiés. Mais les blocs modifiés s’accumulent, et la comptabilité de l’espace a dû expliquer cette réalité.
3. Le « stockage en pool » a été un changement philosophique. Les systèmes de fichiers traditionnels vivaient sur des partitions/LUNs fixes. ZFS a déplacé les contraintes vers le pool, c’est pourquoi les datasets peuvent avoir des quotas/réservations indépendants tout en partageant le même allocateur physique.
4. La famille logicalused est arrivée pour rendre la compression visible. Les opérateurs avaient besoin d’un moyen de séparer « empreinte applicative » et « coût disque », notamment pour la planification de capacité et la facturation interne.
5. Le copy-on-write explique la fragmentation et les frais d’allocation. ZFS évite l’écrasement en place ; il écrit de nouveaux blocs et bascule des pointeurs. La comptabilité de l’espace doit donc gérer plusieurs versions de blocs et le churn d’allocation à court terme.
6. La standardisation OpenZFS compte. Des propriétés comme usedby* et logicalused* sont largement disponibles maintenant, mais d’anciennes versions fournisseurs et des forks de l’ère illumos variaient — d’où de nombreuses histoires « mais mon système n’affiche pas cette propriété ».
7. Les grandes tailles de record ont été un choix de performance délibéré. Les valeurs par défaut de recordsize (par ex. 128K) ont été choisies pour rendre l’IO séquentiel efficace, mais elles influencent aussi combien d’espace physique est alloué pour de petites écritures et la compressibilité des données.
8. La comptabilité de l’espace est devenue un champ de bataille du support. Les vendeurs de stockage et les équipes plateformes internes ont appris à la dure qu’une simple colonne « Used » génère des tickets. Les propriétés détaillées existent parce que les opérateurs ont exigé des réponses, pas des impressions.

Comment la compression change l’histoire

La compression est la raison la plus courante pour laquelle logicalused dépasse used. C’est aussi la raison pour laquelle la planification de capacité ZFS peut sembler magique à ceux qui n’ont pas vécu un pool se remplir à 3 h du matin.

Exemple : la base de données qui « utilisait 10 To » sur un pool de 4 To

J’ai vu le message paniqué : « Le dataset indique 10 To utilisés mais le pool fait seulement 4 To — ZFS est corrompu. » Non, c’est de la compression. logicalused suit la taille logique ; used suit l’allocation réelle. Si vos données compressent 3:1, les nombres logiques peuvent être plus grands que la capacité du pool et rester parfaitement sains.

Le ratio de compression n’est pas une promesse

Au moment où votre charge change, votre « espace libre » évolue d’une manière qui semble injuste. Les logs compressent bien jusqu’à ce qu’ils ne compressent plus. Les images VM compressent bien jusqu’à ce que quelqu’un active le chiffrement complet du disque dans la VM. Les sauvegardes compressent bien jusqu’à ce que votre logiciel de sauvegarde commence sa propre compression et son chiffrement.

Planifier la capacité en se basant sur le ratio de compression d’hier, c’est comme budgéter en se basant sur la météo d’hier : ça marche jusqu’au moment où vous en avez besoin.

Deuxième petite blague : la compression, c’est comme faire sa valise — tout rentre jusqu’à ce que vous ajoutiez des chaussures.

Snapshots, clones et le fisc

Les snapshots sont la raison pour laquelle ZFS peut être votre meilleur ami et votre menteur le plus convaincant. Ils ne mentent pas, mais ils révèlent combien vous ignorez des données « supprimées ».

Les snapshots maintiennent les blocs en vie

Lorsque vous faites un snapshot d’un dataset, vous figez un ensemble de pointeurs de blocs. Les modifications ultérieures allouent de nouveaux blocs ; les anciens blocs restent référencés par le snapshot. Voilà pourquoi :

• La suppression d’un fichier peut ne pas réduire significativement (ou du tout) le used.
• La destruction d’anciens snapshots peut soudainement libérer d’énormes quantités d’espace.
• usedbysnapshots peut croître rapidement sur des charges à fort churn (VMs, bases de données, espaces CI).

Les clones sont une propriété partagée avec paperasserie

Un clone est un dataset inscriptible qui commence comme un snapshot. Il partage des blocs jusqu’à divergence. Cela complique la récupération d’espace car plusieurs enfants peuvent référencer la même généalogie. Si vous détruisez l’origine en pensant libérer de l’espace, vous pouvez découvrir que le clone est devenu le propriétaire principal de ces blocs.

La conséquence pratique

En réponse à un incident, les snapshots sont le premier endroit à regarder pour « l’espace qui ne part pas ». Dans les rapports de capacité, les snapshots expliquent pourquoi vous ne devez jamais traiter « dataset used » comme équivalent au « coût ».

Réservations, quotas, refquota : les contrats cachés

La comptabilité de l’espace n’est pas que de la physique ; c’est de la politique. ZFS vous permet de faire des promesses (réservations) et d’imposer des limites (quotas). Ces promesses et limites apparaissent de façons qui surprennent ceux qui ne regardent que used.

Quota vs refquota (et pourquoi c’est important)

quota limite un dataset et ses descendants. refquota limite seulement l’espace référencé du dataset (pas les enfants). Cette distinction a de l’importance quand votre « dataset projet » est un parent avec de nombreux enfants.

Si vous voulez empêcher un dataset de gonfler tout en permettant aux enfants de croître indépendamment, refquota est l’outil. Si vous voulez plafonner tout un sous-arbre, quota est l’outil.

Reservation vs refreservation

reservation réserve de l’espace pour un dataset et ses descendants. refreservation réserve l’espace uniquement pour le dataset lui-même. Les réservations réduisent ce que le pool rapporte comme disponible même si le dataset n’a pas encore réellement écrit ces données.

C’est de là que viennent les incidents « pourquoi le pool est plein ? » : le pool n’est pas plein de données ; il est plein de promesses.

Refreservation apparaît comme usedbyrefreservation

Quand quelqu’un définit refreservation pour une « sécurité de performance » et l’oublie, cela devient un tueur silencieux de capacité. L’espace est alloué en termes comptables, faisant paraître le pool tendu et provoquant des échecs d’allocation plus tôt que prévu.

Tâches pratiques : commandes + interprétation

Voici les commandes que j’utilise réellement quand quelqu’un dit « l’espace ZFS est faux ». Chaque tâche inclut ce que vous recherchez et comment l’interpréter.

Task 1: Compare used vs logicalused for a dataset

cr0x@server:~$ zfs list -o name,used,logicalused,avail,refer,logicalrefer -H tank/app
tank/app	320G	950G	1.2T	310G	920G

Interprétation : Le dataset contient environ 950G de données logiques mais ne coûte qu’environ 320G d’espace physique — la compression et/ou le partage de blocs paient le loyer. Si le pool est bas, la suppression de ce dataset pourrait ne libérer qu’environ la quantité indiquée par used (et possiblement moins si des snapshots/clones partagent des blocs).

Task 2: Get the usage breakdown (the argument-settler)

cr0x@server:~$ zfs list -o name,used,usedbydataset,usedbysnapshots,usedbychildren,usedbyrefreservation -H tank/app
tank/app	320G	180G	120G	0B	20G

Interprétation : 120G est attribué aux snapshots, 20G est lié à la refreservation. Si vous essayez de récupérer de l’espace, supprimer des snapshots peut être plus efficace que supprimer des fichiers.

Task 3: List snapshots with space impact

cr0x@server:~$ zfs list -t snapshot -o name,used,refer,logicalused -s used -H tank/app
tank/app@daily-2025-12-20	40G	310G	920G
tank/app@daily-2025-12-21	35G	312G	925G
tank/app@daily-2025-12-22	25G	315G	930G

Interprétation : Le used d’un snapshot est l’espace tenu uniquement à cause de ce snapshot (approximativement : les blocs qui seraient libérés si on le détruisait, en supposant qu’il n’y ait pas de clones). Triez par used pour trouver les plus coûteux.

Task 4: Check compression settings and observed ratio

cr0x@server:~$ zfs get -o name,property,value -H compression,compressratio,logicalused,used tank/app
tank/app	compression	zstd
tank/app	compressratio	2.96x
tank/app	logicalused	950G
tank/app	used	320G

Interprétation : Un ratio ~3x explique l’écart. Si compressratio est proche de 1.00x mais que logicalused est encore énorme, cherchez des snapshots/clones ou des frais d’allocation.

Task 5: Confirm whether you’re dealing with a volume (zvol) vs filesystem

cr0x@server:~$ zfs get -H -o name,property,value type,volblocksize,recordsize tank/vm-001
tank/vm-001	type	volume
tank/vm-001	volblocksize	16K
tank/vm-001	recordsize	-

Interprétation : Les volumes se comportent différemment : les petites écritures aléatoires, le padding et les choix de blocksize peuvent modifier les schémas d’utilisation physique et la croissance des snapshots.

Task 6: Spot reservations and why “avail” is small

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

Interprétation : Cette refreservation de 50G apparaîtra dans usedbyrefreservation et réduira l’espace libre du pool même si le dataset est majoritairement vide.

Task 7: Confirm pool health and real free space (don’t ignore slop)

cr0x@server:~$ zpool list -o name,size,alloc,free,frag,capacity,health
NAME   SIZE  ALLOC   FREE  FRAG  CAPACITY  HEALTH
tank  7.25T  6.70T   550G   48%       92%  ONLINE

Interprétation : 92% de capacité, c’est la zone « commencez à annuler des réunions ». Même si des datasets montrent « avail », la fragmentation du pool et les besoins de l’allocateur peuvent faire échouer des écritures plus tôt que prévu.

Task 8: Show top datasets by physical used

cr0x@server:~$ zfs list -o name,used,logicalused,compressratio -S used | head -n 10
NAME             USED  LOGICALUSED  COMPRESSRATIO
tank/vm          2.4T  2.6T         1.08x
tank/backups     1.9T  6.1T         3.21x
tank/home        980G  1.1T         1.12x
tank/app         320G  950G         2.96x

Interprétation : Commencez par ce qui coûte de l’espace physique, pas ce qui paraît gros logiquement. Les 6.1T logiques des backups ne sont que 1.9T réels ; les VMs sont chères parce qu’elles ne compressent pas beaucoup.

Task 9: Identify snapshot-heavy datasets quickly

cr0x@server:~$ zfs list -o name,used,usedbysnapshots,logicalused -S usedbysnapshots | head -n 10
NAME           USED  USEDBYSNAPSHOTS  LOGICALUSED
tank/vm        2.4T  820G             2.6T
tank/app       320G  120G             950G
tank/home      980G  40G              1.1T

Interprétation : usedbysnapshots est votre signal « espace épinglé par l’historique ». Des valeurs élevées signifient churn + snapshots ; ajustez la rétention ou la cadence des snapshots, pas seulement la taille du dataset.

Task 10: Check whether a dataset has clones depending on snapshots

cr0x@server:~$ zfs get -H -o name,property,value clones tank/app@daily-2025-12-20
tank/app@daily-2025-12-20	clones	tank/app-clone-qa

Interprétation : Vous ne pouvez pas détruire ce snapshot sans gérer le clone. Si quelqu’un dit « nous avons supprimé des snapshots mais l’espace n’a pas été libéré », les clones sont un suspect principal.

Task 11: Estimate what you’d free by destroying a snapshot (dry run logic)

cr0x@server:~$ zfs list -t snapshot -o name,used -s used -H tank/app | tail -n 5
tank/app@daily-2025-11-30	2G
tank/app@daily-2025-12-01	3G
tank/app@daily-2025-12-02	4G
tank/app@daily-2025-12-03	9G
tank/app@daily-2025-12-04	15G

Interprétation : Le used d’un snapshot est une première approximation décente de « ce que vous pourriez récupérer », mais souvenez-vous : les clones peuvent empêcher la récupération, et la suppression d’un snapshot peut transférer la comptabilité vers d’autres snapshots.

Task 12: Destroy snapshots safely with a pattern (and verify)

cr0x@server:~$ zfs destroy -n -v tank/app@daily-2025-12-0{1,2,3}
would destroy tank/app@daily-2025-12-01
would destroy tank/app@daily-2025-12-02
would destroy tank/app@daily-2025-12-03

cr0x@server:~$ zfs destroy -v tank/app@daily-2025-12-0{1,2,3}
will destroy tank/app@daily-2025-12-01
will destroy tank/app@daily-2025-12-02
will destroy tank/app@daily-2025-12-03

cr0x@server:~$ zfs list -o name,used,avail -H tank/app
tank/app	250G	1.3T

Interprétation : Utilisez -n d’abord. Puis exécutez. Puis vérifiez. En production, la différence entre héros et titre de presse, c’est un dry run.

Task 13: Check for space “stuck” due to refreservation

cr0x@server:~$ zfs list -o name,usedbyrefreservation,refreservation -H tank/app
tank/app	20G	50G

cr0x@server:~$ zfs set refreservation=none tank/app

cr0x@server:~$ zfs list -o name,used,avail -H tank/app
tank/app	230G	1.4T

Interprétation : Vous venez de récupérer de l’« espace politique ». Confirmez avec l’équipe propriétaire avant de supprimer des réservations ; parfois elles existent pour une raison légitime de tolérance aux pics.

Task 14: Compare file apparent sizes to ZFS logical numbers (sanity check)

cr0x@server:~$ df -hT /tank/app
Filesystem     Type  Size  Used Avail Use% Mounted on
tank/app       zfs   1.5T  310G  1.2T  21% /tank/app

cr0x@server:~$ du -sh /tank/app
910G	/tank/app

Interprétation : du est une vue via l’espace de noms du système de fichiers et peut être biaisée par des fichiers creux, des permissions, et des modifications en direct. Traitez-la comme une preuve d’appui, pas comme la vérité. Les propriétés ZFS sont généralement plus cohérentes pour la comptabilité.

Task 15: If you suspect sparse files in VMs or databases

cr0x@server:~$ ls -lh /tank/vm/images/vm-001.img
-rw------- 1 root root 500G Dec 25 10:11 /tank/vm/images/vm-001.img

cr0x@server:~$ du -h /tank/vm/images/vm-001.img
120G	/tank/vm/images/vm-001.img

Interprétation : Ce fichier est sparse : la taille logique est 500G, la consommation physique est 120G. logicalused tend à s’aligner sur la vision « 500G », tandis que used s’aligne sur la réalité « 120G », modulée par la compression et les snapshots.

Mini-récits du monde de l’entreprise en production

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

L’équipe de stockage a reçu une page pour « pool à 95% » un vendredi après-midi, le genre de timing qui suggère que l’univers a un calendrier et un sens de l’humour. Le propriétaire de l’application a pointé logicalused : leur dataset « contenait plusieurs téraoctets », donc ils étaient les coupables. Ils se sont portés volontaires pour supprimer un lot d’anciens export. Tout le monde a applaudi ; personne n’a vérifié les snapshots.

Les exports ont été supprimés. du a chuté. Slack s’est rempli de pouces levés. Le pool ne bougeait pas. Le job suivant, intensif en écritures, a rencontré ENOSPC dans l’heure et a mis hors service une pipeline d’ingestion. C’était maintenant un incident avec des cadres, pas seulement des ingénieurs.

Nous avons finalement fait la chose adulte : lancé zfs list -o usedby* et trié les snapshots par used. Le dataset avait une politique de snapshots agressive — toutes les 15 minutes — pour des « rollback faciles », et la charge réécrivait constamment de gros fichiers. Les snapshots n’étaient pas bon marché. Ils thésaurisaient les blocs d’hier comme un conservateur de musée avec un budget de stockage.

La correction n’a pas été héroïque. Nous avons réduit la fréquence des snapshots, raccourci la rétention, et détruit un ensemble de snapshots à fort impact après avoir confirmé qu’aucun clone n’en dépendait. L’espace est revenu, l’ingestion a repris, et la leçon clé du postmortem a été imprimée en gras : « Supprimer des fichiers n’est pas un plan de récupération d’espace quand des snapshots existent. »

Ce qui a fait mal n’était pas la complexité technique ; c’était la mauvaise hypothèse que la suppression de fichiers équivaut à la récupération d’espace. Dans ZFS, les références comptent plus que l’intention.

Mini-récit 2 : L’optimisation qui a échoué

Une équipe plateforme voulait de meilleures performances VM et a décidé « d’optimiser les snapshots » en passant le dataset VM à une plus petite taille de bloc et en augmentant la fréquence des snapshots, en supposant que des blocs plus petits signifiaient de plus petits deltas. La théorie sonnait plausible en réunion. La théorie sonne souvent bien.

En pratique, les blocs plus petits ont augmenté le surcoût métadonnées et transformé les écritures en une pluie confettis d’allocations. La charge VM — beaucoup d’écritures aléatoires — a produit un flux continu de nouveaux blocs. Les snapshots capturaient les anciens. L’utilisation d’espace des snapshots a crû plus vite, pas moins vite. Le ratio de compression s’est aussi détérioré parce que des blocs plus petits et plus aléatoires compprimaient moins efficacement.

Le premier signe n’a pas été un tableau de bord ; ce fut la latence. Le pool est devenu fragmenté et occupé. Puis ce fut la capacité : usedbysnapshots est devenu le terme dominant. L’équipe a essayé de supprimer des snapshots « anciens », mais des clones issus de workflows CI détenaient des références, donc les grosses libérations n’arrivaient jamais.

Le plan de récupération était peu glorieux : revenir à une cadence de snapshots sensée, réévaluer les choix de blocksize par charge de travail, et arrêter de cloner à partir de snapshots conservés longtemps. La vraie optimisation n’était pas « plus de réglages », mais d’aligner la politique (snapshots) avec le churn de la charge et comprendre que logicalused n’est pas une facture.

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

Une autre organisation avait une règle : chaque alerte de capacité devait être accompagnée d’un « snapshot de comptabilité d’espace » obligatoire — quatre commandes collées dans le ticket : zpool list, zfs list -o usedby* sur les principaux datasets, la liste des snapshots triée par used, et une vérification des réservations/quotas. C’était si ennuyeux que les ingénieurs se plaignaient que c’était bureaucratique. C’était aussi la raison pour laquelle leurs incidents se terminaient rapidement.

Une nuit, un pool a commencé à monter en usage de façon inattendue. L’astreinte a suivi la checklist, a découvert un dataset unique avec un pic de usedbyrefreservation, et a trouvé qu’un job d’automatisation avait appliqué une grande refreservation pour « protéger la performance » pendant une migration. La migration s’est terminée ; la réservation est restée.

Ils ont retiré la réservation après confirmation qu’elle n’était plus nécessaire. L’espace libre du pool a récupéré instantanément. Pas de purge de snapshots, pas de suppressions risquées, pas de drame. La correction a été littéralement un changement de propriété et une note dans le runbook.

Le commentaire post-incident de l’astreinte était du genre à encadrer : « Nous n’avons pas réparé le stockage ; nous avons réparé la comptabilité. » C’est ce que sont la plupart des incidents d’espace ZFS.

Mode opératoire de diagnostic rapide

Voici le flux de triage quand quelqu’un dit « nous n’avons plus d’espace » ou « les nombres ZFS ne s’additionnent pas ». Exécutez-le dans l’ordre ; il est conçu pour trouver rapidement le goulot d’étranglement, pas pour satisfaire la curiosité.

Premier : le pool est-il réellement serré ?

cr0x@server:~$ zpool list -o name,size,alloc,free,capacity,frag,health
NAME   SIZE  ALLOC   FREE  CAPACITY  FRAG  HEALTH
tank  7.25T  6.70T   550G       92%   48%  ONLINE

Décision : Si la capacité dépasse ~80–85% sur beaucoup de pools (et surtout au-dessus de 90%), supposez un risque de performance et d’allocation. Ne débattez pas encore des chiffres par dataset ; stabilisez le pool.

Deuxième : quels datasets coûtent le plus en espace physique ?

cr0x@server:~$ zfs list -o name,used,avail,logicalused,compressratio -S used | head -n 15

Décision : Concentrez-vous sur used pour un soulagement immédiat, pas sur logicalused. Le pool ne peut allouer que du physique.

Troisième : l’espace est-il épinglé par des snapshots/clones ?

cr0x@server:~$ zfs list -o name,used,usedbysnapshots,usedbydataset,usedbychildren -S usedbysnapshots | head -n 15

cr0x@server:~$ zfs list -t snapshot -o name,used -s used | tail -n 20

Décision : Si usedbysnapshots est élevé, regardez la rétention/cadence des snapshots et les clones. La destruction de snapshots est souvent le levier de récupération le plus sûr — après vérification des dépendances.

Quatrième : des réservations rendent-elles le « free » plus petit qu’il n’est ?

cr0x@server:~$ zfs list -o name,usedbyrefreservation,refreservation -S usedbyrefreservation | head -n 15

Décision : Si les réservations dominent, vous n’êtes pas en manque de disque ; vous êtes en manque de disque non promis. C’est une discussion politique et souvent une correction rapide.

Cinquième : la compression masque-t-elle le risque de croissance ?

cr0x@server:~$ zfs get -o name,property,value -H compressratio,compression tank | head

Décision : Si votre plan repose sur une compression élevée, supposez qu’elle chutera au moment où la charge change (chiffrement, médias déjà compressés, modifications VM). Ajoutez de la marge.

Erreurs courantes et correctifs

Erreur 1 : Prendre logicalused pour la consommation physique

Symptôme : « Le dataset est plus grand que le pool » panique, ou facturation interne qui facture des équipes pour des téraoctets qu’elles n’ont pas réellement coûtés.

Correction : Utilisez used (physique) pour la capacité et le coût. Utilisez logicalused pour l’empreinte applicative et les tendances de croissance. En cas de doute, montrez les deux, plus le compressratio.

Erreur 2 : Supprimer des fichiers pour récupérer de l’espace quand des snapshots existent

Symptôme : du chute, l’espace libre du pool ne bouge pas. Les utilisateurs jurent avoir supprimé « des centaines de gigaoctets ». Ils l’ont fait. Les snapshots l’ont gardé.

Correction : Vérifiez usedbysnapshots. Listez les snapshots par used. Confirmez les clones. Détruisez les snapshots selon la politique de rétention après validation des besoins de restauration.

Erreur 3 : Oublier les refreservations

Symptôme : Le « free » du pool est bas mais les datasets ne semblent pas grands. usedbyrefreservation est non négligeable. Les nouvelles allocations échouent plus tôt que prévu.

Correction : Inventoriez refreservation/reservation et validez chacune. Supprimez ou redimensionnez. Documentez la raison d’être.

Erreur 4 : Ignorer les clones lors du nettoyage des snapshots

Symptôme : zfs destroy échoue à cause des clones, ou la suppression de snapshot réussit mais libère moins que prévu.

Correction : Vérifiez la propriété clones sur les snapshots. Décidez si les clones sont encore nécessaires ; s’ils le sont, acceptez l’espace épinglé ou migrez les données du clone ailleurs.

Erreur 5 : Mal lire refer vs used

Symptôme : Quelqu’un dit « le refer du dataset est petit, donc il est petit », alors que used est énorme à cause d’enfants/snapshots/réservations.

Correction : Utilisez zfs list -o usedby* et décidez si le coût est dans le dataset lui-même, ses snapshots, ses enfants, ou les réservations.

Erreur 6 : Laisser les pools trop pleins en croyant « ZFS a des snapshots et de la compression »

Symptôme : La performance se dégrade, les allocations deviennent erratiques, les durées de scrub/resilver s’allongent, puis un petit pic provoque ENOSPC.

Correction : Gardez de la marge. Alarmez sur la capacité du pool, pas seulement sur l’avail des datasets. Traitez 90% comme un seuil d’urgence pour la plupart des pools de production.

Erreur 7 : Planification de capacité basée sur une seule semaine de compressratio

Symptôme : Le pool se « remplit soudainement » après un changement de charge (chiffrement, nouveaux types de données), malgré une croissance logique stable.

Correction : Suivez la croissance logique et physique dans le temps. Supposez que la compression peut régresser. Utilisez des ratios conservateurs pour les prévisions.

Checklists / plan pas à pas

Checklist de litige d’espace (mettre fin aux débats, pas aux amitiés)

1. Capturez zpool list pour la vérité au niveau pool : capacité, free, fragmentation.
2. Capturez zfs list -o used,logicalused,compressratio pour les principaux datasets triés par used.
3. Pour les 3 premiers datasets, capturez zfs list -o usedbydataset,usedbysnapshots,usedbychildren,usedbyrefreservation.
4. Listez les snapshots sur le principal coupable triés par used.
5. Vérifiez les clones sur tout snapshot à fort used.
6. Vérifiez réservations/quotas : reservation, refreservation, quota, refquota.
7. Décidez de l’action : détruire des snapshots, supprimer des réservations, supprimer des datasets, ou étendre le pool.
8. Après changements, recapturez les mêmes commandes et attachez-les au ticket pour clôture.

Plan de récupération d’urgence (quand vous êtes au-dessus de 90%)

1. Geler le churn non essentiel : pausez les gros runs CI, désactivez les restores lourds, reportez les jobs batch.
2. Détruisez d’abord les snapshots à plus fort impact (après confirmation qu’il n’y a pas de clones et des besoins de restauration).
3. Retirez les réservations accidentelles et les quotas obsolètes qui bloquent les écritures.
4. Si vous devez supprimer des données, ciblez les datasets avec un fort usedbydataset (plutôt exclusifs) plutôt que ceux dominés par l’usage snapshot.
5. Une fois stable, ajustez la rétention/cadence des snapshots pour correspondre au churn, et planifiez l’expansion avec marge.

Plan de reporting de capacité (mettre fin aux guerres de facturation)

1. Rapportez à la fois physique et logique : used et logicalused.
2. Incluez compressratio et la répartition des snapshots (usedbysnapshots).
3. Pour la facturation interne, facturez sur le used physique, mais montrez le logique comme « signal de demande ».
4. Revisitez les réservations trimestriellement ; traitez-les comme des contrats avec un propriétaire.

FAQ

1) Quel nombre dois-je utiliser pour la planification de capacité : used ou logicalused ?

Utilisez used pour « le pool va-t-il se remplir ? » car il reflète l’allocation physique. Utilisez logicalused pour « quelle est l’empreinte des données applicatives ? » et pour prédire à quel point une régression de la compression pourrait être douloureuse.

2) Pourquoi logicalused dépasse-t-il la taille du pool ?

Parce qu’il ignore la compression et peut refléter des fichiers sparse ou des données très compressibles. Il rapporte la taille logique, pas le coût sur disque. Si used tient et que le pool a de l’espace libre, ce n’est pas une erreur.

3) J’ai supprimé 500 GB et rien ne s’est libéré. Que s’est-il passé ?

Des snapshots (ou des clones) référencent probablement encore les blocs supprimés. Vérifiez usedbysnapshots, listez les snapshots triés par used, et vérifiez la propriété clones sur les snapshots avant de les supprimer.

4) Détruire un snapshot libère-t-il toujours la quantité used indiquée ?

Pas toujours. Le used d’un snapshot est une estimation de l’espace unique détenu à cause de ce snapshot, mais les références partagées et les clones peuvent changer ce qui est libéré et comment la comptabilité se déplace vers d’autres snapshots.

5) Quelle est la différence entre refer et used ?

refer est la quantité de données accessibles via le dataset (approximativement « ce que vous voyez »). used inclut l’espace attribuable aux snapshots, aux enfants, et aux réservations selon le contexte. En cas de doute, utilisez la répartition usedby*.

6) Pourquoi avail sur un dataset est-il différent de l’espace libre du pool ?

avail d’un dataset est contraint par les quotas/réservations et les limites parentales. L’espace libre du pool est physique. De plus, à forte occupation du pool, l’espace réellement allouable peut être inférieur au « free » affiché à cause de la fragmentation et des besoins de l’allocateur.

7) Un fort compressratio est-il toujours bon ?

C’est bon pour la capacité et généralement acceptable pour la performance, mais cela peut créer un risque de planification si vous supposez qu’il persistera. Un changement de charge peut faire chuter rapidement la compression et accélérer la croissance physique.

8) Comment les réservations apparaissent-elles dans « used » si aucune donnée n’a été écrite ?

Les réservations réduisent l’espace disponible et apparaissent dans la comptabilité via usedbyrefreservation (et propriétés associées). Ce sont des promesses de pré-allocation délibérées, pas des blocs de données.

9) Quelle est la façon la plus rapide de trouver ce qui épingle l’espace ?

Exécutez zfs list -o usedbydataset,usedbysnapshots,usedbychildren,usedbyrefreservation sur les plus gros datasets par used. Une de ces lignes vous dira généralement où l’espace est coincé.

10) Puis-je « défragmenter » ZFS pour récupérer de l’espace ?

La fragmentation affecte surtout la performance et l’efficacité d’allocation, pas la justesse de la comptabilité. La façon de « récupérer de l’espace » est de supprimer des références (supprimer snapshots/clones/données) ou d’ajouter de la capacité, pas de poursuivre un bouton magique de défragmentation.

Conclusion

logicalused et used ne sont pas des vérités concurrentes. Ce sont deux lentilles : l’une vous dit quelle est la taille des données en principe, l’autre vous dit quel est leur coût sur disque. La plupart des disputes en production surviennent quand quelqu’un insiste qu’il ne peut y avoir qu’une seule vérité.

Quand vous diagnostiquez la capacité, commencez par la réalité du pool (zpool list), puis trouvez qui paie la facture physique (used), ensuite demandez qui épingle l’histoire (usedbysnapshots) et qui a signé des contrats (refreservation). Faites cela systématiquement et vous cesserez de vous disputer sur les chiffres ZFS — parce que vous les lirez enfin correctement.