ZFS SMB : corriger définitivement « Copie Windows lente »

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

Cet article vous a aidé ?

Explorateur Windows indique « Copie… 112 MB/s » pendant trois secondes, puis passe à 0 B/s et reste figé comme s’il réfléchissait à sa vie. Les utilisateurs accusent « le réseau ». Le réseau renvoie la faute au « stockage ». Le stockage blâme « Windows ». Chacun a tort, mais de façons différentes.

Si vous exécutez SMB basé sur ZFS (généralement Samba sur Linux, parfois sur une appliance de stockage), vous pouvez rendre les copies Windows constamment rapides. Mais on n’y arrive pas en tournant des boutons au hasard. Il faut prouver d’où vient la latence, puis corriger la partie précise qui ment.

Ce que « copie lente » signifie réellement (et ce que ce n’est pas)

« Explorateur Windows lent » n’est pas un problème unique. C’est un symptôme visible par l’utilisateur d’un pipeline qui inclut : le comportement du client Windows, les sémantiques du protocole SMB, les détails d’implémentation de Samba, les groupes de transactions et chemins d’écriture de ZFS, et la latence du média physique. Votre tâche est de trouver l’étape qui transforme le débit en attente.

Les trois schémas de copie à dissocier

Copies séquentielles volumineuses (par ex., ISO, VHDX) : devraient se rapprocher du débit du lien jusqu’à ce que le serveur ne puisse plus engager les écritures.
Beaucoup de petits fichiers (par ex., arbres de source) : dominés par les métadonnées (create, setattr, close, rename), pas par le débit brut.
Workloads mixtes (partages personnels + VM + scanners) : « lent » est souvent un blocage tête-de-file : un mauvais motif ruine la file d’attente pour tout le monde.

Ce que ce n’est généralement pas

Ce n’est rarement « SMB est lent ». SMB3 peut être très rapide. Ce n’est rarement « ZFS est lent ». ZFS peut saturer des réseaux sérieux. C’est généralement des pics de latence causés par des écritures sync, des I/O aléatoires petits, une amplification des métadonnées, ou un mauvais alignement du cache, rendus visibles par un client qui rapporte des vitesses en rafales optimistes.

Un autre changement de perspective : Explorateur Windows n’est pas un outil de benchmark ; c’est un visualiseur d’anxiété. Ce graphique est plus un indicateur d’humeur qu’un oscilloscope.

Faits intéressants et contexte historique (pour comprendre le comportement)

SMB1 vs SMB2/3 a tout changé. SMB2 (ère Vista/2008) a réduit la verbosité, permis des lectures/écritures plus grandes et le pipelining. Beaucoup d’histoires « SMB lent » sont en réalité « vous êtes coincé sur SMB1 ».
Samba a commencé comme un projet d’ingénierie inverse. Il est passé de « faire communiquer UNIX et Windows » à un serveur SMB de niveau entreprise. Certains paramètres par défaut sont conservateurs parce que Samba doit survivre à des clients bizarres.
Les écritures ZFS sont regroupées. ZFS engage les données par groupes de transactions (TXG). Cela rend le débit excellent, mais crée aussi un comportement en « pulsation » visible si la phase de commit cale.
Les écritures sync sont une promesse, pas une sensation. Quand un client SMB demande de la durabilité, ZFS doit engager de façon sûre. Si votre pool ne peut pas faire des fsync à faible latence, vous obtenez le fameux graphe « rapide puis zéro ».
Les durable handles et leases SMB ont modifié le comportement close/open. Les versions modernes de Windows mettent en cache agressivement. C’est bien, jusqu’à ce qu’une application impose des sémantiques de durabilité et transforme le caching en douleur synchrone.
Le recordsize compte plus pour les partages que la plupart l’admettent. recordsize ZFS façonne l’amplification I/O. Un mauvais recordsize n’économise pas seulement l’espace — il force des IOPS supplémentaires sous accès aléatoire petit.
La compression aide souvent SMB, même sur CPU rapide. Beaucoup de fichiers bureautiques se compressent bien, réduisant le coût disque et réseau. Le bénéfice est souvent sur la latence, pas le seul débit.
Le signing SMB est devenu plus courant pour la sécurité. Activer le signing peut coûter du CPU. Le réglage « sécurisé » devient parfois « sécurisé mais lent » quand le serveur a un CPU faible ou un seul cœur saturé.

Feuille de route pour un diagnostic rapide

Ceci est l’ordre qui trouve rapidement le goulot d’étranglement, sans tomber dans le piège « on règle tout ».

Premier : classer le workload

Un gros fichier ? Beaucoup de petits fichiers ? Applications qui exigent la durabilité ?
La vitesse chute-t-elle à intervalles réguliers (toutes les quelques secondes) ? Ça sent les commits TXG.
Est-ce que ça n’arrive que sur certains partages ? Ça sent les propriétés du dataset ou des options de partage SMB.

Deuxième : décider si c’est réseau, CPU ou latence stockage

Réseau : erreurs d’interface, retransmissions, MTU incorrecte, hashing LACP défaillant, clients Wi‑Fi se faisant passer pour des serveurs.
CPU : un cœur saturé dans smbd, surcharge liée au signing/chiffrement, interruptions, saturation softirq.
Latence stockage : await élevé sur les vdevs, chemin sync ZFS bloqué, SLOG absent/lent, pool quasi plein ou fragmenté.

