Taille des chunks cdc Décidé
Une cible : min 512 Kio · moyenne 2 Mio · max 8 Mio, épinglés par tenant. On penche vers le gros — plus que restic — parce que le chiffrement convergent double le coût des métadonnées par chunk.
FastCDC découpe sur le clair, BLAKE3 nomme chaque chunk. Reste à fixer les trois bornes du découpage. C’est un choix quasi-irréversible : changer les paramètres change toutes les frontières, donc toutes les adresses — c’est un re-découpage complet du dépôt. On tranche une fois, prudemment.
L’arbitrage
Le curseur oppose deux coûts.
- Petits chunks (~8–64 Kio) — meilleure granularité de dédup (modifs internes, fragments partagés entre fichiers), mais explosion des métadonnées, flot de vérifications d'existence pour un client stateless, et compression médiocre par chunk.
- Gros chunks (~1–4 Mio) — index et manifestes légers, gros débit, peu d'aller-retours, compression par chunk déjà pleine ; en échange une granularité de dédup plus grossière (une modif ré-écrit ~un chunk entier, mais FastCDC borne déjà le rayon de souffle à un seul chunk).
Le gain réel des petits chunks est étroit : les fichiers identiques dédupliquent déjà entièrement (même fichier = même manifeste = même jeu de chunks), quelle que soit la taille. Ce qu’on gagnerait, c’est surtout la dédup de fragments partagés entre fichiers différents, et la dédup des gros fichiers mutables (images VM, bases, boîtes mail) édités en place — un cas précis, à valider par la mesure avant de payer pour lui.
Ce que font les voisins
| Outil | min | moyenne | max |
|---|---|---|---|
| restic | 512 Kio | ~1 Mio | 8 Mio |
| rustic | 512 Kio | ~1 Mio | 8 Mio |
| borg | 512 Kio | 2 Mio | 8 Mio |
| kopia | 2 Mio | 4 Mio | 8 Mio |
| Cairn | 512 Kio | 2 Mio | 8 Mio |
Deux constantes : min ≥ 512 Kio et max = 8 Mio partout. restic tire vers ~1 Mio de moyenne, borg vers 2 Mio, kopia jusqu’à 4 Mio. rustic hérite par défaut du chunker de restic (compatibilité des dépôts) mais reste le seul à exposer min/moyenne/max en configuration — précédent utile pour nous.
Le facteur décisif : nos métadonnées pèsent le double
clé_chunk = BLAKE3_keyed(secret, chunk) — et cette clé ne peut pas être re-dérivée à la restauration (il faudrait le clair, précisément ce qu'on restaure). Il faut donc la stocker dans le manifeste, à côté de l'adresse : ~64 o par chunk, soit ≈ 2× restic. À taille de chunk égale, notre index et nos manifestes sont deux fois plus lourds.
Conséquence directe : le coût métadonnées est le seul qu’on ne peut pas récupérer après coup (contrairement à l’espace des blobs, que le GC finit par rendre). Donc dans le doute on vise un peu trop gros, et jamais plus petit que restic/borg.
Le piège : des paramètres non épinglés cassent la dédup
La décision
min 512 Kio · moyenne 2 Mio · max 8 Mio, FastCDC en chunking normalisé (NC niveau 2) pour resserrer la distribution autour de la cible. En Rust : la crate fastcdc.
- On ne descend à 1 Mio de moyenne que si une mesure sur une charge réelle riche en gros fichiers mutables montre un gain de dédup net.
- On ne descend jamais sous 512 Kio de minimum : en dessous, le coût métadonnées, l'overhead par chunk (tag AEAD, framing) et le flot de vérifications d'existence dominent.
- kopia va plus gros encore (2/4/8) : si l'index devient le goulot, c'est la direction — pas l'inverse.
Corollaire, traité au point Compression : à 2 Mio de chunk, chaque chunk se compresse pleinement seul — les dictionnaires zstd, utiles seulement sur de petits chunks, sont écartés.