Poignées durables SMB sur ZFS : pourquoi Copier/Déplacer semble étrange

Modèle mental : ce que « durable » signifie vraiment

Commençons par une affirmation directe : SMB n’est pas « juste des E/S de fichiers ». C’est un protocole avec état qui garde en mémoire côté serveur
ce que fait un client. Les poignées durables font partie de cette mémoire.

Dans SMB2/SMB3, un client ouvre un fichier et obtient une poignée. Cette poignée représente un état vivant : verrous, modes de partage,
verrous sur plages d’octets, droits de cache, et parfois un lease (une promesse structurée sur le cache et la cohérence). Si le réseau
saute, le client perdait traditionnellement la poignée. Les applications recevaient alors « fichier introuvable » ou « nom réseau non disponible »
et tout le monde accusait le stockage.

Les poignées durables résolvent cela : le serveur peut conserver l’état d’ouverture un certain temps pour que le client puisse se reconnecter
et « réclamer » l’ouverture. La reconnexion peut avoir lieu après une réinitialisation TCP, un hoquet Wi‑Fi ou la mise en veille d’un portable.
C’est une fonctionnalité de fiabilité. Le compromis est que le serveur doit conserver et valider plus d’état, et être prudent quand des fichiers
sont renommés/déplacés pendant que des ouvertures existent.

Ajoutez maintenant ZFS. ZFS est très efficace pour préserver la cohérence sur disque et fournir une identité d’objet stable. SMB est
très efficace pour préserver la cohérence des fichiers ouverts pendant les reconnexions. Ensemble, vous obtenez de la justesse. Vous obtenez
aussi des pics de latence visibles dans des endroits que les utilisateurs Windows interprètent comme « pourquoi le déplacement ressemble à une copie ? »

Pourquoi Copier/Déplacer paraît étrange avec SMB sur ZFS

1) « Déplacer » n’est un renommage que si le serveur peut faire un renommage atomique

Sur un volume NTFS local, un déplacement dans le même système de fichiers est typiquement un renommage metadata : rapide, atomique, et qui ne touche pas les données.
Sur SMB, Explorer demande au serveur d’effectuer un renommage (SMB2 SET_INFO / FileRenameInformation). Si le renommage est dans le même partage et que
le serveur peut le mapper à un renommage simple, il peut être rapide.

Mais si le « déplacement » traverse des frontières que le serveur considère non-atomiques — partages différents, systèmes de fichiers sous-jacents différents,
datasets ZFS montés séparément, ou un chemin qui déclenche une politique VFS différente — le serveur peut répondre « ne peut pas le faire en tant que renommage ».
Le client retombe alors sur copie+suppression. Voilà la première source d’étrangeté.

2) Les poignées durables rendent le serveur prudent vis‑à‑vis des renommages et suppressions

Si un fichier est ouvert avec une poignée durable et que le client peut se reconnecter pour continuer à écrire, le serveur doit préserver les sémantiques :
la poignée doit toujours référencer le même objet fichier après un renommage. C’est faisable si le serveur suit les IDs de fichiers de façon fiable.
Mais cela change le profil de coût. Des opérations qui étaient « juste renommer une entrée » impliquent maintenant :

• La mise à jour des tables de poignées durables et de l’état des ruptures de lease
• La validation que les modes de partage sont respectés pour le nouveau nom/emplacement
• L’assurance que le renommage est visible et cohérent pour les autres clients
• Éventuellement casser des leases/oplocks pour forcer les autres clients à invalider leurs caches

Ce travail n’est pas gratuit. Si le serveur est occupé, ou si les E/S métadonnées sont lentes, un renommage peut prendre suffisamment de temps pour que Explorer ait l’air de « copier ».
L’interface n’est pas un moteur de vérité ; c’est une impression visuelle plus une barre de progression.

3) « Déplacement instantané » suivi de fichiers persistants vient généralement d’une suppression différée ou de rétention de poignées

Un autre cas étrange : vous déplacez un dossier, il apparaît à destination, mais il reste visible à la source pendant un moment. Il y a plusieurs raisons honnêtes :

• Mise en cache des entrées de répertoire côté client (Explorer est très optimiste).
• Poignées ouvertes empêchant la suppression ; le serveur marque en suppression-à-la-fermeture.
• Snapshots ou holds qui maintiennent les blocs, même si l’espace de noms live a changé (l’espace de noms change ; les blocs restent).
• Déplacements cross-dataset implémentés en copie+suppression ; la suppression attend la fermeture des poignées.

4) Les frontières de dataset ZFS transforment les renommages en copies, même si les chemins semblent « proches »

Les datasets ZFS ne sont pas des répertoires avec un joli nom. Ce sont des systèmes de fichiers séparés avec leurs propres points de montage, propriétés,
et parfois un recordsize, une compression, une disposition des xattr et un comportement ACL différents. Un renommage entre datasets n’est pas atomique.
Le serveur SMB ne peut pas effectuer un renommage système de fichiers unique lorsque la source et la destination ne sont pas le même filesystem.

Cela signifie que le « déplacer » d’Explorer devient « copier puis supprimer ». Les utilisateurs ne connaissent pas (et ne se soucient pas) de ce qu’est un dataset.
Ils voient juste une opération qui était instantanée devenir longue de plusieurs minutes. Vous pouvez soit les informer, soit concevoir des partages pour rendre
les frontières de dataset invisibles à leurs flux de travail. Choisissez-en un. Un seul arrivera.

