C’est bien mais ce serait mieux que les systèmes de fichier qui gagnent en performance soient les systèmes avec copie-à-l’écriture (Copy on Write).
Les systèmes de fichier comme ext4 avec leur systèmes d’inode prédéterminé au formatage comme dans les années 80 et sans copie à l’écriture ne sont plus sérieux que dans des cas très spécifiques et qui deviennent désormais très rares.
Dès qu’un active la copie à l’écriture (Btrfs, ZFS…) on peut :
faire un instantané du volume que l’on va sauvegarder, et continuer à modifier le système de fichier d’origine alors que la sauvegarde est en cours,
faire des instantanés régulièrement pour une restauration facile ou simplement une consultation sans même avoir à utiliser la sauvegarde,
démarrer sur un instantané créé avant une mise à jour,
dédupliquer les fichiers en général,
dédupliquer les images disques (de machine virtuelle ou non), ça c’est vraiment un truc de fou, tu as 5 machines virtuelles Debian? Tu peux les dédupliquer, elles ne prendront pas 5 fois la place sur le disque…
etc.
ce commentaire est sous licence cc by 4 et précédentes
Posté par Nicolas (site web personnel) .
Évalué à 6 (+5/-0).
Dernière modification le 16 mars 2026 à 08:26.
Pour les cas pathologique le CoW est désactivable (entre autres options de contrôle fin du système de fichiers) : btrfs(5), chattr(1).
Sans ça c'est mal barré…
Pour ce qui est de la déduplication je vois mal comment ce serait utilisable en pratique (il faudrait comparer deux à deux tous les blocs alloués… ça peut se faire ponctuellement sur deux fichiers précis) ; je pense que tu voulais parler des reflinks, mais les hardlinks font déjà pas mal le taf (et pour les machines virtuelles avoir des partitions communes sont une manière plus fiable d'arriver au résultat escompté).
PS : non les snapshots ne sont pas de vraies sauvegardes aussi longtemps qu'ils restent sur le même device.
Exactement, avant que je convertisse les serveurs à btrfs, quand un utilisateur supprimait son fichier par erreur, il devait me faire une demande de restauration depuis la sauvegarde.
Après que j’ai fait la conversion à btrfs, ils ont eu un disque réseau spécial où chaque dossier de travail auquel ils ont accès ont commencé à produire des instantanés nommés par date. Chaque instantané est alors réalisé toutes les heures alors que la sauvegarde chaque nuit. Fichier supprimé ? Écrasé ? Corrompu ? L’utilisateur peut le récupérer de lui-même et avec une version qui a moins d’une heure.
En plus la magie c’est que puisque le disque de “machine à remonter le temps” utilise la même infrastructure de partage, bah il n’y a rien à implémenter côté gestion des droits. Les gens voient les instantanés de fichiers qui ont leur permission.
Je fait du btrfs depuis au moins 10 ans maintenant, c’est magique.
ce commentaire est sous licence cc by 4 et précédentes
Ça dépend du système d’exploitation s’il implémente la copie reflink quand il accède au système de fichier en direct, ou bien s’il utilise la copie côté serveur si sur un disque réseau.
Et le principe d’avoir le service bees qui tourne c’est d’attraper tout le reste qui ne serait pas déjà dédupliqué au moment de la copie.
Par exemple si tu as plusieurs utilisateurs qui reçoivent le même PDF par mail et que chacun le télécharge, bees s’en chargera.
ce commentaire est sous licence cc by 4 et précédentes
Posté par Psychofox (Mastodon) .
Évalué à 8 (+5/-0).
Dernière modification le 16 mars 2026 à 11:31.
La dedup (au niveau des blocks) fonctionne très bien sur ZFS…pour peu que tu aies beaucoup de RAM.
Les instantanés te facilitent certaines sauvegardes car ça permet de réduire le temps où une appli est stoppée / ou des requêtes sont mises en attentes. Tu snap, et après tu sauve sur environnement de backup/
C’est un service, il explore ton système de fichier et déduplique, il conserve un cache pour savoir où il en est.
La première exécution peut prendre beaucoup de temps puisqu’il va tout lire et tout dédupliquer, mais ensuite, bah il ne traite que ce qui est nouveau/a changé.
Je parle bien de reflink. Le hardlink est tout le contraire du copy on write, puisque l’écriture modifie le fichier lié, au lieu de copier pour délier avant d’écrire.
Bees fait la déduplication à l’intérieur des fichiers, c’est pour ça que ça va même dédupliquer tes images disques. Genre t’as une machine virtuelle Debian ? Tu dump dans un fichier avec dd une clé USB Debian ? Il va te dédupliquer les block d’octets du binaire bash.
C’est d’ailleurs pourquoi je ne compresse plus les fichier image que je sauvegarde. J’active la compression au niveau de btrfs et je stocke mes images décompressées. Bees + btrfs vont compresser et dédupliquer au niveau système de fichier.
ce commentaire est sous licence cc by 4 et précédentes
Lorsque tu édites un hard-link, la convention veut que ça se fasse inplace mais rien n'empêche de produire une copie, travailler dessus, et rename/replace à l'écriture disque (garantie d'atomicité en Posix). C'est du CoW au sens strict, mais à haut niveau (inode). C'est obligatoire même sur un fs CoW (block) si tu veux modifier un fichier de manière atomique pour apporter des garanties de cohérence et d'intégrité de tes données (un système de fichier est trop bas niveau dans le cas ou le besoin est fonctionnel/métier).
Et je viens de jeter un œil, il emploie une heuristique basée à la fois sur la proximité et l'ancienneté des blocs, un CRC détourné en fonction de hashage, une limitation ad-hoc de l'utilisation des ressources machine. Bref beaucoup de contournements (sans tests de leur pertinence à priori) pour rendre le traitement moins consommateur.
Le hash occupe 8 octets sur des blocs de 4096, 19Go/10To, et il proclame 0.1Go, donc j'imagine assez bien les trous dans la raquette. Ce serait à tester face à un algorithme qui teste tous les blocs et retient tous les hash (bon pas sûr qu'il soit applicable), est-ce qu'au moins le logiciel rend compte du taux de déduplication, tu as des statistiques d'exemples tirés de la vie réelle ?
Il y a quelques mois j’ai lancé bees sur un volume de 30To. Je n’avais pas fait de déduplication dessus depuis 5 ans (avec un autre outil, je ne sais plus lequel). J’ai lancé la déduplication parce qu’il ne restait que 1To de libre… Ça a tourné quelques jours, et ça m’a libéré 5To. De quoi voir venir pour plusieurs mois ou peut-être années.
Et maintenant que bees a tout exploré je le laisse tourner en tâche de fond et il se fait oublier,
Sachant que j’optimise les systèmes pour faire du reflink le plus possible: alias cp qui active le reflink, options samba pour cumuler le sever-side copy et le reflink, etc. Évidemment on ne peut pas tout faire au moment de l’écriture, un exemple sont les dépôts Git: lors d’un checkout les fichiers sont décompressés, et si Git déduplique sa base de donnée, tout fichier restauré lors d’un checkout est « nouveau », et si en plus tu faits des instantanés réguliers du systèmes de fichier, ces copies prennent potentiellement autant de place qu’il y a eu de checkout et d’instantanés…
Bees déduplique aussi les snapshots.
ce commentaire est sous licence cc by 4 et précédentes
Quoi qu'on en pense ext4 reste le système de fichiers le plus répandu, le plus largement compatible, le plus simple, le plus stable, le moins bogué et très souvent le plus performant.
Tous le monde n'a pas besoin des capacités de snapshot intégrées au système de fichiers (et on a aussi LVM)
J'ai d'ailleurs l'impression que ces fonctionnalités posent plus de problèmes qu'elles n'apportent de solutions aux utilisateurs de base des deux distribuions qui proposent Btrfs par défaut.
sur ma config je suis passé à des partitions XFS pour tous ce qui est stockage de jeux steam, j'ai noté de manière non scientifique, une bonne amélioration lors des lancement de jeux.
Il y a pléthore de tests comparatifs des divers systèmes de fichiers sur le web. Celui donné en lien ne montre pas de différence significative entre ext4 et XFS avec les noyaux récents.
De mémoire, XFS s'avère plus performant pour manipuler de (très) gros fichiers et ext4 prend l'avantage s'il s'agit de très nombreux petits fichiers
dédupliquer les images disques (de machine virtuelle ou non), ça c’est vraiment un truc de fou, tu as 5 machines virtuelles Debian? Tu peux les dédupliquer, elles ne prendront pas 5 fois la place sur le disque…
En faisant la déduplication au niveau système de fichier t’as pas besoin d’avoir une image en commun. Tu peux dédupliquer des machines virtuelles, des dumps de disques de machines physiques, et si ton hôte est sur le même système de fichier, tu peux dédupliquer les machines virtuelles avec les fichiers de l’hyperviseur !
J’ai pas vérifié, mais il n’y a pas de raison que ça ne déduplique pas aussi des images docker avec le reste. De toute façon j’utilise aussi btrfs en backend docker car c’est requis pour faire tourner Darling dans docker.
ce commentaire est sous licence cc by 4 et précédentes
J'ai pas dis qu'il n'y a pas de raison de faire de la déduplication je dis que pour ce cas d'usage de vm, overlay fait in excellent travail en utilisant bien moins de ressources et ne contraignant pas sur la manière de déployer.
J'utilise btrfs, j'active pas la dedup par contre parce que je m'en fou
# C’est bien mais…
Posté par Thomas Debesse (site web personnel, Mastodon) . Évalué à 8 (+8/-3).
C’est bien mais ce serait mieux que les systèmes de fichier qui gagnent en performance soient les systèmes avec copie-à-l’écriture (Copy on Write).
Les systèmes de fichier comme ext4 avec leur systèmes d’inode prédéterminé au formatage comme dans les années 80 et sans copie à l’écriture ne sont plus sérieux que dans des cas très spécifiques et qui deviennent désormais très rares.
Dès qu’un active la copie à l’écriture (Btrfs, ZFS…) on peut :
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: C’est bien mais…
Posté par Nicolas (site web personnel) . Évalué à 6 (+5/-0). Dernière modification le 16 mars 2026 à 08:26.
Pour les cas pathologique le CoW est désactivable (entre autres options de contrôle fin du système de fichiers) :
btrfs(5),chattr(1).Sans ça c'est mal barré…
Pour ce qui est de la déduplication je vois mal comment ce serait utilisable en pratique (il faudrait comparer deux à deux tous les blocs alloués… ça peut se faire ponctuellement sur deux fichiers précis) ; je pense que tu voulais parler des reflinks, mais les hardlinks font déjà pas mal le taf (et pour les machines virtuelles avoir des partitions communes sont une manière plus fiable d'arriver au résultat escompté).
PS : non les snapshots ne sont pas de vraies sauvegardes aussi longtemps qu'ils restent sur le même device.
[^] # Re: C’est bien mais…
Posté par gUI (Mastodon) . Évalué à 5 (+2/-0).
Je pense que c'est pas ce qu'il a dit. Juste que t'as un accès immédiat, sans aller voir du côté de la sauvegarde (que tu as fait bien évidemment).
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: C’est bien mais…
Posté par Thomas Debesse (site web personnel, Mastodon) . Évalué à 6 (+3/-0).
Exactement, avant que je convertisse les serveurs à btrfs, quand un utilisateur supprimait son fichier par erreur, il devait me faire une demande de restauration depuis la sauvegarde.
Après que j’ai fait la conversion à btrfs, ils ont eu un disque réseau spécial où chaque dossier de travail auquel ils ont accès ont commencé à produire des instantanés nommés par date. Chaque instantané est alors réalisé toutes les heures alors que la sauvegarde chaque nuit. Fichier supprimé ? Écrasé ? Corrompu ? L’utilisateur peut le récupérer de lui-même et avec une version qui a moins d’une heure.
En plus la magie c’est que puisque le disque de “machine à remonter le temps” utilise la même infrastructure de partage, bah il n’y a rien à implémenter côté gestion des droits. Les gens voient les instantanés de fichiers qui ont leur permission.
Je fait du btrfs depuis au moins 10 ans maintenant, c’est magique.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: C’est bien mais…
Posté par orfenor . Évalué à 2 (+1/-1).
Je ne comprends pas bien : quand tu supprimes, ça va dans ta corbeille, non ? À moins que vous ne travailliez tous en console ?
[^] # Re: C’est bien mais…
Posté par Thomas Debesse (site web personnel, Mastodon) . Évalué à 4 (+1/-0).
Ça dépend du système d’exploitation s’il implémente la copie reflink quand il accède au système de fichier en direct, ou bien s’il utilise la copie côté serveur si sur un disque réseau.
Et le principe d’avoir le service bees qui tourne c’est d’attraper tout le reste qui ne serait pas déjà dédupliqué au moment de la copie.
Par exemple si tu as plusieurs utilisateurs qui reçoivent le même PDF par mail et que chacun le télécharge, bees s’en chargera.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: C’est bien mais…
Posté par Psychofox (Mastodon) . Évalué à 8 (+5/-0). Dernière modification le 16 mars 2026 à 11:31.
La dedup (au niveau des blocks) fonctionne très bien sur ZFS…pour peu que tu aies beaucoup de RAM.
Les instantanés te facilitent certaines sauvegardes car ça permet de réduire le temps où une appli est stoppée / ou des requêtes sont mises en attentes. Tu snap, et après tu sauve sur environnement de backup/
[^] # Re: C’est bien mais…
Posté par Thomas Debesse (site web personnel, Mastodon) . Évalué à 6 (+3/-0).
C’est un service, il explore ton système de fichier et déduplique, il conserve un cache pour savoir où il en est.
La première exécution peut prendre beaucoup de temps puisqu’il va tout lire et tout dédupliquer, mais ensuite, bah il ne traite que ce qui est nouveau/a changé.
Je parle bien de reflink. Le hardlink est tout le contraire du copy on write, puisque l’écriture modifie le fichier lié, au lieu de copier pour délier avant d’écrire.
Bees fait la déduplication à l’intérieur des fichiers, c’est pour ça que ça va même dédupliquer tes images disques. Genre t’as une machine virtuelle Debian ? Tu dump dans un fichier avec dd une clé USB Debian ? Il va te dédupliquer les block d’octets du binaire
bash.C’est d’ailleurs pourquoi je ne compresse plus les fichier image que je sauvegarde. J’active la compression au niveau de btrfs et je stocke mes images décompressées. Bees + btrfs vont compresser et dédupliquer au niveau système de fichier.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: C’est bien mais…
Posté par Nicolas (site web personnel) . Évalué à 3 (+2/-0).
Lorsque tu édites un hard-link, la convention veut que ça se fasse inplace mais rien n'empêche de produire une copie, travailler dessus, et rename/replace à l'écriture disque (garantie d'atomicité en Posix). C'est du CoW au sens strict, mais à haut niveau (inode). C'est obligatoire même sur un fs CoW (block) si tu veux modifier un fichier de manière atomique pour apporter des garanties de cohérence et d'intégrité de tes données (un système de fichier est trop bas niveau dans le cas ou le besoin est fonctionnel/métier).
[^] # Re: C’est bien mais…
Posté par Nicolas (site web personnel) . Évalué à 2 (+1/-0).
Et je viens de jeter un œil, il emploie une heuristique basée à la fois sur la proximité et l'ancienneté des blocs, un CRC détourné en fonction de hashage, une limitation ad-hoc de l'utilisation des ressources machine. Bref beaucoup de contournements (sans tests de leur pertinence à priori) pour rendre le traitement moins consommateur.
Le hash occupe 8 octets sur des blocs de 4096, 19Go/10To, et il proclame 0.1Go, donc j'imagine assez bien les trous dans la raquette. Ce serait à tester face à un algorithme qui teste tous les blocs et retient tous les hash (bon pas sûr qu'il soit applicable), est-ce qu'au moins le logiciel rend compte du taux de déduplication, tu as des statistiques d'exemples tirés de la vie réelle ?
[^] # Re: C’est bien mais…
Posté par Thomas Debesse (site web personnel, Mastodon) . Évalué à 4 (+1/-0). Dernière modification le 17 mars 2026 à 20:37.
Il y a quelques mois j’ai lancé bees sur un volume de 30To. Je n’avais pas fait de déduplication dessus depuis 5 ans (avec un autre outil, je ne sais plus lequel). J’ai lancé la déduplication parce qu’il ne restait que 1To de libre… Ça a tourné quelques jours, et ça m’a libéré 5To. De quoi voir venir pour plusieurs mois ou peut-être années.
Et maintenant que bees a tout exploré je le laisse tourner en tâche de fond et il se fait oublier,
Sachant que j’optimise les systèmes pour faire du reflink le plus possible: alias cp qui active le reflink, options samba pour cumuler le sever-side copy et le reflink, etc. Évidemment on ne peut pas tout faire au moment de l’écriture, un exemple sont les dépôts Git: lors d’un checkout les fichiers sont décompressés, et si Git déduplique sa base de donnée, tout fichier restauré lors d’un checkout est « nouveau », et si en plus tu faits des instantanés réguliers du systèmes de fichier, ces copies prennent potentiellement autant de place qu’il y a eu de checkout et d’instantanés…
Bees déduplique aussi les snapshots.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: C’est bien mais…
Posté par orfenor . Évalué à 2 (+0/-0).
Donc ce n'est pas intégré à Btrfs ?
[^] # Re: C’est bien mais…
Posté par Maderios . Évalué à 2 (+0/-0).
https://archlinux.org/packages/extra/x86_64/bees/
[^] # Re: C’est bien mais…
Posté par Voltairine . Évalué à 10 (+12/-0).
Quoi qu'on en pense ext4 reste le système de fichiers le plus répandu, le plus largement compatible, le plus simple, le plus stable, le moins bogué et très souvent le plus performant.
Tous le monde n'a pas besoin des capacités de snapshot intégrées au système de fichiers (et on a aussi LVM)
J'ai d'ailleurs l'impression que ces fonctionnalités posent plus de problèmes qu'elles n'apportent de solutions aux utilisateurs de base des deux distribuions qui proposent Btrfs par défaut.
[^] # Re: C’est bien mais…
Posté par ChocolatineFlying . Évalué à 1 (+1/-1).
sur ma config je suis passé à des partitions XFS pour tous ce qui est stockage de jeux steam, j'ai noté de manière non scientifique, une bonne amélioration lors des lancement de jeux.
sinon pour le reste ext4
[^] # Re: C’est bien mais…
Posté par Voltairine . Évalué à 5 (+3/-0).
Il y a pléthore de tests comparatifs des divers systèmes de fichiers sur le web. Celui donné en lien ne montre pas de différence significative entre ext4 et XFS avec les noyaux récents.
De mémoire, XFS s'avère plus performant pour manipuler de (très) gros fichiers et ext4 prend l'avantage s'il s'agit de très nombreux petits fichiers
[^] # Re: C’est bien mais…
Posté par barmic 🦦 . Évalué à 2 (+0/-0).
overlayfs est fait pour ça.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: C’est bien mais…
Posté par Thomas Debesse (site web personnel, Mastodon) . Évalué à 4 (+1/-0).
En faisant la déduplication au niveau système de fichier t’as pas besoin d’avoir une image en commun. Tu peux dédupliquer des machines virtuelles, des dumps de disques de machines physiques, et si ton hôte est sur le même système de fichier, tu peux dédupliquer les machines virtuelles avec les fichiers de l’hyperviseur !
J’ai pas vérifié, mais il n’y a pas de raison que ça ne déduplique pas aussi des images docker avec le reste. De toute façon j’utilise aussi btrfs en backend docker car c’est requis pour faire tourner Darling dans docker.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: C’est bien mais…
Posté par barmic 🦦 . Évalué à 2 (+0/-0).
J'ai pas dis qu'il n'y a pas de raison de faire de la déduplication je dis que pour ce cas d'usage de vm, overlay fait in excellent travail en utilisant bien moins de ressources et ne contraignant pas sur la manière de déployer.
J'utilise btrfs, j'active pas la dedup par contre parce que je m'en fou
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.