xattr ZFS : le choix de compatibilité qui change les performances

décembre 10, 2025 • février 3, 2026 • Lecture : 34 min • Views: 11

Cet article vous a aidé ?

ZFS a le don de rendre le stockage ennuyeux — dans le meilleur sens — jusqu’à ce qu’un petit réglage transforme votre « NAS rapide » en tapis roulant de métadonnées. Les attributs étendus (xattrs) sont exactement ce genre de levier. Ils sont petits, faciles à ignorer, et utilisés partout : SMB, NFS, étiquettes SELinux, tags Finder de macOS, runtimes de conteneurs, outils de sauvegarde, et cet écosystème tentaculaire de « il faut stocker un peu d’info en plus sur ce fichier » qui s’accumule en production réelle.

Sur ZFS, la propriété de dataset xattr est une décision de compatibilité qui change les performances. Et l’astuce est : cela ne change pas seulement les performances au sens d’un benchmark. Cela change les performances au sens d’« incident à 2 h du matin » — pics de latence, ralentissement des traversées d’arborescence, sauvegardes qui explosent, et comportements d’application étranges qui ressemblent à des « problèmes réseau » jusqu’à ce qu’on regarde sérieusement les métadonnées.

Ce que sont les xattr (et pourquoi vous vous en souciez soudainement)

Les attributs étendus sont des blobs clé/valeur attachés aux objets du système de fichiers. Ce ne sont ni le contenu du fichier ni les permissions POSIX traditionnelles. Ce sont des « métadonnées ambitieuses ». Parfois elles sont minuscules (quelques octets). Parfois elles sont volumineuses (vignettes, descripteurs de sécurité, indices). Elles peuvent être critiques pour la correction : ACLs, étiquettes de sécurité, ou état applicatif. Ou bien elles peuvent être des « agréables à avoir », comme les métadonnées Finder que les utilisateurs considèrent encore comme sacrées.

Quand les xattrs sont très utilisés, la charge devient axée sur les métadonnées. Les charges axées sur les métadonnées ne tombent pas en panne comme de gros écritures séquentielles. Elles échouent comme un restaurant bondé : la cuisine a encore des ingrédients, mais chaque commande implique trois personnes, un carnet, et un aller-retour au placard. Vos disques ne sont pas pleins, votre réseau n’est pas saturé, et pourtant tout est lent.

Une de mes blagues opérationnelles préférées est que « les métadonnées, c’est comme la paperasse : moins vous en voyez, plus il s’en passe. » L’autre : « les xattrs sont le tiroir à bazar du système de fichiers — jusqu’à ce que le CFO demande où sont les clés. »

Qu’est-ce qui utilise les xattrs en production ?

Quelques exemples que vous rencontrerez réellement :

SMB/CIFS : les métadonnées Windows, les flux de données alternatifs, et les descripteurs de sécurité se mappent souvent en xattrs ou métadonnées associées.
NFSv4 : les ACLs et métadonnées de permissions riches peuvent interagir avec les xattrs selon la pile.
Sécurité Linux : SELinux utilise des xattrs comme security.selinux. AppArmor et IMA/EVM peuvent aussi intervenir.
macOS : les tags Finder, forks de ressources, et autres métadonnées apparaissent souvent comme des xattrs quand elles sont accédées via des protocoles réseau.
Logiciels de sauvegarde : certains outils préservent les xattrs ; d’autres non ; et certains le font lentement.
Conteneurs : les systèmes de fichiers en superposition et l’extraction d’images peuvent générer beaucoup de xattrs selon la politique et les outils.

Modes xattr ZFS : `sa` vs `dir` (et pourquoi c’est important)

ZFS vous donne une propriété de dataset appelée xattr. Dans OpenZFS, les deux grands modes que vous verrez sont :

xattr=sa : stocker les xattrs dans l’espace system attribute (SA) du fichier. Pensez « métadonnées en ligne-ish stockées avec la structure de type inode », optimisé pour éviter des objets fichier séparés.
xattr=dir : stocker les xattrs comme des fichiers séparés dans un répertoire d’attributs caché associé au fichier. Pensez « les xattrs sont leurs propres petits fichiers ».

Ce n’est pas une préférence philosophique. C’est un choix de modèle de données avec des conséquences :

sa tend à réduire l’amplification d’E/S pour les petits attributs parce que vous évitez de créer et de parcourir un répertoire d’xattr et des objets fichier séparés.
dir tend à être plus compatible avec des outils anciens et certains cas limites, et il peut éviter les contraintes de taille/packing de SA en utilisant un stockage fichier régulier pour des attributs plus grands.

La subtilité opérationnelle : le réglage affecte comment ZFS touche le disque pour les opérations courantes. Une charge qui exécute « stat + getxattr + open + read » sur des millions de fichiers est effectivement un benchmark de métadonnées. Passer de dir à sa peut transformer « quatre allers au placard » en « un aller au comptoir », surtout quand votre ARC est chaud et que la latence des vdev est sous pression.

Que se passe-t-il réellement sous le capot ?

En mode dir, ZFS implémente les xattrs en créant un répertoire caché pour chaque fichier qui a des attributs, puis en stockant chaque attribut sous forme d’un fichier dans ce répertoire. Donc un getxattr peut se traduire par plusieurs recherches de métadonnées : trouver le répertoire d’xattr, chercher le « fichier » de l’attribut, puis lire ses données. Ce sont des dentries en plus, des znodes en plus, des objets DMU en plus, et potentiellement des petites lectures aléatoires supplémentaires.