Troisième : valider le comportement sync (c’est souvent le coupable)

Vérifiez la propriété dataset sync et les paramètres Samba qui forcent le sync (par ex. strict sync).
Mesurez la latence fsync depuis l’hôte SMB lui‑même, pas depuis votre portable.
Si vous avez besoin de sémantiques sync, assurez‑vous d’avoir un SLOG approprié (protégé contre la perte d’alimentation) ou acceptez les limites de performance de vos vdevs principaux.

Quatrième : isoler le cas « beaucoup de petits fichiers »

Les métadonnées sont le workload. Vérifiez atime, le comportement des xattr et les performances en petits blocs.
Vérifiez que le layout du pool correspond aux attentes IOPS pour les métadonnées (trade‑off mirrors vs RAIDZ).

Cinquième : ne tuner que ce que les mesures impliquent

Si vous ne pouvez pas montrer un avant/après sur la latence I/O, l’utilisation CPU ou les retransmissions, vous ne faites pas du tuning — vous décorez.

Arrêtez de deviner : mesurer où passe le temps

Les copies SMB sont une négociation entre un client qui met en tampon et un serveur qui engage. Explorateur rapporte la « vitesse » basée sur la rapidité d’acceptation dans les tampons, pas sur la vitesse d’écriture durable. Pendant ce temps, ZFS peut accepter les données rapidement dans l’ARC et les tampons sales, puis faire une pause pendant le commit des TXG. Cette pause est là où le graphe tombe à zéro.

Votre plan de mesure doit répondre à trois questions :

Le client attend‑il le serveur (latence), ou n’envoie‑t‑il pas (throttling côté client) ?
Le serveur attend‑il des flush disque (chemin sync), ou du CPU (signing/chiffrement), ou le réseau ?
ZFS amplifie‑t‑il le workload (mismatch recordsize, fragmentation, pression sur les métadonnées) ?

L’ingénierie de la fiabilité a une règle simple applicable ici : mesurez le système que vous avez, pas celui que vous voudriez avoir.

Idée paraphrasée (Gene Kim) : « Améliorer le flux signifie trouver et supprimer la contrainte. » C’est tout le jeu.

Réelités ZFS qui gênent SMB

TXG et le motif « rapide puis zéro »

ZFS accumule des données sales en mémoire et les commit périodiquement sur disque comme un groupe de transactions. Si la phase de commit prend trop de temps, le système bride les écrivains. Du point de vue du client : rafale rapide, puis blocage. Répéter. Ce n’est pas « jitter réseau ». C’est la durabilité stockage qui rattrape son retard.

Écritures sync : la taxe de durabilité

Quand le workload émet des écritures synchrones (ou que le serveur les traite ainsi), ZFS doit garantir que les données sont sur un stockage stable avant d’acquitter. Sur des pools sans device intent log rapide, les écritures sync frappent vos vdevs principaux. Si ceux‑ci sont en RAIDZ sur HDD, vous pouvez prédire le résultat : douleur avec horodatage.

Recordsize, ashift et amplification I/O

Le recordsize ZFS contrôle la taille maximale de bloc pour les données de fichier. Les partages SMB stockent souvent des tailles de fichiers mixtes ; un recordsize trop grand n’altère pas toujours les lectures séquentielles, mais peut nuire aux écritures aléatoires et aux réécritures partielles. Trop petit peut augmenter la surcharge de métadonnées et réduire l’efficacité de la compression.

Les métadonnées ne sont pas « gratuites »

Les copies de petits fichiers stressent les métadonnées : entrées de répertoire, ACL, xattrs, horodatages. ZFS peut gérer cela correctement, mais seulement si le layout du pool et le caching sont sensés. Si vous avez construit un large RAIDZ pour la capacité puis l’avez converti en partage SMB chargé en métadonnées, vous avez essentiellement acheté un bus et l’avez inscrit à une course de motos.

Remplissage du pool et fragmentation

À mesure que les pools se remplissent, l’allocation devient plus difficile, la fragmentation augmente et la latence grimpe. Les utilisateurs SMB vivent cela comme « c’était bien le mois dernier ». ZFS n’oublie pas soudainement comment écrire ; il manque des endroits faciles pour placer les blocs.

Réelités SMB qui gênent ZFS

Les sémantiques de copie Windows : buffering, close et durabilité

Windows peut mettre en tampon les écritures et n’imposer la durabilité qu’à la fermeture du fichier, selon les flags de l’application et la configuration du serveur. Certaines applis (et certains outils de sécurité) demandent des écritures write‑through. Cela transforme instantanément votre workload de « principalement async » en « lourdement sync ».

Signing et chiffrement : la sécurité a un coût CPU

Le signing SMB est souvent imposé par une politique. Le chiffrement peut être activé pour certains partages. Les deux consomment du CPU. Si votre serveur SMB a un CPU modeste avec une NIC rapide, vous pouvez atteindre un plafond où le réseau est inactif et un cœur sue en crypto.

SMB3 Multichannel : excellent quand ça marche, inutile sinon

Multichannel peut utiliser plusieurs NIC et files RSS. Mal configuré, vous obtenez exactement un flux TCP bloqué sur une file. Alors quelqu’un dit « mais on a du dual 10GbE » comme si le serveur était obligé de s’en préoccuper.