5) Les métadonnées SMB sont bavardes ; les métadonnées ZFS peuvent coûter cher sous charge

Copier un arbre de répertoires n’est pas que des données. C’est un festival de métadonnées : create, set security, set timestamps, set attributes, set
alternate data streams, query info, open/close. Les poignées durables et les leases ajoutent des transitions d’état à ce festival. ZFS sous forte
charge synchrone ou avec des IOPS métadonnées contraints rendra ce festival aussi lent qu’une parade.

Petite blague #1 : Les poignées durables, c’est comme garder votre ticket de parking après être parti — utile, sauf si l’employé s’attend aussi à ce que vous laissiez la voiture pour toujours.

Faits intéressants et un peu d’histoire

1. SMB2 est arrivé avec Windows Vista/Server 2008 et a considérablement réduit la « bavardise SMB1 » en regroupant et en pipelineant les opérations.
2. Les poignées durables sont apparues dans SMB2.1 (ère Windows 7/Server 2008 R2) pour survivre aux déconnexions transitoires sans retries applicatifs.
3. SMB3 a ajouté les « poignées persistantes » principalement pour les partages continuellement disponibles sur des serveurs en cluster ; elles sont plus fortes que les « durables ».
4. Les opportunistic locks (oplocks) existaient bien avant SMB2 ; SMB2+ les a généralisés en leases avec des sémantiques plus claires.
5. L’interface de progression de Windows Explorer n’est pas un analyseur de protocole ; elle étiquette fréquemment mal copie vs déplacement lorsque des reculs se produisent.
6. Le renommage ZFS est atomique au sein d’un dataset, mais pas entre datasets ; il devient alors une opération de plus haut niveau copy+unlink.
7. Les snapshots ZFS ne « figent » pas le système de fichiers live ; ils préservent des anciens blocs. Les suppressions après snapshot peuvent devenir du travail de reclamation d’espace plus tard.
8. Samba implémente les poignées durables en espace utilisateur ; la performance et les sémantiques dépendent du comportement VFS du noyau, du support xattr, et des modules vfs choisis.
9. SMB utilise des IDs de fichier pour identifier les fichiers au-delà des noms. Les serveurs qui peuvent fournir des IDs stables semblables à des inodes rendent la réclamation de poignées durables plus robuste.

Poignées durables vs leases/oplocks vs poignées « persistantes »

Poignées durables

Une poignée durable concerne la reconnexion. Le serveur conserve l’état après une déconnexion pour que le client puisse le réclamer.
Le serveur décide combien de temps la garder et sous quelles conditions elle est valide. Les poignées durables sont courantes sur les piles SMB modernes.

Leases (et oplocks)

Les leases concernent la mise en cache. Ils permettent au client de mettre en cache lectures, écritures et métadonnées avec moins d’allers-retours.
Quand un autre client veut un accès en conflit, le serveur « casse » le lease et le client vide/invalide ses caches. Les ruptures de lease peuvent ressembler
à des pauses aléatoires pendant un Copier/Déplacer parce que le serveur force la cohérence.

Poignées persistantes

Les poignées persistantes sont la variante « ne perdez pas ma poignée même si le serveur bascule » ; elles sont prévues pour les partages continuellement disponibles
sur des clusters. Si vous ne faites pas tourner un cluster prévu pour cela, attendre des poignées persistantes est une manière de se blesser.

La conclusion pratique : les poignées durables gardent la cohérence pendant la reconnexion ; les leases rendent rapide jusqu’au moment où il faut être correct.
Le comportement étrange de Copier/Déplacer est souvent la transition entre ces deux modes.

Idée paraphrasée — Richard Cook : « Les systèmes complexes échouent de façon complexe ; les opérateurs doivent continuellement concilier comment le travail est réellement fait. »

Mécanismes ZFS importants : IDs, txgs, xattrs, snapshots

Identité de fichier stable : comportement type inode et IDs SMB

Les clients SMB bénéficient quand le serveur peut fournir des IDs de fichier stables pour que « même objet, nouveau nom » reste vrai après un renommage.
ZFS a une forte identité d’objet interne. Samba (ou votre pile SMB) mappe cela aux IDs SMB. Si ce mapping est stable, la réclamation de poignée durable à travers un renommage est plus sûre.
Sinon, le serveur devient conservateur : plus de vérifications, plus de ruptures, plus de reculs.

Groupes de transaction (txgs) et comportement sync

ZFS regroupe les changements en groupes de transaction. Beaucoup de petites mises à jour de métadonnées lors d’une copie de répertoire peuvent s’accumuler puis être poussées.
Si votre charge déclenche des sémantiques synchrones (sync explicite, ou paramètres SMB qui l’impliquent pour la durabilité), vous pouvez avoir des stalls périodiques quand le système attend l’activité du journal d’intent et les commits de txg.

C’est une des raisons pour lesquelles « la copie est fluide, le déplacement est saccadé » arrive : les déplacements peuvent créer des rafales de mises à jour metadata et des séquences rename/unlink
qui touchent des points de sync différemment que des écritures séquentielles.

xattrs et flux de données alternatifs