En mode sa, les données d’xattr sont stockées dans l’aire d’attribut système associée au znode du fichier. Le cas idéal : vous chargez les métadonnées du znode une seule fois et l’xattr est juste là. Moins d’objets, moins de recherches, moins de lectures aléatoires.

Mais « métadonnées en ligne » n’est pas magique. Les xattrs plus volumineux peuvent déborder ou nécessiter des structures supplémentaires. Et tous les consommateurs ne se comportent pas bien : certains logiciels écrivent beaucoup d’xattrs, les réécrivent fréquemment, ou stockent des valeurs étonnamment grandes (les caches de vignettes reviennent souvent).

Faits et contexte historique utiles pour les débats

Voici quelques points concrets et concis qui aident quand vous expliquez cela à une salle pleine de gens qui veulent une réponse en une ligne :

Les xattrs sont nés comme un pont de compatibilité entre les permissions Unix classiques et des besoins de métadonnées plus riches (ACLs, étiquettes de sécurité, métadonnées de bureau). Ils sont devenus courants parce que les applications avaient besoin de métadonnées sans changer le format des fichiers.
Linux a standardisé des espaces de noms xattr comme user.* et security.*, ce qui explique les noms cohérents entre distributions et outils.
Les forks de ressources macOS ont historiquement vécu dans des structures séparées ; lorsqu’ils sont transportés sur des partages réseau ils sont souvent représentés comme des xattrs ou des flux alternatifs, ce qui surprend jusqu’à ce que cela casse un workflow créatif.
SMB a évolué vers un protocole gourmand en métadonnées pour de nombreuses charges. Les serveurs de fichiers ne se contentent plus de « lire/écrire des octets » ; ils doivent préserver des attributs riches et la sémantique ACL.
ZFS a été conçu avec de forts objectifs de correction : copy-on-write, checksums, et sémantiques transactionnelles. Cela le rend excellent pour éviter la corruption silencieuse, mais les charges axées sur les métadonnées peuvent révéler des surcoûts si vous choisissez des structures qui multiplient les objets de métadonnées.
Les system attributes (SA) d’OpenZFS ont été introduits pour stocker les métadonnées étendues plus efficacement. Ce n’était pas une micro-optimisation ; c’était une réponse à des charges réelles avec trop de petits objets de métadonnées.
« Les petites E/S aléatoires » sont devenues la taxe moderne à mesure que les charges ont changé : machines virtuelles, conteneurs, pipelines CI, et outils de collaboration génèrent des tempêtes de métadonnées. Le choix de stockage des xattr devient disproportionné dans ces tempêtes.
Les sauvegardes ont appris les xattrs à la dure : pendant des années, des équipes ont découvert qu’une restauration sans xattrs pouvait être une rupture fonctionnelle silencieuse (tempêtes de relabellisation SELinux, sémantique ACL manquante, apps qui stockent des flags en xattrs).

Comment le choix modifie les performances dans des systèmes réels

Parlons en termes qui correspondent à ce que vous verrez sur des graphiques.

1) Latence : le KPI invisible

La principale différence de performance n’est pas le débit en Mo/s. C’est la latence des opérations sur les appels de métadonnées : getxattr, listxattr, setxattr, plus les recherches implicites nécessaires pour trouver le stockage des xattrs.

Avec xattr=dir, vous observez souvent :

Une latence moyenne plus élevée pour les opérations de métadonnées en raison de traversées d’objets supplémentaires.
Des latences de queue (p95/p99) plus prononcées sous contention, parce que chaque « ouverture de fichier » peut entraîner des lectures de métadonnées supplémentaires.
Une plus grande sensibilité à la latence des vdev, car vous effectuez simplement plus de petites lectures/écritures aléatoires par requête logique.

Avec xattr=sa, vous observez souvent :

Une latence plus faible pour les opérations riches en métadonnées lorsque les xattrs sont petits à modérés.
Un meilleur comportement du cache : moins d’objets distincts en concurrence dans l’ARC.
Une « falaise » plus nette si quelqu’un commence à remplir des xattrs volumineux partout, selon la façon dont ils débordent et la churn qu’ils créent.

2) Amplification IOPS : « une requête » devient plusieurs

Un malentendu opérationnel fréquent : « Nos clients ne font que 2k IOPS. » Puis vous examinez le pool et il en fait 20k IOPS. ZFS ne ment pas ; vous comptez la mauvaise chose.

En mode dir, la lecture d’un xattr peut impliquer plusieurs lectures de métadonnées : les métadonnées du fichier, les métadonnées du répertoire d’attribut, les métadonnées du « fichier » d’attribut, puis les données de l’attribut. Même avec le cache, l’ensemble de travail grossit rapidement dans de grandes arborescences. Si votre charge touche une large hiérarchie de dossiers, vous chamboulez l’ARC et vous déversez sur disque.

3) Espace et fragmentation : la mort par petits objets

En mode dir, chaque xattr devient un objet de type fichier. Cela gonfle le nombre d’objets et peut augmenter la fragmentation et la surcharge de métadonnées. Vous le verrez comme :

Plus d’objets DMU et de dnodes.
Traversées de métadonnées plus lourdes pendant les scrubs et la planification de réplication.
Plus de questions « pourquoi ce dataset est-il si volumineux ? » parce que vous avez créé une forêt de petits objets.

En mode sa, vous conservez typiquement les xattrs co-localisés avec d’autres métadonnées, réduisant l’explosion d’objets.

4) Comportement des sauvegardes et de la réplication

