Sur un disque classique, on cherche un fichier à son emplacement. Dans un stockage adressé par contenu, on identifie aussi ce qu’il contient. Deux blocs identiques peuvent alors partager la même place dans le magasin. C’est une idée simple ; les choses deviennent plus intéressantes quand on ajoute les snapshots, les nœuds et les écritures concurrentes.
01
Une empreinte pour retrouver les octets
Le stockage principal découpe le chemin de stockage principal en blocs de 4 Mio et calcule leurs empreintes BLAKE3. Une empreinte sert d’identité au contenu. Un bloc déjà présent peut être réutilisé ; cela ne permet pas de prédire votre taux de déduplication sans regarder vos données.
02
Un snapshot conserve des références
Le volume garde ses métadonnées et sa racine Merkle. Le snapshot retient un état de ces références : il ne recopie pas systématiquement tous les octets du volume. Le code clone aussi des métadonnées ; on évite donc d’en déduire un coût constant ou une durée instantanée.
03
Découvrir un voisin n’est pas répliquer
Le moteur distingue un fonctionnement autonome et un cluster réellement configuré. La découverte de pairs ne suffit pas à constituer ce cluster. Les chemins de publication et de lecture doivent respecter la configuration et ses conditions de quorum.
04
FUSE ne transforme pas un prototype en CephFS
Le montage FUSE actuel reste un adaptateur expérimental de fichiers plats, avec un seul écrivain. Il ne fournit ni arborescence complète, ni métadonnées POSIX générales, ni fencing de disques VM. C’est précisément la limite à garder en tête avant de brancher une application exigeante dessus.
fichier → blocs → empreintes BLAKE3
↓
magasin de contenu
↓
volume → références → snapshot MerkleEt face aux autres outils ?
Comparaison de périmètres, sans classement de performances. Références éditeurs consultées le 31 octobre 2026.
Ceph RBD / CephFS
Ceph propose du stockage distribué en blocs et en fichiers, avec des intégrations Proxmox documentées. MeshFS propose une approche CAS/FUSE à évaluer ; aucune équivalence de disponibilité ou de performances n’est établie.
Documentation de référence ↗ZFS / NFS
ZFS fournit des instantanés locaux ; NFS expose un stockage de fichiers partagé. Le choix dépend d’abord de l’emplacement des données, des pannes à couvrir et du besoin de partage.
Documentation de référence ↗CephFS
CephFS expose un système de fichiers distribué POSIX. Le montage expérimental MeshFS a un périmètre plus restreint, à distinguer de cette couverture.
Documentation de référence ↗NFS
Le backend NFS de Proxmox monte un partage de fichiers existant. Ses snapshots de disques reposent sur qcow2 ; le protocole NFS ne fournit pas lui-même des snapshots.
Documentation de référence ↗Sources et références
Les mécanismes sont présentés avec leur périmètre d’utilisation. Leur qualification dans votre environnement reste une étape distincte. Les liens ci-dessous donnent accès aux références publiques disponibles.