Windows utilise des flux de données alternatifs (ADS). Les serveurs SMB implémentent souvent les ADS avec des attributs étendus. Sur ZFS, les xattrs peuvent être stockés de différentes façons
(dépendant de l’implémentation), et les petites métadonnées peuvent se traduire par beaucoup d’E/S aléatoire si vous manquez de mémoire. Copier depuis Windows inclut souvent des security descriptors,
des zone identifiers, et d’autres métadonnées qui « devraient être bon marché », jusqu’à ce que ce ne le soit plus.

Snapshots : le déplacement a eu lieu, mais l’espace n’est pas revenu

Les utilisateurs demandent « Je l’ai déplacé, pourquoi le pool est toujours plein ? » Snapshots. Un déplacement à l’intérieur du même dataset peut seulement renommer des entrées ; l’espace ne change pas.
Une copie+suppression entre datasets peut libérer de l’espace dans le dataset source, mais si la source a des snapshots, les blocs restent référencés.
Du point de vue capacité, « suppression » devient « marquer libre dans l’arbre live mais toujours référencé par snapshot ». C’est correct. C’est aussi déroutant si vous regardez l’espace libre comme un cours en temps réel.

Modes de panne qui ressemblent à « SMB est lent » mais ne le sont pas

Tempêtes de renommage déclenchant des ruptures de lease

Les gros déplacements d’arbres de répertoires sont des tempêtes de renommage. Si d’autres clients explorent ces répertoires, le serveur doit maintenir des vues cohérentes.
Les ruptures de lease se propagent. Votre « simple déplacement » devient un exercice de coordination multi‑clients.

Antivirus et indexation de contenu transformant les métadonnées en latence

Sur Windows, Defender (ou l’AV corporate) adore les nouveaux fichiers. La copie crée des fichiers neufs. Le déplacement-comme-copie crée des fichiers neufs.
Le client les lit, les hache, et parfois les rouvre. Cela augmente les opens/close SMB, qui interagissent avec les tables de poignées durables et les modes de partage.
Le stockage se retrouve blâmé pour l’enthousiasme de l’équipe sécurité.

Pression sur l’ARC ZFS et amplification d’E/S petites opérations

Copier beaucoup de petits fichiers est une charge metadata et petites E/S. Si l’ARC est sous pression, le système commence à faire de vraies lectures disque pour des métadonnées
qui seraient autrement en cache. La latence augmente. La latence SMB augmente. Explorer déclare le déplacement « calcul du temps restant… » indéfiniment.

Déplacements inter‑partages : taxe UX pour des frontières administratives propres

Les administrateurs aiment les partages multiples. Les utilisateurs veulent que « ça bouge instantanément ». Ces objectifs sont souvent mutuellement exclusifs.
Un déplacement cross-share ne peut généralement pas être un renommage côté serveur. Le client copie et supprime, ce qui est correct mais pas rapide.

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

Voici les vérifications que j’exécute quand quelqu’un dit « les déplacements SMB sont bizarres sur ZFS ». Chaque tâche contient : la commande, ce que signifie la sortie, et la
décision à prendre en conséquence.

Task 1: Confirm dataset boundaries and mountpoints

cr0x@server:~$ zfs list -o name,mountpoint -r tank/smb
NAME               MOUNTPOINT
tank/smb           /tank/smb
tank/smb/users     /tank/smb/users
tank/smb/projects  /tank/smb/projects
tank/smb/archive   /tank/archive

Signification : tank/smb/archive est monté ailleurs. Un « déplacement » depuis /tank/smb/projects vers /tank/smb/archive traverse des systèmes de fichiers.

Décision : Si les utilisateurs déplacent régulièrement entre ces chemins, soit fusionnez en un seul dataset, soit acceptez le comportement copie+suppression (et informez-les).

Task 2: Verify both source and destination are same filesystem from the kernel’s view

cr0x@server:~$ stat -f -c '%T %m' /tank/smb/projects /tank/archive
zfs /tank/smb/projects
zfs /tank/archive

Signification : Les deux sont ZFS, mais cela ne signifie pas le même dataset. stat -f n’indiquera pas les datasets ZFS ; il dit juste « zfs ».

Décision : Utilisez la Tâche 1 plus une carte des partages. N’assumez pas que « même pool » signifie « même filesystem ».

Task 3: Map SMB shares to filesystem paths (Samba)

cr0x@server:~$ testparm -s 2>/dev/null | sed -n '/^\[users\]/,/^\[/{/path =/p}'
	path = /tank/smb/users

Signification : Le partage [users] pointe sur /tank/smb/users. Faites cela pour les deux partages impliqués dans le « déplacement ».

Décision : Si le déplacement traverse des partages, attendez un fallback copie+suppression côté client à moins que vous n’utilisiez des fonctions de copie côté serveur et que le client les supporte bien.

Task 4: Watch live SMB sessions and open files

cr0x@server:~$ smbstatus --shares --processes
Service      pid     Machine       Connected at                     Encryption   Signing
users        21408   10.20.30.44    Tue Dec 26 09:10:12 2025 UTC     -            -
projects     22119   10.20.30.44    Tue Dec 26 09:11:05 2025 UTC     -            -

Signification : Le même client est connecté à plusieurs partages. Un déplacement cross-share est probablement une copie+suppression.

Décision : Si c’est un flux de travail fréquent, envisagez de présenter une racine de partage unique qui maintient les déplacements courants dans un seul partage et dataset.

Task 5: Identify durable handle and lease behavior in Samba logs