Les sauvegardes et la réplication ne déplacent pas seulement des données ; elles déplacent la structure. Plus vous créez d’objets, plus il y a de travail pour parcourir, snapshotter, envoyer et recevoir. ZFS send/receive est excellent pour déplacer des snapshots, mais il doit toujours décrire les changements. Une charge qui churn des millions de « fichiers » d’xattr peut causer :

Des envois incrémentiels plus lents parce que plus d’objets de métadonnées sont modifiés.
Des flux de réplication plus volumineux que prévu pour des « petits changements ».
Des temps de montage et de traversée de snapshot plus longs dans certains workflows.

5) La « taxe de compatibilité » est réelle

Beaucoup d’équipes choisissent dir parce que cela semble plus sûr : « C’est juste des fichiers normaux. » Cela peut être une décision correcte lorsque vous avez affaire à des piles anciennes, des clients mixtes, ou des logiciels qui se comportent mal avec le stockage de type SA. Mais c’est toujours une taxe : vous payez en latence et en surcharge de métadonnées, chaque jour, par petites incréments qui deviennent une grosse douleur opérationnelle.

Compatibilité et attentes : SMB, NFS, Linux, macOS

La plupart des problèmes de compatibilité ne sont pas des « corruptions de données ». Ce sont des « l’application attend de faire un round-trip exact des métadonnées » problèmes. Ce qui est pire, parce que tout semble correct jusqu’à ce qu’un utilisateur ouvre un fichier et que son application refuse de se comporter.

Charges locales Linux

Sur Linux avec OpenZFS, xattr=sa est couramment le choix performant par défaut pour de nombreuses déployations. Il se comporte généralement bien avec la sémantique xattr de Linux. Si vos charges utilisent fortement les étiquettes SELinux, la correction compte : perdre des xattrs pendant une restauration ou une copie entre systèmes de fichiers peut provoquer des tempêtes de relabel ou des refus d’accès. Ce n’est pas un problème ZFS, c’est votre processus — mais ZFS sera blâmé de toute façon.

Partages SMB (Samba)

Les charges SMB déclenchent souvent beaucoup d’opérations de métadonnées. Les clients Windows posent des questions sur les fichiers d’une manière bavarde : attributs, ACLs, flux alternatifs. Selon votre configuration Samba, certaines métadonnées peuvent se mapper en xattrs. Si vos xattrs sont stockés comme des objets séparés (dir), vous pouvez transformer par inadvertance « parcourir un dossier » en « effectuer un petit test de charge de métadonnées ».

Partages NFS

NFSv3 est relativement simple ; NFSv4 apporte des sémantiques plus riches, y compris les ACLs. Le mappage de ces sémantiques par votre serveur NFS peut interagir avec les métadonnées du système de fichiers. La règle générale : si vos clients effectuent beaucoup d’appels de métadonnées, choisissez le modèle de stockage xattr qui minimise le nombre d’objets de métadonnées, sauf si vous avez une raison de compatibilité démontrée de ne pas le faire.

Clients macOS

macOS est un générateur fiable de « métadonnées surprises ». Tags Finder, flags de quarantaine, et métadonnées d’application peuvent apparaître comme des xattrs. Si vous avez des équipes créatives utilisant des apps macOS sur SMB, vous verrez une forte utilisation des xattrs. C’est là que dir peut créer une surcharge notable, car vous transformez beaucoup de « petites touches de métadonnées » en multiples opérations d’objet système de fichiers.

Détail opérationnel : les utilisateurs macOS peuvent être les premiers à se plaindre que « le réseau est lent », parce que leurs workflows créent beaucoup d’aller-retours de métadonnées. Ils n’ont pas tort ; ils mesurent juste un goulot d’étranglement différent.

Tâches pratiques : commandes, sorties et interprétation

L’objectif ici n’est pas de déverser des commandes. C’est de vous donner des tâches à exécuter lors d’une revue de changement, d’une enquête sur les performances, ou d’un postmortem. Certaines commandes ciblent Linux (OpenZFS sur Linux), mais le modèle mental s’applique à toutes les plateformes.

Tâche 1 : Vérifier le mode xattr actuel sur un dataset

cr0x@server:~$ zfs get -H -o name,property,value xattr tank/projects
tank/projects	xattr	sa

Interprétation : Vous utilisez les system attributes. Si c’est une charge riche en métadonnées (home dirs SMB, espaces CI, arbres de sources), c’est généralement le choix favorisant les performances sauf si vous avez une contrainte de compatibilité spécifique.

Tâche 2 : Vérifier les propriétés de dataset liées qui influencent les performances des métadonnées

cr0x@server:~$ zfs get -o name,property,value -s local,default atime,recordsize,primarycache,acltype,xattr tank/projects
NAME          PROPERTY      VALUE
tank/projects  atime         off
tank/projects  recordsize    128K
tank/projects  primarycache  all
tank/projects  acltype       posixacl
tank/projects  xattr         sa

Interprétation : atime=off réduit le churn d’écriture sur les lectures. primarycache=all permet le caching des métadonnées et données. Aucun de ces réglages ne compense un mauvais mode xattr, mais ils peuvent cacher ou révéler le problème.

Tâche 3 : Voir si votre charge effectue réellement des appels xattr

cr0x@server:~$ sudo strace -f -tt -e trace=getxattr,setxattr,listxattr,removexattr -p 12345
12:11:09.210519 getxattr("/srv/projects/repo/.git/index", "user.foo", 0x7ffd8d7a2c10, 4096) = -1 ENODATA (No data available)
12:11:09.211004 listxattr("/srv/projects/repo/.git/index", 0x7ffd8d7a3c20, 4096) = 0