Oplocks opportunistes, leases et antivirus

Le caching client (oplocks/leases) réduit la verbosité. Mais les scanners de sécurité endpoint adorent ouvrir des fichiers, forcer des mises à jour d’attributs et casser le comportement de cache. Cela peut transformer une copie « beaucoup de petits fichiers » en un festival d’appels système.

Blague #1 : le dépannage SMB ressemble à la politique de bureau — tout le monde insiste pour être le goulot d’étranglement, et d’une certaine façon ils ont tous raison.

Tâches pratiques : commandes, sorties, décisions

Ci‑dessous des tâches réelles à exécuter sur le serveur SMB/ZFS. Chacune inclut ce que la sortie signifie et la décision suivante à prendre. Ces conseils sont orientés Linux + Samba + OpenZFS, parce que c’est là que vivent la plupart des tickets « Explorateur Windows lent ».

Task 1: Confirm pool health (because performance is often a symptom of a dying disk)

cr0x@server:~$ sudo zpool status -v tank
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 04:12:19 with 0 errors on Tue Dec 10 03:20:01 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          mirror-0                  ONLINE       0     0     0
            ata-SAMSUNG_SSD_1TB_A   ONLINE       0     0     0
            ata-SAMSUNG_SSD_1TB_B   ONLINE       0     0     0

errors: No known data errors

Signification : « ONLINE » et un scrub propre signifie que vous ne luttez pas contre des tentatives silencieuses ou une resilver en cours. Si vous voyez DEGRADED, resilvering ou checksum errors, arrêtez le tuning et corrigez d’abord le matériel.

Décision : Si un vdev montre des erreurs ou une resilver, planifiez une remédiation et retestez les performances après stabilisation.

Task 2: Check pool fullness (near-full pools get slow in boring, predictable ways)

cr0x@server:~$ zfs list -o name,used,avail,refer,mountpoint tank
NAME   USED  AVAIL  REFER  MOUNTPOINT
tank   38.2T 2.1T   96K    /tank

Signification : ~95% utilisé (38.2T used, 2.1T avail) est un territoire dangereux pour beaucoup de workloads. L’allocation devient contrainte ; la fragmentation augmente.

Décision : Si vous êtes au‑dessus de ~80–85% utilisé et que la performance compte, planifiez de récupérer de l’espace ou d’étendre. Aucun réglage Samba ne battra la physique.

Task 3: Identify which dataset backs the SMB share and dump its key properties

cr0x@server:~$ sudo zfs get -H -o property,value recordsize,compression,atime,sync,xattr,acltype,primarycache,logbias tank/shares/engineering
recordsize	1M
compression	lz4
atime	on
sync	standard
xattr	sa
acltype	posixacl
primarycache	all
logbias	latency

Signification : Vous avez recordsize=1M (bon pour gros fichiers séquentiels, risqué pour réécritures partielles), atime activé (écritures métadonnées supplémentaires), sync standard (sync honoré), xattr en SA (souvent bon), logbias latency (préférence SLOG si présent).

Décision : Si le partage est « beaucoup de petits fichiers », envisagez recordsize=128K et atime=off. Si ce sont des images VM, traitez différemment (et probablement pas via SMB).

Task 4: Measure pool I/O latency during a copy (the truth is in iostat)

cr0x@server:~$ sudo zpool iostat -v tank 1 5
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
tank                        38.2T  2.1T     12   2400   3.1M   210M
  mirror-0                  38.2T  2.1T     12   2400   3.1M   210M
    ata-SAMSUNG_SSD_1TB_A      -      -      6   1250   1.6M   108M
    ata-SAMSUNG_SSD_1TB_B      -      -      6   1150   1.5M   102M
--------------------------  -----  -----  -----  -----  -----  -----

Signification : Un grand nombre d’opérations d’écriture (2400/s) avec une bande passante modérée suggère des écritures petites ou un comportement sync‑heavy. Si la bande passante est faible mais les ops élevées, vous êtes lié aux IOPS ou aux flush.

Décision : Si les écritures sont petites et fréquentes, investiguez les sémantiques sync, la charge sur les métadonnées et un mismatch recordsize. Si les ops sont faibles et la bande passante faible, suspectez le réseau ou un throttling SMB.

Task 5: Observe per-vdev latency with iostat (await is the smoke alarm)

cr0x@server:~$ sudo iostat -x 1 3
Linux 6.6.15 (server) 	12/25/2025 	_x86_64_	(16 CPU)

Device            r/s     w/s   rkB/s   wkB/s  avgrq-sz avgqu-sz   await  r_await  w_await  svctm  %util
nvme0n1           2.0   950.0    64.0 118000.0   248.0     3.20    3.4     1.2      3.4    0.6   58.0
nvme1n1           1.0   910.0    32.0 112000.0   246.0     3.05    3.3     1.1      3.3    0.6   55.0

Signification : ~3.3ms d’await en écriture est acceptable pour NVMe. Si vous voyez des dizaines/centaines de ms pendant les copies, le stockage bride votre débit.

Décision : await élevé + CPU bas + réseau propre = problème chemin stockage (écritures sync, pool plein, vdevs lents, ou problèmes SLOG).

Task 6: Check whether you even have a SLOG (and whether it’s doing anything)

cr0x@server:~$ sudo zpool status tank | sed -n '1,120p'
  pool: tank
 state: ONLINE