cr0x@server:~$ grep -E 'durable|lease|oplock' /var/log/samba/log.smbd | tail -n 8
[2025/12/26 09:17:41.231112,  3] smbd/smb2_oplock.c:3177(smbd_smb2_request_process_break)
  Sending break for lease key 9c3c2b0d...
[2025/12/26 09:17:41.245891,  3] smbd/smb2_server.c:4041(smbd_smb2_request_error_ex)
  smbd_smb2_request_error_ex: idx[1] status[STATUS_OPLOCK_BREAK_IN_PROGRESS]

Signification : Des ruptures de lease se produisent. Le serveur force les clients à vider leurs caches, souvent pendant les tempêtes de renommage.

Décision : Si les ruptures de lease corrèlent avec le « déplacement étrange », réduisez la navigation concurrente dans les répertoires pendant les migrations, ou planifiez les déplacements en dehors des heures de pointe.

Task 6: Check ZFS dataset properties that affect SMB metadata behavior

cr0x@server:~$ zfs get -H -o name,property,value atime,xattr,acltype,casesensitivity,recordsize,sync tank/smb/projects
tank/smb/projects	atime	off
tank/smb/projects	xattr	sa
tank/smb/projects	acltype	posixacl
tank/smb/projects	casesensitivity	mixed
tank/smb/projects	recordsize	1M
tank/smb/projects	sync	standard

Signification : xattr=sa peut être bon pour les charges metadata-intensives ; recordsize=1M convient aux gros fichiers mais n’est pas décisif pour les tempêtes de petits fichiers.

Décision : Si vous voyez beaucoup de trafic ADS/xattr et des E/S aléatoires, validez la stratégie xattr et envisagez un dataset optimisé pour petits fichiers (et gardez les déplacements à l’intérieur).

Task 7: Check snapshot pressure when “delete didn’t free space”

cr0x@server:~$ zfs list -t snapshot -o name,used,refer,mountpoint -r tank/smb/projects | head
NAME                                USED  REFER  MOUNTPOINT
tank/smb/projects@daily-2025-12-25   118G  2.4T   -
tank/smb/projects@daily-2025-12-26   6.1G  2.5T   -

Signification : Les snapshots référencent beaucoup. Supprimer/déplacer des fichiers ne libérera pas ces blocs tant que les snapshots existent.

Décision : Si la capacité est le problème, ajustez la rétention des snapshots ou déplacez les données vers un dataset sans snapshots de longue durée (mais faites-le en connaissance de cause).

Task 8: Observe txg and I/O latency during the operation

cr0x@server:~$ iostat -x 2 5
Linux 6.6.44 (server) 	12/26/2025 	_x86_64_	(32 CPU)

avg-cpu:  %user %nice %system %iowait  %steal   %idle
          12.1  0.0     6.8     9.7     0.0    71.4

Device            r/s     w/s   rkB/s   wkB/s  await  svctm  %util
nvme0n1         215.0   480.0  8200.0 51200.0   8.40   0.35   24.0
sdg             120.0   900.0  1400.0 18000.0  38.20   1.10   95.0

Signification : Un dispositif est saturé en %util et a un await élevé. C’est là que votre « renommage » attend.

Décision : Si les métadonnées atterrissent sur des vdevs lents, corrigez le layout des vdevs, ajoutez des classes d’allocation spéciales (si possible), ou réduisez les opérations metadata‑lourdes aux heures creuses.

Task 9: Check ARC efficiency and pressure (Linux)

cr0x@server:~$ arcstat 2 3
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  arcsz     c
09:20:11  12K  3.1K     25   510   16   2.6K   84     0    0   92G   110G
09:20:13  15K  5.9K     39   820   14   5.1K   86     0    0   92G   110G
09:20:15  14K  6.2K     44   900   14   5.3K   86     0    0   92G   110G

Signification : Le taux de miss est élevé et surtout des préfetch misses. Vous effectuez du travail metadata/aléatoire qui ne reste pas chaud.

Décision : Si cela corrèle avec des tempêtes de copie/déplacement, ajoutez de la RAM, réduisez la concurrence, ou déplacez les métadonnées sur un média plus rapide si votre plateforme le permet.

Task 10: Confirm whether the operation is rename or copy+delete from the client side (Windows via server logs)

cr0x@server:~$ grep -E 'rename|unlink|NT_STATUS|SET_INFO' /var/log/samba/log.smbd | tail -n 10
[2025/12/26 09:21:44.101220, 10] smbd/smb2_trans2.c:3920(smbd_smb2_setinfo_file)
  SMB2_SETINFO_FILE: FileRenameInformation
[2025/12/26 09:21:44.141109, 10] smbd/close.c:871(close_normal_file)
  closed file users/alice/report.xlsx (numopen=0) NT_STATUS_OK

Signification : Vous voyez FileRenameInformation, donc au moins une partie du déplacement est un vrai renommage.

Décision : Si l’UI affiche « copie » mais les logs montrent un renommage, concentrez-vous sur la latence metadata/ruptures de lease — pas sur le débit de données.

Task 11: Check for share-level options that change sync/durability behavior

cr0x@server:~$ testparm -s 2>/dev/null | grep -E 'strict sync|sync always|durable handles|kernel oplocks|oplocks|leases'
	kernel oplocks = no
	oplocks = yes
	leases = yes
	strict sync = yes

Signification : strict sync = yes peut forcer des sémantiques synchrones pour certaines opérations, augmentant la latence sous tempêtes metadata.