Interprétation : Si vous voyez beaucoup de getxattr/listxattr pendant des opérations courantes, le choix de stockage des xattr peut être un facteur de performance de premier ordre, pas une erreur d’arrondi.

Tâche 4 : Inspecter les xattrs d’un fichier (et vérifier le round-trip)

cr0x@server:~$ setfattr -n user.testkey -v "hello" /srv/projects/file1
cr0x@server:~$ getfattr -d /srv/projects/file1
# file: srv/projects/file1
user.testkey="hello"

Interprétation : Cela valide la fonctionnalité xattr côté client. Cela ne prouve pas les performances, mais cela prouve la sémantique.

Tâche 5 : Micro-benchmark set/get xattr sur de nombreux fichiers

cr0x@server:~$ mkdir -p /srv/projects/xattrbench
cr0x@server:~$ cd /srv/projects/xattrbench
cr0x@server:~$ time bash -c 'for i in $(seq 1 50000); do echo x > f.$i; setfattr -n user.k -v v f.$i; done'
real	0m42.381s
user	0m6.992s
sys	0m34.441s

Interprétation : Le temps sys vous indique que vous faites beaucoup de travail noyau. Répétez cela sur des datasets avec xattr=sa vs xattr=dir et observez le delta. Exécutez-le deux fois ; la première exécution réchauffe les caches et crée les objets, la seconde teste le comportement en régime établi.

Tâche 6 : Vérifier les stats ARC pour voir si vous perdez la bataille du cache de métadonnées

cr0x@server:~$ arcstat 1 5
    time  read  miss  miss%  dmis  dm%  pmis  pm%  arcsz     c
12:14:01   812   144     17   122   85    22   15   12.3G  16.0G
12:14:02   901   211     23   185   88    26   12   12.3G  16.0G
12:14:03   840   199     23   171   86    28   14   12.3G  16.0G
12:14:04   799   225     28   201   89    24   11   12.3G  16.0G
12:14:05   820   210     26   188   90    22   10   12.3G  16.0G

Interprétation : Un taux de miss élevé pendant une activité riche en métadonnées signifie que vous forcez des petites lectures aléatoires. Si xattr=dir multiplie les objets, cela peut vous pousser dans cet état plus rapidement.

Tâche 7 : Surveiller les E/S du pool en reproduisant le problème

cr0x@server:~$ iostat -x 1
Device            r/s     w/s   rKB/s   wKB/s  await  svctm  %util
nvme0n1         1200     980   14500   12200   6.20   0.35   78.0
nvme1n1         1180     960   14100   12050   6.10   0.34   76.5

Interprétation : La douleur liée aux métadonnées se manifeste par des IOPS plus élevés et un await plus élevé sans débit impressionnant. Si les utilisateurs se plaignent « copier des fichiers est lent » mais que vous voyez peu de Mo/s et beaucoup d’IOPS, vous êtes probablement limité par les métadonnées, pas par la bande passante.

Tâche 8 : Voir les I/O logiques et la latence par dataset (OpenZFS)

cr0x@server:~$ zpool iostat -v 1
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
tank        2.10T  5.12T   2.3K   2.0K   38.1M  21.4M
  mirror    2.10T  5.12T   2.3K   2.0K   38.1M  21.4M
    nvme0      -      -   1.2K   1.0K   19.1M  10.8M
    nvme1      -      -   1.1K   1.0K   19.0M  10.6M

Interprétation : Si la charge est principalement métadonnées, attendez-vous à des ops élevées par rapport au débit. Comparez le comportement avant/après un changement de mode xattr (ou entre datasets) pour quantifier la taxe.

Tâche 9 : Vérifier que les xattrs sont préservés dans les sauvegardes (exemple tar)

cr0x@server:~$ mkdir -p /srv/projects/backup-test
cr0x@server:~$ echo data > /srv/projects/backup-test/a
cr0x@server:~$ setfattr -n user.keep -v yes /srv/projects/backup-test/a
cr0x@server:~$ tar --xattrs -cpf /tmp/backup-test.tar -C /srv/projects backup-test
cr0x@server:~$ rm -rf /srv/projects/backup-test
cr0x@server:~$ tar --xattrs -xpf /tmp/backup-test.tar -C /srv/projects
cr0x@server:~$ getfattr -d /srv/projects/backup-test/a
# file: srv/projects/backup-test/a
user.keep="yes"

Interprétation : Ne supposez pas que votre outil de sauvegarde préserve les xattrs par défaut. Vérifiez-le. Si vous stockez des données de sécurité ou d’état applicatif dans des xattrs, « ça a restauré » n’est pas la même chose que « ça a correctement restauré ».

Tâche 10 : Snapshot puis send/receive, ensuite confirmer le round-trip des xattrs

cr0x@server:~$ zfs snapshot tank/projects@xattrtest
cr0x@server:~$ zfs send -v tank/projects@xattrtest | zfs receive -u tank/restore/projects
send from @xattrtest estimated size is 2.31G
total estimated size is 2.31G
TIME        SENT   SNAPSHOT
00:00:12   2.31G  tank/projects@xattrtest

cr0x@server:~$ zfs mount tank/restore/projects
cr0x@server:~$ getfattr -d /tank/restore/projects/backup-test/a
# file: tank/restore/projects/backup-test/a
user.keep="yes"