config:

        NAME                         STATE     READ WRITE CKSUM
        tank                         ONLINE       0     0     0
          mirror-0                   ONLINE       0     0     0
            ata-SAMSUNG_SSD_1TB_A    ONLINE       0     0     0
            ata-SAMSUNG_SSD_1TB_B    ONLINE       0     0     0
        logs
          nvme-SLOG_INTEL_OPTANE     ONLINE       0     0     0

Signification : Il y a un device log séparé. Bien. Mais l’existence n’est pas la performance ; il doit être rapide et protégé contre la perte d’alimentation.

Décision : Si vous avez des workloads sync‑heavy et pas de SLOG, décidez si vous avez besoin des sémantiques sync. Si oui, ajoutez un SLOG adéquat. Si non, n’essayez pas de le simuler avec sync=disabled à moins d’accepter la perte d’écritures reconnues en cas de coupure.

Task 7: Watch TXG throttling and dirty data behavior

cr0x@server:~$ sudo arcstat 1 3
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  arcsz     c  avail
12:10:01   320    12      4     1    0    11    3     0    0   84.2G  96.0G  21.4G
12:10:02   410    16      3     2    0    14    3     0    0   84.2G  96.0G  21.4G
12:10:03   390    10      2     1    0     9    2     0    0   84.2G  96.0G  21.4G

Signification : L’ARC ne manque pas trop ; le caching n’est pas votre contrainte actuelle. Si l’ARC est petit par rapport à la mémoire, ou si les misses grimpent, vous pourriez être limité par la mémoire ou mal configuré.

Décision : Si les misses ARC sont élevées pendant les lectures, ajustez la taille mémoire/ARC ou le working set (ou acceptez que le workload ne se cache pas bien).

Task 8: Confirm Samba version and whether SMB3 is negotiated

cr0x@server:~$ smbd -V
Version 4.19.5-Debian

cr0x@server:~$ sudo smbstatus -b | sed -n '1,60p'
Samba version 4.19.5-Debian
PID     Username     Group        Machine                                   Protocol Version  Encryption           Signing
-------------------------------------------------------------------------------------------------------------------------
23144   user1        domain users  10.10.20.55 (ipv4:10.10.20.55:53122)     SMB3_11           -                    partial

Signification : SMB3_11 est négocié, bien. Le signing est « partial » (dépend de la config et du client). Si vous voyez SMB1, vous avez des problèmes plus graves que le tuning.

Décision : Si SMB1 apparaît, désactivez‑le et corrigez la compatibilité client de façon intentionnelle. Ne conservez pas SMB1 « pour ce vieux scanner ». Remplacez le scanner ou isolez‑le.

Task 9: Check Samba share configuration for sync killers (strict sync, sync always)

cr0x@server:~$ sudo testparm -sv | sed -n '/^\[engineering\]/,/^\[/{p}'
[engineering]
	path = /tank/shares/engineering
	read only = No
	vfs objects = acl_xattr
	strict sync = Yes
	sync always = No

Signification : strict sync = Yes force Samba à flusher sur plus d’opérations. C’est un classique « on l’a activé pour la sécurité » qui peut anéantir le débit.

Décision : Si vous n’avez pas une exigence de conformité stricte, mettez strict sync = No et validez le comportement des applications. Si vous en avez besoin, investissez dans un SLOG et un stockage à faible latence.

Task 10: Check whether SMB signing/encryption is on and whether CPU is the limiter

cr0x@server:~$ sudo smbstatus -b | awk 'NR==1 || NR==2 || $0 ~ /SMB3/'
Samba version 4.19.5-Debian
PID     Username     Group        Machine                                   Protocol Version  Encryption           Signing
23144   user1        domain users  10.10.20.55 (ipv4:10.10.20.55:53122)     SMB3_11           AES-128-GCM          mandatory

cr0x@server:~$ top -b -n 1 | sed -n '1,20p'
top - 12:12:41 up 34 days,  3:01,  2 users,  load average: 9.12, 8.40, 7.95
Tasks: 291 total,   2 running, 289 sleeping,   0 stopped,   0 zombie
%Cpu(s): 12.1 us,  2.0 sy,  0.0 ni, 78.0 id,  0.0 wa,  0.0 hi,  7.9 si,  0.0 st
MiB Mem :  256000.0 total,  21000.0 free,  95000.0 used, 140000.0 buff/cache

Signification : Le chiffrement est activé. Le CPU est majoritairement inactif ici, donc le chiffrement n’est probablement pas le goulot à cet instant. Si vous voyez un cœur saturé et un softirq élevé, revoyez la question.

Décision : Si le chiffrement/signing est obligatoire et que le CPU chauffe, améliorez le CPU, utilisez des systèmes compatibles AES‑NI, assurez‑vous que RSS et multiqueue sont configurés, ou restreignez le chiffrement à certains partages sensibles.

Task 11: Verify NIC link, duplex, and error counters (cheap checks, expensive consequences)

cr0x@server:~$ ip -s link show dev bond0
2: bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 9c:dc:71:aa:bb:cc brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast
    1223344556677 1023344556      0       0       0  120034
    TX:  bytes packets errors dropped carrier collsns
    1334455667788 1124455667      0       0       0       0