Décision : Ne désactivez pas strict sync aveuglément. Décidez par partage selon la criticité des données. Pour des profils personnels, peut‑être ; pour la compta, probablement pas.

Task 12: Spot “move became copy” via unexpected write volume

cr0x@server:~$ zpool iostat -v tank 2 3
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank        88.2T  21.5T    220   1600   18M   220M
  raidz2-0  40.1T  10.2T    110    900   10M    120M
    sdg         -      -     30    260  2.5M    34M
    sdh         -      -     25    230  2.1M    30M
  raidz2-1  48.1T  11.3T    110    700  8.0M   100M
    sdi         -      -     28    210  2.0M    29M
    sdj         -      -     26    190  1.8M    27M

Signification : Un « déplacement » au sein d’un dataset ne devrait pas générer des écritures soutenues de centaines de MB/s. Si c’est le cas, c’est une copie.

Décision : Reconcevez les frontières share/dataset. Si les utilisateurs doivent déplacer entre datasets, planifiez le débit et la surcharge AV ; ne promettez pas la vitesse d’un renommage.

Task 13: Check directory enumeration pressure (are we doing millions of LOOKUPs?)

cr0x@server:~$ nfsstat -c 2>/dev/null || true
nfsstat: NFS not running

Signification : Pas de NFS — bien. Pour la pression d’énumération SMB vous vous appuierez sur les logs SMB, compteurs perf, et traçage d’appels système.

Décision : Si vous ne pouvez pas instrumenter SMB correctement, augmentez brièvement le niveau de log Samba sur une IP client unique et capturez le comportement renommage/copie directement.

Task 14: Trace rename/unlink syscalls during a “move” (Linux server)

cr0x@server:~$ sudo strace -f -p $(pidof smbd | awk '{print $1}') -e trace=rename,renameat,unlink,unlinkat -s 128 -tt -o /tmp/smbd.rename.trace & sleep 5; tail -n 5 /tmp/smbd.rename.trace
09:23:10.118023 renameat(AT_FDCWD, "/tank/smb/projects/Q4/budget.xlsx", AT_FDCWD, "/tank/smb/projects/Q4-archive/budget.xlsx") = 0
09:23:10.118771 unlinkat(AT_FDCWD, "/tank/smb/projects/Q4/tmp~budget.xlsx", 0) = 0

Signification : Vous voyez de vrais appels renameat. Cela suggère qu’un renommage côté serveur a lieu — le ralentissement vient probablement de verrous/ruptures de lease ou d’E/S metadata.

Décision : Si vous voyez du volume d’open/read/write au lieu de renommages, c’est une copie+suppression. Corrigez d’abord le problème de frontière.

Task 15: Detect deletes blocked by open handles (Samba)

cr0x@server:~$ smbstatus --locks | head -n 12
Locked files:
Pid    Uid   DenyMode   Access      R/W        Oplock           SharePath   Name   Time
22119  1050  DENY_NONE  0x120089    RDONLY     EXCLUSIVE+BATCH  /tank/smb/projects  Q4/budget.xlsx  Tue Dec 26 09:23:44 2025

Signification : Un client a un oplock/lease (affiché comme oplock ici). La suppression ou le déplacement peut nécessiter une rupture ; si le client répond lentement, vous attendez.

Décision : Si un client détient des verrous qui bloquent les opérations, adressez-vous à ce client (portables en veille, applis bloquées) avant d’ajuster le stockage.

Feuille de diagnostic rapide

Quand un « déplacement » ressemble à une « copie », ne commencez pas par changer les paramètres ZFS. Commencez par déterminer quelle opération se passe réellement.
Voici l’ordre qui fait gagner du temps.

Premier : est‑ce un renommage ou une copie+suppression ?

• Vérifiez les chemins de partage et les frontières de dataset (Tâche 1, Tâche 3).
• Surveillez un débit d’écriture soutenu pendant un « déplacement » (Tâche 12).
• Cherchez des appels de renommage SMB dans les logs ou tracez les syscalls (Tâche 10, Tâche 14).

Si c’est une copie+suppression : arrêtez de blâmer les poignées durables. Votre architecture a forcé le fallback.

Deuxième : si c’est un renommage, qu’est‑ce qui fait attendre ?

• Cherchez des ruptures de lease/oplock et STATUS_OPLOCK_BREAK_IN_PROGRESS (Tâche 5).
• Vérifiez des suppressions bloquées ou des poignées ouvertes (Tâche 15).
• Corrélez avec la latence disque / iowait (Tâche 8).

Si ce sont des ruptures de lease : réduisez la concurrence, évitez les renommages massifs en heures de pointe, et envisagez de modifier la disposition des partages.

Troisième : est‑ce que les métadonnées sont le goulot ?

• Vérifiez le taux de miss ARC (Tâche 9).
• Validez les propriétés du dataset pour la charge (Tâche 6).
• Vérifiez que les snapshots ne masquent pas les attentes de suppression (Tâche 7).

Si ce sont les métadonnées : la correction est d’accélérer les métadonnées, ajouter de la mémoire, réduire les tempêtes de petits fichiers, ou mieux planifier — rarement « désactiver les poignées durables ».

Trois micro-histoires du monde de l’entreprise

Incident : la mauvaise hypothèse (« un déplacement est toujours un renommage »)