Interprétation : La réplication ZFS devrait préserver la sémantique du système de fichiers, y compris les xattrs, parce qu’elle réplique des snapshots ZFS. Validez néanmoins. Le mode de défaillance réel est souvent pas ZFS send/receive ; c’est une étape intermédiaire où quelqu’un a copié les données hors de ZFS avec un outil qui a supprimé les xattrs.

Tâche 11 : Identifier si `xattr=dir` a créé beaucoup d’objets d’attributs cachés

cr0x@server:~$ sudo zdb -dddd tank/projects | head -n 30
Dataset tank/projects [ZPL], ID 123, cr_txg 5, 1.23T, 18.4M objects
    dnode flags: USED_BYTES USERUSED_ACCOUNTED USEROBJUSED_ACCOUNTED
    microzap: 2048 bytes, 18 entries
    path		/srv/projects
    ...

Interprétation : Les comptes d’objets comptent. Si vous voyez un nombre d’objets inattendu sur un dataset « majoritairement petits fichiers », et que vous savez aussi que les xattrs sont courants, xattr=dir est suspect parce qu’il augmente le fan-out d’objets. (Utilisez zdb prudemment ; c’est puissant et ce n’est pas un jouet.)

Tâche 12 : Vérifier si le mode xattr peut être changé et ce que cela affecte

cr0x@server:~$ zfs set xattr=sa tank/projects
cr0x@server:~$ zfs get -H -o name,property,value xattr tank/projects
tank/projects	xattr	sa

Interprétation : Définir la propriété change la façon dont les nouveaux xattrs sont stockés à l’avenir ; cela ne réécrit pas nécessairement le monde instantanément. Les xattrs existants peuvent rester dans leur représentation d’origine jusqu’à ce que les fichiers soient modifiés d’une manière qui déplace/réécrive les xattrs. Planifiez les migrations en conséquence et testez avec des datasets représentatifs.

Tâche 13 : Détecter des arbres de répertoires lourds en xattr (approche d’échantillonnage)

cr0x@server:~$ find /srv/projects -type f -maxdepth 3 -print0 | head -z -n 200 | \
  xargs -0 -n 1 bash -c 'n=$(getfattr --absolute-names -d "$0" 2>/dev/null | grep -c "^[a-z]"); echo "$n $0"' | \
  sort -nr | head
5 /srv/projects/app1/bin/tool
3 /srv/projects/app1/lib/libx.so
2 /srv/projects/app1/config/settings.json

Interprétation : C’est une technique grossière mais efficace sur le terrain : échantillonner une tranche, identifier les points chauds, puis reproduire les problèmes de performance contre ces points chauds. Vous cherchez des répertoires où les xattrs sont fréquents et les opérations nombreuses.

Tâche 14 : Confirmer si une appli est « liée aux métadonnées » en utilisant perf (Linux)

cr0x@server:~$ sudo perf stat -p 12345 -e syscalls:sys_enter_getxattr,syscalls:sys_enter_listxattr,syscalls:sys_enter_statx  -- sleep 10
 Performance counter stats for process id '12345':

         12,410      syscalls:sys_enter_statx
          8,922      syscalls:sys_enter_getxattr
          4,101      syscalls:sys_enter_listxattr

      10.001234567 seconds time elapsed

Interprétation : Si les syscalls xattr/stat dominent pendant des opérations « lentes » utilisateurs, discuter de recordsize ou de débit séquentiel est surtout de la mise en scène. Vous devez réduire l’amplification des métadonnées : caching, mode xattr, et modèles de charge.

Méthode de diagnostic rapide

Ceci est le workflow « vous avez 20 minutes avant l’appel post-incident ». L’ordre compte.

Première étape : prouvez que c’est des métadonnées, pas de la bande passante

Vérifier iostat : IOPS élevés, faible Mo/s, latence en hausse implique métadonnées ou petites E/S aléatoires.
Vérifier le comportement client : utilisez strace ou les logs d’appli pour voir des tempêtes de getxattr/listxattr.
Vérifier l’utilisation du pool et l’await : si %util est élevé et await augmente, vous faites la queue pour des petites opérations.

Deuxième étape : confirmer le modèle de stockage xattr et l’intensité xattr de la charge

Vérifier la propriété du dataset : zfs get xattr.
Échantillonner les xattrs : utilisez une find/getfattr ciblée dans l’arborescence de dossier chaude.
Chercher les couches de compatibilité liées aux xattrs : modules vfs Samba, comportement des métadonnées macOS, schémas de labellisation SELinux.

Troisième étape : valider le caching et la pression mémoire

Taux de miss ARC : des misses élevés pendant une tempête de métadonnées signifient que l’ensemble de travail dépasse la mémoire ou est trop riche en objets.
Contention mémoire système : vérifier le swap ou un reclaim agressif ; un ARC sous pression peut faire chuter les opérations de métadonnées.
vdev spécial (si présent) : confirmez qu’il est sain et sert réellement les métadonnées comme prévu ; un vdev métadonnées dégradé peut rendre tout « mystérieusement lent ».

Quatrième étape : décider du levier

Si le dataset est xattr=dir et que vous avez une charge riche en xattr sans raison de compatibilité stricte, le levier est généralement : passer à sa pour les nouvelles écritures et planifier une migration contrôlée pour réécrire les xattrs existants (souvent en copiant les données à l’intérieur de ZFS avec un outil qui préserve les xattrs, ou en utilisant rsync avec les options qui les préservent réellement).