cr0x@server:~$ ethtool bond0 | sed -n '1,25p'
Settings for bond0:
	Supported ports: [ ]
	Supported link modes:   Not reported
	Speed: 20000Mb/s
	Duplex: Full
	Auto-negotiation: off

Signification : Pas d’erreurs, duplex complet, vitesse attendue. Si vous voyez des erreurs ou des paquets perdus, corrigez le réseau avant de toucher à ZFS.

Décision : Si des erreurs existent : vérifiez le câblage, les ports du switch, la cohérence MTU et les paramètres offload. Le tuning de performance sur une perte de paquets est du théâtre.

Task 12: Check TCP retransmits and socket pressure (SMB over a sick network is a lie)

cr0x@server:~$ ss -s
Total: 884
TCP:   211 (estab 104, closed 72, orphaned 0, timewait 72)

Transport Total     IP        IPv6
RAW	  0         0         0
UDP	  11        8         3
TCP	  139       113       26
INET	  150       121       29
FRAG	  0         0         0

cr0x@server:~$ netstat -s | sed -n '1,80p'
Tcp:
    154239 active connection openings
    149802 passive connection openings
    1124 failed connection attempts
    1821 connection resets received
    0 connections established
    224159 segments received
    231008 segments sent out
    214 segments retransmitted

Signification : Des retransmissions existent mais pas de façon délirante. Si les retransmissions montent pendant les copies, vous verrez des blocages indépendants du stockage. SMB est sensible aux pics de latence.

Décision : Retransmissions élevées : inspectez les buffers du switch, la mismatch MTU, le driver/firmware NIC, ou un chemin de firewall surchargé.

Task 13: Identify whether the workload is sync-heavy (server-side fsync test)

cr0x@server:~$ sync; sudo bash -c 'time dd if=/dev/zero of=/tank/shares/engineering/.fsync-test bs=1M count=256 conv=fdatasync status=none'
real	0m1.92s
user	0m0.00s
sys	0m0.28s

cr0x@server:~$ sudo rm -f /tank/shares/engineering/.fsync-test

Signification : Ceci mesure « écrire puis forcer la durabilité ». Si c’est lent (par ex., 10–60s), votre pool ne peut pas commit les écritures sync assez vite pour des workloads SMB qui les exigent.

Décision : fsync lent : ajoutez/validez un SLOG, réduisez les sync forcés dans Samba si acceptable, ou redessinez le stockage pour des écritures à faible latence.

Task 14: Confirm dataset is not accidentally forcing sync off (or on) where you didn’t intend

cr0x@server:~$ sudo zfs get -H -o name,property,value sync tank/shares/engineering tank/shares/finance
tank/shares/engineering	sync	standard
tank/shares/finance	sync	always

Signification : Le partage finance est forcé en sync=always. Cela peut être intentionnel (apps nécessitant la durabilité) ou une mauvaise configuration qui le rend lent.

Décision : Si sync=always existe, confirmez auprès des propriétaires d’application pourquoi. Si personne ne le justifie, revenez à standard et testez.

Task 15: Check ZFS compression and actual ratio (because “we enabled compression” is not the same as “it’s working”)

cr0x@server:~$ zfs get -H -o name,property,value compression,compressratio tank/shares/engineering
tank/shares/engineering	compression	lz4
tank/shares/engineering	compressratio	1.62x

Signification : 1.62x signifie que vous économisez I/O et espace. Si le ratio est ~1.00x, la compression n’aide pas beaucoup mais n’handicape généralement pas avec LZ4.

Décision : Gardez LZ4 presque toujours. Désactivez uniquement si vous avez mesuré une saturation CPU et des données presque incompressibles.

Task 16: Look for pathological fragmentation (especially if pool is old and near full)

cr0x@server:~$ sudo zdb -bbbs tank | sed -n '1,40p'
Block Size Histogram:
 512: 0
 1K : 0
 2K : 1048576
 4K : 2097152
 8K : 1048576
 16K: 524288
 32K: 262144
 64K: 131072
 128K: 65536
 256K: 32768
 512K: 16384
 1M : 8192

Signification : C’est une vue approximative ; dans la pratique vous corrélerez la fragmentation avec le comportement d’allocation et la latence. Une forte diversité de petits blocs sur un dataset prévu pour des écritures séquentielles larges peut être un indice.

Décision : Si la fragmentation et le remplissage sont élevés, planifiez une migration de données ou une expansion du pool. ZFS est excellent, mais il ne se défragmente pas par la pensée.

Trois micro-récits du monde de l’entreprise

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

Ils avaient un tout nouveau serveur de fichiers ZFS et deux uplinks 10GbE. Le déploiement semblait correct la première semaine, surtout parce que le test était « copier une ISO de 20GB une fois » et tout le monde est parti content.

Puis la clôture trimestrielle est arrivée. Finance a poussé des milliers de petits PDFs et feuilles de calcul dans un partage depuis une application Windows qui insistait sur le write‑through. Les utilisateurs ont signalé des copies « qui calaient toutes les quelques secondes ». L’équipe réseau n’a vu aucune saturation, donc elle s’est déclarée victorieuse et a accusé Windows. L’équipe stockage voyait beaucoup de RAM libre et a supposé que l’ARC lisserait tout. Ce ne fut pas le cas.