Une entreprise de taille moyenne avait une taxonomie propre : un dataset ZFS par département, un partage SMB par dataset, quotas propres, snapshots propres.
Le serveur de fichiers était sain et ennuyeux — jusqu’à la clôture de trimestre de la finance. Soudain, « déplacer » des dossiers vers un partage d’archive prenait des heures.
Les tickets d’assistance ont afflué, et quelqu’un a déclaré le pool ZFS « dégradé » parce que Windows disait « Préparation du déplacement… ».

L’erreur était simple : ils ont supposé qu’un déplacement au sein du « même serveur » est un renommage. Mais l’archive était un partage différent et un dataset différent.
Windows a fait copie+suppression. L’antivirus a scanné les nouveaux fichiers. Les outils financiers ont rouvert les fichiers.
Le serveur SMB a fait exactement ce qu’il devait : appliquer les modes de partage et garder les ouvertures durables pendant les déconnexions transitoires.

L’ingénieur SRE a prouvé le diagnostic en observant la bande passante d’écriture du pool pendant le « déplacement » et en grepant les logs Samba pour les appels rename.
Il y en avait presque aucun. C’était une tempête de copies. Pendant ce temps, les snapshots sur le dataset source faisaient que même après la suppression, l’espace n’était pas récupéré.
Les utilisateurs ont vu un déplacement lent et pas d’espace libéré et ont conclu « le stockage ment ».

La solution n’était pas un simple réglage. Ils ont créé une racine de partage unique avec des sous-répertoires pour les départements dans un seul dataset pour les flux nécessitant des déplacements rapides.
Ils ont gardé des datasets séparés en coulisses pour les besoins de snapshot/rétention, mais ont cessé d’exposer les frontières de dataset comme des partages séparés pour les utilisateurs quotidiens.
La clôture de trimestre est redevenue calme. Le serveur de fichiers est retourné à l’ennui, ce que vous souhaitez d’un serveur de fichiers.

Optimisation qui s’est retournée contre eux : « rendons tout encore plus durable »

Une autre organisation avait été brûlée par une flotte de portables qui se mettait souvent en veille en plein milieu d’une copie. Ils ont entendu parler des poignées durables
et ont décidé d’appliquer la sécurité maximale partout. Ils ont activé strict sync et traité le serveur SMB comme une base de données. Personne n’a demandé quelle charge réelle ils avaient :
surtout des petits fichiers Office, quelques CAD, et d’énormes arbres de répertoires.

Le résultat fut étrange : les copies allaient bien au début, puis des stalls périodiques. Les déplacements à l’intérieur d’un dataset étaient « généralement instantanés » mais parfois
bloqués pendant des dizaines de secondes. Les utilisateurs remarquaient surtout ces blocages lors de réorganisations massives de dossiers, qui sont metadata‑lourdes et riches en renommages.
Chaque stall correspondait à une rafale d’opérations métadonnées synchrones‑moyennes et une pile de ruptures de lease car plusieurs clients regardaient les mêmes arbres.

L’équipe stockage a chassé les disques. L’équipe réseau a chassé le MTU. L’équipe Windows a chassé les mises à jour d’Explorer. Le vrai problème était une politique :
ils avaient imposé des sémantiques « base de données » à un partage de fichiers général. La correction n’a pas beaucoup amélioré la justesse (SMB avait déjà des mécanismes de durabilité),
mais la latence a empiré. Ils ont rétabli strict sync uniquement sur les partages où les exigences métier le justifiaient, et déplacé les données critiques vers un partage avec des attentes explicites et des fenêtres de maintenance planifiées.

Les poignées durables n’étaient pas le vilain. Le vilain était de prétendre que toutes les données ont les mêmes sémantiques d’écriture. Ce n’est pas le cas.

Pratique ennuyeuse mais correcte qui a sauvé la mise : conception des frontières et fenêtres de maintenance

Une entreprise avec une grande équipe d’ingénierie exécutait une tâche hebdomadaire de « nettoyage » du système de fichiers : purge, archivage, réorganisation.
Ils avaient appris (à la dure, des années plus tôt) que des renommages massifs en heures ouvrées créent des tempêtes de rupture de lease et des utilisateurs mécontents.
Ils ont donc fait deux choses ennuyeuses.

D’abord, ils ont conçu les partages pour que les déplacements les plus courants restent dans un dataset. « Projet actif » et « Archive projet » vivaient dans le même dataset avec une frontière de répertoire, pas des datasets séparés.
La rétention était gérée par snapshots et politiques de réplication, pas en forçant les utilisateurs à déplacer entre filesystems.

Ensuite, ils ont planifié toute migration cross-dataset pour une fenêtre dédiée, l’ont annoncée, et l’ont limité en débit. Ils ont utilisé un outil contrôlé côté serveur (pas le glisser‑déposer d’Explorer)
pour mesurer le comportement et éviter les effets de « thundering herd » de dizaines de clients.

Une semaine, un changement réseau a causé de brèves déconnexions sur un étage. Les portables se sont reconnectés. Les poignées durables ont fait leur travail. Le travail de migration a continué sans corruption.
Les utilisateurs ont à peine remarqué. Le compte-rendu d’incident fut court et ennuyeux, ce qui est le compliment le plus élevé en opérations.

Petite blague #2 : Si vous voulez de l’excitation, gérez une discothèque. Si vous voulez de la fiabilité, gérez un serveur de fichiers.

Erreurs courantes : symptôme → cause racine → correction