Si le dataset est déjà sa, concentrez-vous sur : comportement applicatif (churn d’xattr), caching/mémoire, périphérique métadonnées, et configuration de la pile protocole (tuning SMB/NFS) plutôt que d’attendre qu’une propriété ZFS magique règle tout.

Trois mini-histoires du monde de l’entreprise (réalistes, pénibles, instructives)

Mini-histoire n°1 : Un incident causé par une fausse hypothèse

Contexte : une entreprise de taille moyenne avec une plateforme Git interne et un « partage d’artéfacts » séparé utilisé par les pipelines CI. Le partage d’artéfacts vivait sur ZFS. L’équipe avait récemment migré depuis un ancien NAS et avait essayé de garder les choses « aussi compatibles que possible », ce qui s’était traduit par le choix de xattr=dir parce que cela semblait conservateur et semblable à des fichiers.

Pendant un temps, tout avait l’air normal. Les graphiques de débit étaient sains. Le pool avait de la marge. Le réseau n’était pas saturé. Puis un nouveau workflow CI est arrivé : des milliers de jobs parallèles, chacun décompressant des archives contenant beaucoup de petits fichiers, certains avec des xattrs, suivi d’un scan intensif (les outils de sécurité adorent les métadonnées). Le premier symptôme fut vague : « les builds sont aléatoirement lents ». Puis cela a escaladé en « le partage timeoute ».

La mauvaise hypothèse était classique : ils pensaient que le goulot d’étranglement se verrait comme du débit. Ils ont donc réglé le recordsize. Ils ont blâmé le réseau. Ils ont même remplacé un switch. Rien n’a aidé car la charge faisait une tempête de recherches de métadonnées. Chaque lecture d’xattr en dir signifiait des traversées d’objets supplémentaires. Les IOPS étaient là, mais la latence tail était meurtrière.

Quand ils ont finalement tracé la latence p99 au niveau du stockage et corrélé cela au nombre d’appels getxattr provenant d’un worker CI tracé, l’histoire est devenue évidente. Passer les nouvelles écritures en xattr=sa et migrer les chemins de build les plus chauds vers un nouveau dataset a réduit l’amplification des métadonnées. L’incident s’est terminé non pas par une mise à niveau matérielle héroïque, mais par un changement de propriété et un déplacement de données soigneux.

Le postmortem était franc : « la ‘compatibilité’ n’est pas gratuite. Si vous ne dites pas avec quoi vous êtes compatible, vous achetez juste un coût sans client. »

Mini-histoire n°2 : Une optimisation qui s’est retournée contre eux

Une autre entreprise, une douleur différente. Celle-ci gérait un service SMB multi-tenant pour des départements internes. Quelqu’un a remarqué que les listings de répertoires et les ouvertures de fichiers étaient plus lents pour un tenant que pour d’autres. Ils avaient entendu — correctement — que xattr=sa peut améliorer les performances. Ils l’ont appliqué largement et ont passé à autre chose.

Deux semaines plus tard, une équipe créative a commencé à signaler des comportements étranges : les fichiers se copiaient, mais certaines métadonnées d’apps ne persistaient pas comme attendu à travers un workflow spécifique impliquant des clients macOS et un outil d’intégration ancien qui touchait aux métadonnées de façon non standard. Ce n’était pas une « perte de données » dramatique. C’était « l’application ne fait plus confiance au partage », ce qui est pire opérationnellement car les utilisateurs interprètent cela comme une fiabilité défaillante.

La cause racine n’était pas que xattr=sa soit cassé ; c’était qu’un workflow en bordure dépendait d’une représentation particulière et d’un comportement de taille des xattrs, et l’outil d’intégration faisait quelque chose de fragile. Le changement n’a pas échoué immédiatement parce que la plupart des clients ne déclenchaient pas ce chemin. L’échec est apparu quand un grand nombre de fichiers a franchi un seuil de taille et churn des métadonnées. L’équipe de stockage avait optimisé correctement pour la majorité, mais sans une suite de tests de compatibilité pour la minorité.

La correction n’a pas été « revenir en arrière ». Ils ont créé des datasets séparés : des paramètres orientés performance pour la plupart des tenants, et un dataset orienté compatibilité pour le département avec le workflow legacy. Ils ont documenté l’attente : si vous avez besoin de ce workflow, vous payez consciemment la taxe métadonnées. Ils ont aussi travaillé avec l’équipe applicative pour moderniser l’intégration, mais cela a pris plus de réunions.

La leçon : le danger n’est pas d’optimiser ; c’est d’optimiser à l’aveugle. Les changements de performance sont aussi des changements de comportement quand la sémantique des métadonnées fait partie du contrat applicatif.

Mini-histoire n°3 : Une pratique ennuyeuse mais correcte qui a sauvé la mise

Celle-ci est moins dramatique, ce qui explique pourquoi c’est celle que vous devriez copier.

Une organisation finance gérait des services de fichiers sur ZFS et avait des exigences strictes de restauration. Pas juste « restaurer les fichiers », mais « restaurer les fichiers de sorte que les contrôles d’accès et les étiquettes se comportent correctement ». Ils traitaient les xattrs comme des données de première classe. Chaque job de vérification de sauvegarde incluait une petite suite de tests : créer un fichier, définir quelques xattrs représentatifs (namespace user et quelques-unes à connotation sécurité), snapshotter, répliquer, restaurer dans un bac à sable, puis vérifier le round-trip des xattrs et que les applis clés pouvaient lire leurs métadonnées sans les réécrire.