L’hypothèse erronée était subtile : « Si le pool peut faire 1GB/s en écriture séquentielle, il peut faire les copies de fichiers bureau. » Ce sont deux sports différents. Le débit séquentiel est un tour de victoire ; les métadonnées sync‑heavy sont le parcours d’obstacles.

Quand quelqu’un a lancé un simple test dd ... conv=fdatasync sur le dataset, c’est devenu évident. La latence de commit sync était le goulot. Le pool était en RAIDZ sur HDD. Parfait pour la capacité, terrible pour les écritures à faible latence.

La correction fut aussi subtile : ils n’ont pas désactivé le sync. Ils ont ajouté un SLOG approprié, protégé contre la perte d’alimentation, et retiré strict sync des partages qui n’en avaient pas besoin. Finance a conservé ses garanties ; engineering a retrouvé sa vitesse. Les tickets d’assistance se sont arrêtés — c’est la seule KPI qui compte quand on est d’astreinte.

Mini‑récit 2 : L’optimisation qui s’est retournée contre eux

Une autre entreprise avait des copies lentes de répertoires personnels. Quelqu’un a lu un fil de forum et a décidé que la solution était « plus grand recordsize = plus rapide ». Ils ont donc mis recordsize=1M sur tous les datasets SMB, y compris home dirs et arbres de projet partagés.

Les copies de gros fichiers se sont améliorées légèrement. Ensuite les plaintes sont devenues plus étranges : sauvegarder de petits documents semblait saccadé, l’accès à Outlook PST est devenu instable, et certaines applis « ne répondaient plus » lors des enregistrements. Le serveur SMB n’était pas tombé ; il faisait juste beaucoup d’opérations supplémentaires.

Pourquoi ? Les réécritures partielles sur de grands records peuvent créer une amplification d’écriture. Un petit changement dans un fichier peut déclencher un read‑modify‑write d’un gros bloc, surtout quand le workload est aléatoire et que l’appli fait beaucoup de petites mises à jour. ZFS est copy‑on‑write, donc il fait déjà un travail prudent ; ajouter de l’amplification, c’est comme lui demander de jongler sur un tapis roulant.

L’« optimisation » a aussi aggravé le churn des métadonnées parce que les profils utilisateurs génèrent un tas de petits fichiers et de mises à jour d’attributs. Un recordsize plus grand n’aidait pas du tout le chemin métadonnées. Il a juste rendu le chemin données moins amiable.

Le rollback fut discipliné : ils ont séparé les datasets selon le workload. Les home dirs sont passés à 128K recordsize, atime off. Les archives projets/media sont restées à 1M. Les performances se sont stabilisées. La leçon : le tuning n’est pas un buffet où on empile tout ce qui semble appétissant.

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

Une équipe exploitant un cluster ZFS + Samba avait une habitude peu glamour : rapports de scrub hebdomadaires et snapshots de performance mensuels. Pas des tableaux de bord pour l’exécutif. Juste un fichier texte avec zpool status, zpool iostat sous charge, et les compteurs d’erreurs NIC de base.

Un mardi, les utilisateurs ont signalé que les copies étaient devenues « saccadées ». L’ingénieur d’astreinte n’a pas deviné. Il a extrait la baseline et l’a comparée aux chiffres actuels. Le grand changement : la latence d’écriture sur une jambe de mirror avait dérivé vers le haut, et des erreurs corrigeables apparaissaient — juste assez pour déclencher des retries, pas assez pour faire échouer le disque.

Parce qu’ils avaient des données de référence, ils n’ont pas passé une demi‑journée à se disputer sur des flags Samba. Ils ont remplacé le disque pendant une fenêtre de maintenance, resilveré, et les blocages de copie ont disparu.

Rien d’héroïque. Aucun réglage magique. Juste remarquer qu’une « régression de performance » est souvent un vieillissement matériel lent. Voilà à quoi ressemble la compétence en production.

Décisions de réglage qui déplacent vraiment l’aiguille

1) Décidez explicitement de votre position sur le sync (ne laissez pas cela vous arriver)

Les workloads SMB peuvent être sync‑heavy, surtout avec certaines applications et politiques. Vous avez trois choix :

Respecter le sync et en payer le prix : garder sync=standard, éviter les paramètres Samba qui forcent des flushs supplémentaires, et déployer un vrai SLOG si nécessaire.
Forcer sync toujours : sync=always pour des partages conformes. Attendez‑vous à un débit plus faible ; concevez le stockage en conséquence.
Désactiver le sync : sync=disabled est une décision métier qui accepte la perte d’écritures acquittées en cas de coupure. Cela peut être valide pour des partages temporaires, mais ne prétendez pas que c’est un « gain de performance gratuit ». C’est un contrat de durabilité différent.

2) Séparez les datasets par workload (un partage, un comportement)

Un seul dataset pour tout est la manière la plus rapide de s’assurer que rien ne va bien. Séparez :

Home directories (métadonnées lourdes, petits fichiers)
Arbres projets engineering (beaucoup de petits fichiers, lecture majoritaire)
Archives médias (gros séquentiels)
Zones de dépôt applicatives (peuvent nécessiter une durabilité stricte)

Puis définissez les propriétés par dataset : recordsize, atime, sync, compression, comportement ACL.

3) Choisissez un recordsize suffisamment adapté