1) Symptôme : « Déplacer sur le même serveur est aussi lent qu’une copie »

Cause racine : Le déplacement traverse des partages SMB ou des datasets ZFS, il ne peut donc pas être un renommage ; Windows retombe sur copie+suppression.

Correction : Placez la source et la destination dans le même partage et dataset pour les flux courants ; ou acceptez que ce soit une copie et dimensionnez le système en conséquence.

2) Symptôme : « Déplacement bloqué à 99 % »

Cause racine : Poignées ouvertes ou suppression différée ; Explorer attend la finalisation des suppressions/métadonnées pendant qu’un autre client détient un lease/oplock.

Correction : Utilisez smbstatus --locks pour identifier les bloqueurs ; rompez la dépendance (fermez l’application, réveillez les portables, réduisez les watchers de répertoires).

3) Symptôme : « Dossier déplacé, mais il apparaît encore à l’ancienne emplacement »

Cause racine : Cache côté client, cache d’énumération de répertoire, ou mise à jour différée due à des ruptures de lease.

Correction : Forcez un rafraîchissement, confirmez l’espace de noms sur le serveur avec un ls côté serveur. Si c’est cohérent sur le serveur, traitez-le comme un cache client. Si c’est incohérent, vérifiez les logs SMB pour des erreurs.

4) Symptôme : « Nous avons supprimé des téraoctets mais l’espace n’est pas revenu »

Cause racine : Les snapshots retiennent les blocs ; les suppressions ne retirent que les références live.

Correction : Inspectez l’usage des snapshots ; ajustez la rétention, ou déplacez les données vers un dataset avec une politique de snapshots adéquate.

5) Symptôme : « Pauses aléatoires pendant copie/déplacement de nombreux fichiers »

Cause racine : Ruptures de lease/oplock ; stalls d’E/S metadata ; pression ARC ; politiques synchrones metadata.

Correction : Corrélez les logs Samba avec iostat et les statistiques ARC. Réduisez les opérations concurrentes sur les arbres et corrigez la latence de stockage en premier.

6) Symptôme : « Après une coupure Wi‑Fi, l’application continue d’enregistrer, mais le renommage échoue »

Cause racine : La réclamation de poignée durable a réussi, mais le renommage ultérieur entre en conflit avec les modes de partage ou une poignée rivale sur le chemin de destination.

Correction : Vérifiez les ouvertures sur la source et la destination ; envisagez des changements de workflow (enregistrer dans un fichier temporaire puis renommage atomique) et assurez-vous que le serveur fournit des IDs de fichier stables.

7) Symptôme : « Copie rapide, déplacement lent (dans le même dataset) »

Cause racine : Le déplacement déclenche des schémas rename/unlink qui provoquent plus de ruptures de lease et de mises à jour metadata ; la copie peut être un flux plus lisse si les clients ne concourent pas sur l’espace de noms.

Correction : Mesurez les ruptures de lease et la latence metadata ; planifiez les réorganisations massives et évitez de les faire quand de nombreux clients parcourent le même arbre.

8) Symptôme : « Robocopy /Z fonctionne, Explorer échoue »

Cause racine : Comportements clients différents. Robocopy utilise le mode restartable et des sémantiques de retry différentes ; Explorer est orienté interface et parfois plus sensible aux erreurs perçues.

Correction : Pour les migrations, utilisez des outils robustes (Robocopy, outils côté serveur) avec des flags explicites ; traitez Explorer comme un outil de commodité, pas comme un système de migration.

Listes de contrôle / plan pas à pas

Checklist de conception : prévenir les surprises « le déplacement est devenu une copie »

1. Listez les 5 principaux flux utilisateurs qui impliquent la réorganisation des données (déplacements/renommages).
2. Assurez-vous que ces flux restent dans un seul partage SMB autant que possible.
3. Assurez-vous que ces flux restent dans un seul dataset ZFS lorsque le « déplacement instantané » est requis.
4. Utilisez les datasets pour la politique (snapshots/quotas/réplication) quand cela ne casse pas les workflows — ou cachez les frontières derrière une racine de partage unique.
5. Décidez quels partages nécessitent des sémantiques de durabilité strictes et lesquels privilégient débit/latence ; documentez cette décision.

Checklist opérationnelle : quand les utilisateurs se plaignent du comportement Copier/Déplacer

1. Demandez : chemin source, chemin destination, nombre approximatif de fichiers, types de fichiers, et si d’autres utilisateurs parcouraient l’arbre.
2. Vérifiez si cela a traversé des partages/datasets (Tâche 1, Tâche 3).
3. Vérifiez si des écritures sur le pool ont culminé pendant le « déplacement » (Tâche 12).
4. Si renommage : vérifiez les ruptures de lease et les verrous (Tâche 5, Tâche 15).
5. Corrélez avec la latence disque et la pression ARC (Tâche 8, Tâche 9).
6. Vérifiez les snapshots si « la suppression n’a pas libéré d’espace » fait partie de la plainte (Tâche 7).
7. Une fois que vous avez des preuves, changez une variable à la fois (option de partage, planification, layout de dataset).

Checklist de migration : déplacer des données entre datasets sans drame