Pendant une migration de stockage, un contractant a proposé une méthode de copie plus rapide « parce que ce ne sont que des fichiers ». La suite de tests de l’organisation a échoué immédiatement : les xattrs ne survivaient pas à cette méthode. Le contractant n’était pas malveillant ; il optimisait juste pour la partie visible du système de fichiers.

Parce que l’équipe avait une checklist ennuyeuse, ils ont détecté la rupture avant qu’elle ne devienne un problème de conformité ou une surprise du lundi matin. Ils ont utilisé un chemin de copie/réplication qui préservait les xattrs et ACLs, accepté le temps plus long, et ont continué. Pas d’incident. Pas de drame utilisateur. Juste la satisfaction tranquille d’un système qui se comporte comme un système.

La leçon : si vous ne testez pas continuellement la préservation des xattrs, vous ne « supposez pas que ça marche ». Vous reportez la découverte de la façon dont ça échoue.

Erreurs courantes (avec symptômes et correctifs)

Erreur 1 : Choisir `xattr=dir` « pour la sécurité » sur une charge riche en métadonnées

Symptômes : navigation de dossier sur SMB lente ; pipelines CI ralentis avec beaucoup de petits fichiers ; stockage montre IOPS élevés et latence sans gros débit ; utilisateurs disent « délais aléatoires ».

Correctif : utilisez xattr=sa pour les datasets servant des charges riches en métadonnées sauf si vous avez une contrainte de compatibilité démontrée. Migrer les arbres chauds vers un nouveau dataset et mesurer avant/après.

Erreur 2 : Changer `xattr` en s’attendant à ce que les fichiers existants se réécrivent magiquement

Symptômes : vous passez à sa et rien ne s’améliore ; les performances n’améliorent que pour les nouveaux fichiers ; comportement mixte entre répertoires.

Correctif : planifiez une stratégie de migration. La réécriture des métadonnées nécessite souvent la réécriture des fichiers (par ex., copie à l’intérieur du système de fichiers avec un outil qui préserve les xattrs, ou envoi/ réception ZFS dans un nouveau dataset puis échange des points de montage).

Erreur 3 : Perdre les xattrs pendant copie/restauration

Symptômes : tempêtes de relabel SELinux ; apps perdent de l’état ; métadonnées macOS disparaissent ; permissions « semblent correctes » mais le comportement est faux ; outils de conformité signalent des changements après restauration.

Correctif : standardisez les outils et options de sauvegarde/restauration qui préservent les xattrs, et testez la restauration en vérifiant des xattrs représentatifs après restauration.

Erreur 4 : Diagnostiquer à tort une douleur liée aux métadonnées comme des « problèmes réseau »

Symptômes : graphiques réseau montrent une faible utilisation ; SMB/NFS semble lent ; ping est correct ; tests de débit semblent acceptables, pourtant la navigation et les opérations de fichiers sont lentes.

Correctif : mesurez les patterns de syscalls et la latence stockage. Si les IOPS sont élevés et les Mo/s faibles, attaquez l’amplification des métadonnées (mode xattr, caching, compte d’objets, vdevs spéciaux).

Erreur 5 : Laisser proliférer de gros xattrs sans les remarquer

Symptômes : augmentation soudaine du churn d’écriture des métadonnées ; snapshots qui grossissent plus vite que prévu ; flux de réplication plus volumineux que prévu ; régressions de performance liées à un déploiement d’application spécifique.

Correctif : auditez les tailles et les patterns d’xattr. Travaillez avec les propriétaires d’application pour plafonner ou repenser. Utilisez un échantillonnage ciblé pour identifier les répertoires/fichiers avec beaucoup ou de gros xattrs, puis validez si sa reste approprié.

Erreur 6 : Faire des benchmarks avec la mauvaise charge

Symptômes : tests séquentiels synthétiques excellents ; utilisateurs réels se plaignent ; décisions de tuning ne corrèlent pas avec les améliorations.

Correctif : faites des benchmarks avec des outils lourds en métadonnées et des arbres de répertoires représentatifs. Incluez les opérations set/get/list xattr et les traversées de répertoires sous concurrence.

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

Checklist A : Choisir le mode xattr pour un nouveau dataset

Identifier les clients et protocoles : SMB ? NFS ? Linux local ? beaucoup de macOS ?
Identifier les besoins sémantiques xattr : étiquettes SELinux ? métadonnées Windows ? xattrs applicatives ?
Classer la charge : principalement gros fichiers (média) vs petits fichiers (arbres source, home dirs, artefacts CI).
Par défaut privilégier la performance lorsque c’est sûr : choisir xattr=sa pour les arbres riches en métadonnées sauf blocage de compatibilité.
Documenter la décision : « Nous avons choisi dir pour le test de compatibilité X », ou « Nous avons choisi sa car la charge est riche en métadonnées et les clients sont validés. »

Checklist B : Migrer de `xattr=dir` vers `xattr=sa` en toute sécurité

Créer un nouveau dataset avec les propriétés désirées (y compris xattr=sa) et le monter dans un chemin de mise en scène.
Choisir une méthode de migration qui préserve xattrs et ACLs ; valider sur un petit arbre pilote d’abord.
Faire des benchmarks avant/après sur la charge chaude : listing de répertoire, ouverture de fichier, tests de tempêtes get/list xattr.
Basculer avec un plan de rollback : utiliser des échanges de mountpoint ou des bascules de symlink ; garder l’ancien dataset en lecture seule jusqu’à validation.
Vérifier la sémantique : spot-check des xattrs, ACLs, et comportement applicatif sur des clients représentatifs.
Surveiller la latence p95/p99 et le taux de miss ARC après le cutover ; assurez-vous de ne pas avoir troqué un goulot d’étranglement pour un autre.