Partages SMB généraux : commencez par recordsize=128K.
Archives de gros fichiers : envisagez recordsize=1M si la majorité des fichiers sont gros et séquentiels.
Bases de données/VM via SMB : évitez si possible ; si vous devez, utilisez des réglages spécialisés et testez rigoureusement. Le service de fichiers SMB et un datastore VM ne font pas bon ménage par hasard.

4) Désactivez atime pour les partages SMB (sauf raison réelle)

atime=on ajoute des écritures métadonnées sur les lectures. La plupart des organisations n’utilisent pas l’heure d’accès pour quelque chose d’utile, et Windows n’a certainement pas besoin que votre serveur ZFS écrive des métadonnées supplémentaires à chaque ouverture de fichier.

5) Gardez la compression LZ4 activée par défaut

LZ4 est un des rares « par défaut » que je défends en production. Il améliore souvent le débit effectif et réduit l’I/O. Ne vous compliquez pas la vie sauf si vous avez des preuves d’une saturation CPU.

6) Utilisez un vrai SLOG quand vous en avez besoin (et ne lésinez pas)

Un device SLOG n’est pas « n’importe quel SSD ». Il doit avoir une faible latence sous charge d’écriture sync et une protection contre la perte d’alimentation. Sinon vous avez construit un générateur de latence coûteux.

7) Samba : évitez « strict sync » sauf justification

strict sync peut détruire le débit pour des workloads qui génèrent beaucoup de points fsync (y compris certains comportements Windows autour de la fermeture de fichier). Si vous avez besoin de sémantiques strictes, rendez le stockage capable. Sinon, ne payez pas pour cela.

8) Signing/chiffrement SMB : ciblez-les

Les équipes sécurité aiment les politiques globales. Les systèmes de production aiment les budgets. Si signing/chiffrement doivent être obligatoires, assurez‑vous que l’hôte SMB a de la marge CPU et un matériel crypto moderne. Si seules certaines partages contiennent des données sensibles, ciblez la politique par partage ou par segment de trafic.

Blague #2 : Rien ne rend un serveur de fichiers plus rapide comme une réunion de politique qui se termine par « nous n’avons rien changé ».

Erreurs courantes : symptôme → cause racine → correctif

1) Symptom: Copy starts fast, then drops to 0 B/s repeatedly

Cause racine : stalls de commit TXG dus aux écritures sync ou à une latence de flush lente (pas de SLOG, vdevs lents, pool trop plein).

Correctif : Mesurez fsync (dd ... conv=fdatasync), vérifiez les paramètres sync Samba, ajoutez un SLOG approprié ou redessinez le pool pour la latence, récupérez de l’espace.

2) Symptom: Large files copy fine; many small files crawl

Cause racine : Workload lié aux métadonnées (ACL, xattrs, timestamps) plus limites en petits I/O aléatoires.

Correctif : atime=off, assurez‑vous de propriétés dataset appropriées, envisagez des mirrors pour les pools lourds en métadonnées, vérifiez que les modules VFS Samba n’ajoutent pas de surcharge, et acceptez qu’il s’agisse d’IOPS et non de bande passante.

3) Symptom: Speed caps at ~110 MB/s on “10GbE”

Cause racine : Client/serveur négocié en 1GbE, mauvais hashing LACP, ou contrainte d’un seul flux TCP sans multichannel.

Correctif : Vérifiez la vitesse de lien via ethtool, validez la config du switch, testez SMB multichannel, et confirmez que le client n’est pas sur un segment 1GbE.

4) Symptom: Performance worse after enabling SMB signing or encryption

Cause racine : Bottleneck CPU en crypto/signing, points chauds mono‑thread, queues RSS insuffisantes.

Correctif : Mesurez le CPU par cœur pendant le transfert, activez multiqueue/RSS, upgradez le CPU, ciblez signing/chiffrement, ou utilisez du matériel qui accélère ça.

5) Symptom: Copies intermittently hang for “exactly a few seconds”

Cause racine : Retransmissions réseau, bufferbloat, ou congestion switch ; parfois le timing TXG s’aligne avec les pauses perçues.

Correctif : Regardez les retransmissions (netstat -s), les drops d’interface et les compteurs switch. Si tout est propre, retournez à la latence stockage et au sync.

6) Symptom: One share is slow; another share on same server is fine

Cause racine : Mismatch de propriétés dataset (sync=always, recordsize bizarre, atime activé), différences de config Samba (strict sync, modules VFS), ou quotas/réservations affectant l’allocation.

Correctif : Comparez les sorties zfs get et les blocs testparm -sv pour les deux partages. Normalisez intentionnellement.

7) Symptom: “Windows says it will take 2 hours” but server looks idle

Cause racine : Scan côté client (antivirus, indexation), surcharge petits fichiers, ou client qui attend des opérations metadata par fichier.

Correctif : Reproduisez avec un client propre, testez avec les options robocopy, et confirmez les métriques serveur pendant l’opération. Ne tunez pas les serveurs pour compenser une flotte de endpoints défaillante.

Listes de contrôle / plan pas à pas

Étapes pas à pas : corriger les copies SMB « rapide puis zéro » sur ZFS