1. Privilégiez les outils côté serveur pendant une fenêtre de changement ; ne comptez pas sur le glisser-déposer d’Explorer pour des téraoctets.
2. Bridez la concurrence ; les déplacements de petits fichiers ne s’améliorent pas forcément avec « plus de threads » une fois que les métadonnées sont le goulot.
3. Gelez ou coordonnez les politiques AV/indexation si possible (ou anticipez la surcharge).
4. Mesurez : latence IOPS, ruptures de lease SMB, et nombre de poignées ouvertes pendant la migration.
5. Ayez un plan de rollback : si les tempêtes de lease impactent les utilisateurs, arrêtez proprement le travail et reprenez plus tard.

FAQ

1) Les poignées durables sont‑elles une fonctionnalité de ZFS ?

Non. Les poignées durables sont une fonctionnalité du protocole SMB implémentée par le serveur SMB (souvent Samba sur systèmes Unix-like). ZFS influence la qualité
avec laquelle le serveur peut mapper une identité de fichier stable et la rapidité des opérations metadata.

2) Pourquoi déplacer un dossier prend‑il parfois plus de temps que le copier ?

Parce que le « déplacer » d’un arbre peut être une tempête de renommages et suppressions qui déclenche des ruptures de lease et des mises à jour metadata. Une copie peut
être un flux plus lisse si les clients ne concurrencent pas l’espace de noms.

3) Si je désactive les poignées durables, les déplacements redeviendront‑ils normaux ?

Généralement non. Si votre « déplacement » est en réalité une copie+suppression due aux frontières de partage/dataset, désactiver les poignées durables ne changera rien.
Si votre problème est lié aux ruptures de lease et à la rétention de poignées, désactiver la durabilité peut réduire l’état mais détériore la tolérance aux reconnexions.
Corrigez d’abord l’architecture, puis peaufinez.

4) Pourquoi déplacer entre deux dossiers dans le même partage se comporte‑t‑il comme une copie ?

Deux dossiers peuvent quand même être sur des datasets différents à cause de points de montage à l’intérieur du chemin du partage. Le chemin semble continu ; le filesystem ne l’est pas.
Confirmez avec zfs list -o mountpoint et le path = du partage.

5) Quel est le lien entre leases SMB et les « blocages » ?

Quand le serveur a besoin qu’un client abandonne un cache ou vide des écritures en attente, il casse le lease. Si le client répond lentement (veille, charge CPU, scan AV), le serveur attend.
Votre déplacement attend. Cet attente est la cohérence qui fait son travail.

6) Pourquoi Explorer affiche « calcul du temps restant » indéfiniment ?

Explorer a du mal avec les charges dominées par les métadonnées et les petits fichiers, surtout sur le réseau. Il est aussi mauvais pour prédire les opérations qui changent de nature en cours de route
(renommage réussi pour certains fichiers, fallback copie pour d’autres).

7) Les snapshots ralentissent‑ils les déplacements SMB ?

Les snapshots ne ralentissent généralement pas le renommage lui‑même. Ils affectent les suppressions et la réclamation d’espace. Si vous faites une copie+suppression entre datasets,
les snapshots sur la source ou la destination peuvent changer l’amplification d’écriture et les résultats de capacité.

8) Comment prouver à la direction que « le déplacement est devenu une copie » ?

Montrez une bande passante d’écriture soutenue du pool pendant un « déplacement » (Tâche 12). Puis montrez la frontière dataset ou le mapping cross-share (Tâche 1/3).
Les renommages ne génèrent pas de grosses écritures soutenues ; les copies le font.

9) Est‑ce différent sur TrueNAS ou d’autres appliances ZFS ?

Les principes sont les mêmes. L’appliance peut exposer des options ou des valeurs par défaut différentes, mais les sémantiques SMB ne changent pas : le renommage n’est atomique qu’au sein d’un contexte filesystem/share ; les poignées durables et les leases exigent toujours un suivi d’état et une coordination.

10) Que dois‑je changer en premier : le tuning ZFS ou le tuning Samba ?

Aucun des deux en premier. Changez d’abord la disposition : gardez les déplacements courants à l’intérieur d’un même dataset/share. Puis mesurez. Ne peaufinez qu’après avoir identifié un goulot précis :
latence metadata, contention de verrous, ou politique d’écritures synchrones.

Prochaines étapes concrètes

Si vous voulez que Copier/Déplacer cesse d’être étrange, arrêtez de le traiter comme un mystère et commencez à le traiter comme un problème de classification :
renommage ou copie ? Une fois que vous savez, la solution devient évidente et généralement ennuyeuse.

1. Inventoriez vos partages et datasets et dessinez une carte des frontières que les utilisateurs ne peuvent pas franchir par erreur dans leurs workflows normaux.
2. Choisissez une « zone de déplacement rapide » (dataset unique, racine de partage unique) pour les équipes qui réorganisent constamment.
3. Instrumentez les ruptures de lease et les verrous (augmentez brièvement le niveau de log lors d’incidents) pour distinguer « contention client » de « latence stockage ».
4. Planifiez les réorganisations massives et les migrations hors des heures de pointe, et utilisez des outils contrôlés plutôt qu’Explorer.
5. Alignez la politique de snapshots avec la réalité : si l’entreprise s’attend à récupérer l’espace immédiatement, ne gardez pas de snapshots de longue durée sur ce dataset.

Les poignées durables font le travail de fiabilité que vous ne voulez pas faire manuellement. Laissez‑les faire. Ne construisez simplement pas un layout de partage/dataset qui force chaque « déplacement » à devenir une copie, puis soyez surpris quand la physique se manifeste.