Checklist C : Garde-fous opérationnels (en continu)

Inclure des tests round-trip xattr dans la vérification des sauvegardes et les répétitions DR.
Suivre les comptes d’objets et le churn des métadonnées pour les datasets connus pour héberger des petits fichiers.
Alertes sur les queues de latence tail plutôt que seulement le débit moyen.
Garder un « dataset de compatibilité connu » pour les workflows legacy au lieu d’imposer un mode unique partout.

FAQ

1) Que contrôle réellement la propriété ZFS `xattr` ?

Elle contrôle comment les attributs étendus sont stockés sur disque pour ce dataset : soit comme objets séparés dans un répertoire d’attribut (dir), soit dans l’aire d’attribut système (sa). Ce choix change le nombre d’objets de métadonnées et le comportement des recherches.

2) Lequel est plus rapide, `xattr=sa` ou `xattr=dir` ?

Pour les charges avec beaucoup de petits à moyens xattrs et beaucoup d’opérations de métadonnées, sa est généralement plus rapide parce qu’il réduit les recherches et la surcharge d’objets. dir peut être plus lent à cause des objets supplémentaires, mais peut être préféré pour des contraintes de compatibilité spécifiques ou des patterns impliquant des xattrs volumineux.

3) Changer `xattr` réécrira-t-il les xattrs existants ?

Pas automatiquement d’une manière sur laquelle vous devriez parier votre week-end. La propriété affecte comment les xattrs sont stockés à l’avenir, mais les fichiers existants peuvent garder leur représentation actuelle jusqu’à réécriture. Si vous avez besoin d’un comportement homogène sur les données existantes, planifiez une migration qui réécrit les fichiers/xattrs.

4) Les xattrs peuvent-ils causer une « navigation SMB lente » ?

Oui. Les clients SMB peuvent être bavards en métadonnées, et si chaque requête de métadonnées déclenche des recherches supplémentaires pour les xattrs (surtout en dir), les listings et ouvertures de fichiers peuvent être lents même si le débit et l’utilisation du réseau semblent corrects.

5) Les xattrs sont-ils importants pour la sécurité ?

Ils peuvent l’être. Les étiquettes SELinux résident dans les xattrs, et de nombreux systèmes stockent des métadonnées liées aux ACLs via des xattrs ou des structures adjacentes. Supprimer les xattrs pendant une sauvegarde/restauration peut entraîner des refus d’accès, des tempêtes de relabel, ou des violations subtiles de politique.

6) ZFS send/receive préserve-t-il les xattrs ?

En général, la réplication ZFS préserve la sémantique du dataset, y compris les xattrs, puisque c’est la réplication des snapshots ZFS. Le risque majeur est de copier les données en dehors de ZFS avec un outil ou des options qui ne préservent pas les xattrs, puis de restaurer « avec succès » mais incorrectement.

7) Comment savoir si ma charge est riche en xattr ?

Tracez-la. Utilisez strace ou perf pour compter les syscalls liés aux xattrs pendant l’opération lente. Ensuite, échantillonnez les répertoires chauds avec getfattr. Si vous voyez beaucoup d’activité getxattr/listxattr, le stockage des xattr fait partie de votre profil de performance.

8) Si j’utilise déjà `xattr=sa` et que c’est encore lent, que faire ensuite ?

Regardez le taux de miss ARC (ensemble de travail de métadonnées trop grand), la latence de stockage (queueing vdev), et le comportement du protocole/client (réglages SMB, tempêtes de métadonnées macOS, apps réécrivant les xattrs). Considérez aussi si les xattrs sont inhabituellement volumineux ou fréquemment réécrits, ce qui peut transformer les métadonnées en amplification d’écriture.

9) `xattr=dir` a-t-il encore un sens aujourd’hui ?

Oui — quand vous avez une exigence de compatibilité prouvée, un workflow legacy qui dépend d’un comportement particulier, ou lorsque de gros xattrs sont courants et que vous préférez les stocker comme objets réguliers. L’important est de le choisir intentionnellement pour ces datasets, pas par défaut partout.

10) Quelle est l’approche la plus simple et sûre pour un environnement mixte ?

Séparez les datasets selon la charge et le type de client. Utilisez xattr=sa pour les charges modernes et riches en métadonnées après tests. Gardez un dataset de compatibilité distinct avec xattr=dir pour les intégrations legacy ou pointilleuses. Documentez quelles équipes sont sur quel dataset et pourquoi.

Conclusion

Les xattrs ZFS sont l’un de ces sujets « petits » qui décident si votre service de fichiers semble réactif ou maudit. La propriété xattr n’est pas juste un interrupteur ; c’est un choix structurel sur le nombre d’objets de métadonnées que votre charge va générer et sur le nombre de recherches qu’exigera chaque opération. Dans des environnements à grande échelle — arbres CI, home dirs SMB, partages créatifs, caches de build de conteneur — cette différence devient visible par les utilisateurs sous forme de latence.

Choisissez xattr=sa quand la performance compte et que la compatibilité est validée. Choisissez xattr=dir quand la compatibilité est l’exigence et que vous êtes prêt à payer la taxe métadonnées. Ensuite faites la chose vraiment professionnelle : testez la préservation, mesurez la latence tail, et n’autorisez plus jamais un « ce n’est que des métadonnées » dans une demande de changement sans un benchmark joint.