Confirmer l’état du pool : zpool status -v. Si dégradé ou erreurs, arrêtez et réparez les disques.
Vérifier le remplissage du pool : zfs list. Si >85% utilisé, planifiez récupération/extension d’espace.
Identifier le dataset et ses propriétés : zfs get recordsize,atime,sync,compression.
Inspecter la config du partage Samba : testparm -sv pour strict sync, paramètres aio, modules VFS.
Mesurer la latence sync : test serveur dd ... conv=fdatasync. Si lent, c’est le principal suspect.
Vérifier la présence/performance du SLOG : zpool status pour logs et assurez‑vous que la classe de device est appropriée.
Observer la latence disque sous charge : iostat -x et zpool iostat pendant la reproduction.
Vérifier la santé réseau : ip -s link, retransmissions (netstat -s), et vitesse lien (ethtool).
Appliquer un changement à la fois : par ex., désactiver strict sync sur un partage test ou ajouter un SLOG ; puis relancer le même transfert et comparer.
Noter le résultat : capturez latence, débit, et si les blocages ont disparu. La mémoire s’efface ; les tickets restent.

Checklist baseline (les trucs ennuyeux que vous remercierez)

Scrub hebdomadaire planifié ; rapports de scrub examinés.
Snapshot mensuel de : zpool status, propriétés clés zfs get, ip -s link et un test répétable de débit + fsync.
Layout des datasets documenté par catégorie de workload.
Politique explicite sur le sync : quels partages requièrent des garanties de durabilité.
Contrôle des changements pour la config Samba ; pas de « correctifs one‑liner » en production à 2h du matin.

FAQ

1) Pourquoi Explorateur Windows affiche‑t‑il une vitesse rapide, puis 0 B/s ?

Explorateur rapporte sur la base du buffering et de l’acceptation à court terme. ZFS et Samba peuvent accepter les données rapidement, puis caler pendant le commit des écritures sync ou des TXG. Mesurez la latence côté serveur.

2) Robocopy est‑il plus rapide qu’Explorateur ?

Parfois. Le vrai avantage est que robocopy est plus prévisible et scriptable, et qu’il expose les retries et le comportement par fichier. Il ne résoudra pas la latence sync côté serveur.

3) Dois‑je mettre `sync=disabled` pour accélérer ?

Seulement si vous acceptez de perdre des écritures reconnues en cas de coupure ou crash. Pour des partages temporaires ça peut être acceptable. Pour des données métier, c’est une dégradation de durabilité, pas une astuce de tuning.

4) Ai‑je besoin d’un SLOG pour SMB ?

Si votre workload génère beaucoup d’écritures sync (ou si les paramètres Samba forcent des flushs stricts), un bon SLOG peut être transformateur. Si votre workload est majoritairement async, un SLOG n’aidera pas beaucoup.

5) Quel recordsize utiliser pour les partages SMB ?

Commencez à 128K pour les partages polyvalents. Utilisez 1M pour les archives séquentielles larges. Évitez les changements globaux ; séparez les datasets par workload.

6) Activer LZ4 ralentit‑t‑il ?

Généralement non, et souvent cela accélère en réduisant l’I/O. Si le CPU est déjà saturé (chiffrement/signing, grosse charge), mesurez avant de décider.

7) RAIDZ est‑il mauvais pour SMB ?

Pas « mauvais », mais RAIDZ est moins adapté aux petites écritures aléatoires et aux workloads lourds en métadonnées que les mirrors. Si votre cas SMB implique beaucoup de petits fichiers et un comportement sync, les mirrors gagnent souvent en latence.

8) Pourquoi un partage SMB est‑il lent alors qu’un autre sur le même serveur va bien ?

Propriétés dataset différentes ou options de partage Samba. Cherchez sync=always, atime=on, recordsize étrange ou strict sync activé uniquement sur un partage.

9) SMB Multichannel règle‑t‑il tout ?

Non. Il peut augmenter le débit et la résilience, mais ne corrigera pas la latence stockage ou les stalls sync. Il nécessite aussi un support NIC, driver et client correct.

10) Comment savoir si c’est CPU‑bound ?

Pendant le transfert, un ou plusieurs cœurs seront constamment chargés, souvent dans smbd ou le réseau/kernel crypto. Pendant ce temps les disques et les NICs ne seront pas saturés. C’est votre signal.

Étapes suivantes réalisables cette semaine

Faites‑les dans l’ordre. Chaque étape clarifie une décision, et aucune ne requiert la foi.

Choisissez un test de transfert reproductible (un gros fichier et un dossier « beaucoup de petits fichiers ») et gardez‑le constant.
Exécutez la feuille de route de diagnostic rapide et capturez les sorties : zpool iostat, iostat -x, ip -s link, netstat -s, smbstatus.
Prouvez ou éliminez la latence sync avec le test serveur dd ... conv=fdatasync sur le dataset.
Séparez les datasets par workload si ce n’est pas fait. Mettez atime=off et des recordsize sensés par catégorie.
Corrigez le vrai goulot : ajoutez un SLOG adapté pour les partages sync‑heavy, libérez de l’espace si le pool est trop plein, ou traitez CPU/réseau si c’est là que les preuves pointent.
Rédigez un runbook d’une page avec vos commandes de base et les sorties « normales ». Le futur vous achètera un café au passé vous.

L’objectif n’est pas un graphe parfait. L’objectif est une performance prévisible sous le contrat de durabilité que vous voulez réellement offrir. Une fois que vous choisissez ce contrat volontairement, ZFS et SMB cessent d’être mystérieux et deviennent… simplement exigeants.