Samba 4.25 introduit les poignées persistantes SMB3 pour des partages qui survivent au redémarrage
La version 4.25.0 de Samba, publiée le 24 septembre 2026, embarque à titre expérimental les poignées persistantes SMB3, brique de base de la bascule transparente. Le gain — des fichiers qui restent ouverts après une panne — se paie d’un surcoût de stockage et d’un partage réservé au seul protocole SMB.
24 septembre 2026. Samba publie la version 4.25.0 de son serveur de fichiers libre, première série stable de cette branche. 2012. Microsoft introduisait déjà la « disponibilité continue » dans Windows Server 2012 grâce aux poignées persistantes SMB3. 25 septembre 2026. Phoronix confirme que Samba rattrape son retard en embarquant, à titre expérimental, le même mécanisme. Pourquoi c’est important : un partage SMB devient capable de survivre à un redémarrage du serveur sans que les clients n’aient à rouvrir leurs fichiers — à condition d’accepter un surcoût de stockage significatif.
Ce que font les poignées persistantes
Une poignée est l’identifiant qu’un client SMB reçoit quand il ouvre un fichier. En temps normal, cette poignée n’a de valeur que le temps de la connexion : si le serveur redémarre, la session tombe et le client doit rouvrir chaque fichier, perdant au passage les verrous et les écritures non abouties.
Les poignées persistantes SMB3 changent cette règle. Samba persiste l’état de chaque poignée — l’ouverture, les mises à jour, les baux et les fermetures — sur un stockage durable, afin de pouvoir reconstruire les fichiers ouverts quand le client se reconnecte après une panne. Concrètement, une machine virtuelle dont le disque est servi par SMB ou une base de données en cluster peut tolérer une coupure momentanée du nœud sans avoir à rouvrir ses fichiers.
La capacité est annoncée aux clients via le flag de protocole SMB2_CAP_PERSISTENT_HANDLES. Pour l’activer sur un partage, il faut deux réglages : l’option globale persistent handles et l’option par partage continuous availability. Les deux doivent être réunis — l’une sans l’autre ne produit rien.
Ce que le client ressent est précisément l’intérêt de la fonction. Lors d’une bascule, il conserve sa connexion et ses fichiers ouverts au lieu de recevoir une erreur réseau et d’être contraint de tout rouvrir. C’est la différence entre une charge qui marque une pause brève et une charge qui doit reconstruire son état depuis zéro — celle-là même qui compte pour les systèmes de fichiers en cluster et les images de machines virtuelles, où une poignée perdue peut corrompre une écriture en vol ou forcer un invité à remonter son disque.
[global]
persistent handles = yes
persistent handles durability = full_outage
[cluster_share]
path = /srv/cluster_share
continuous availability = yes
kernel oplocks = no
kernel share modes = no
posix locking = noLe prix à payer : persistance synchrone et SMB exclusif
La fonction n’est pas gratuite, et Samba le dit sans détour dans ses notes de version. Chaque opération d’ouverture, de mise à jour, de bail ou de fermeture doit être persistée de façon synchrone sur le stockage durable. Résultat : la latence augmente par rapport à un serveur de fichiers classique, au point que le projet recommande de réserver la fonction aux charges qui exigent réellement la disponibilité continue et de ne pas l’activer sur un serveur de fichiers généraliste.
Le second coût est moins visible mais tout aussi structurant. Parce que Samba doit conserver l’état SMB par lui-même, les poignées persistantes imposent un partage en accès exclusif SMB. Trois réglages deviennent obligatoires : kernel oplocks = no, kernel share modes = no et posix locking = no. Traduction concrète : le partage cesse d’être interopérable avec un accès local POSIX ou des clients NFS. C’est un choix d’architecture, pas un détail de configuration — on abandonne la double voie d’accès pour gagner la survie des poignées.
La durabilité en cluster, un compromis à deux vitesses
En cluster, l’état des poignées vit dans une base ctdb volatile répliquée sur chaque nœud, doublée d’une copie de sauvegarde dans une base ctdb persistante. Seule cette copie de sauvegarde permet aux poignées de survivre à une panne simultanée de tous les nœuds — par exemple une fenêtre de maintenance où l’on éteint tout le cluster, qui efface les bases volatiles.
Maintenir cette sauvegarde a un coût : chaque changement d’état d’une poignée déclenche une transaction cluster-wide supplémentaire, écrite sur le stockage stable de chaque nœud. C’est là qu’intervient la nouvelle option persistent handles durability, qui laisse l’administrateur choisir son camp entre performance et durabilité.
full_outage est la valeur par défaut. La copie de sauvegarde est maintenue et les poignées survivent à une panne de tout le cluster. partial_outage supprime la sauvegarde : les poignées survivent à toute panne qui laisse au moins un nœud debout — un crash de nœud, un redémarrage roulant, la perte de tous les nœuds sauf un — mais sont perdues si tout le monde tombe en même temps. En échange, chaque opération d’ouverture, de mise à jour, de bail et de fermeture devient nettement moins chère.
Le compromis est propre et chiffrable dans sa logique : si votre bascule repose sur la redondance des nœuds plutôt que sur la survie d’un arrêt total, partial_outage suffit et vous fait gagner de la latence. Si vous devez survivre à un arrêt complet planifié, restez sur full_outage.
Ce que 4.25 apporte d’autre
La branche ne se résume pas aux poignées persistantes. Le module VFS vfs_aio_ratelimit gagne une coordination cluster-wide : les limites de débit par partage sont désormais appliquées comme un plafond global sur tout le cluster, et non plus nœud par nœud. Un nouveau démon, ratelimitd, agrège l’activité des processus smbd de chaque nœud et diffuse des résumés via la couche de messagerie de Samba — la compilation doit être faite avec --with-ratelimitd.
Un nouveau module VFS, vfs_ceph_rgw, utilise l’API librgw pour exporter les buckets du Ceph Object Gateway sous forme de partages SMB, avec une vue hiérarchique des objets présentés comme des fichiers et des dossiers. La journalisation d’audit JSON est nettoyée — les deux espaces qui précédaient l’accolade ouvrante disparaissent, et les sauts de ligne intégrés sont convertis en espaces. Enfin, les types de chiffrement de domaine passent à AES par défaut pour les domaines de niveau fonctionnel 2008 ou supérieur.
Verdict
Si vous servez des disques de machines virtuelles ou des bases de données en cluster par SMB, testez les poignées persistantes sur un environnement de préproduction : c’est la brique qui manquait pour une bascule réellement transparente, mais mesurez d’abord la latence ajoutée sur votre charge, car la persistance synchrone n’est pas neutre. Si vous exploitez un serveur de fichiers généraliste, n’activez pas la fonction : le surcoût de stockage et l’abandon de l’accès POSIX/NFS ne se justifient pas. Si votre cluster doit survivre à un arrêt complet, restez sur persistent handles durability = full_outage ; sinon, partial_outage vous rendra la latence perdue sans sacrifier la redondance qui compte. Dans tous les cas, rappelez-vous que la fonction est expérimentale — elle documente une direction, pas une destination stable.