Présentation
Le benchmark modern-fs-benchmark publié le 18 septembre 2026 compare deux configurations de bcachefs : ec (erasure‑coding) et replicas2 (double réplication). Les tests s’exécutent sous le noyau Linux 7.0.0‑1012‑azure et utilisent la suite d’outils version 1.39.6. Chaque scénario mesure la bande passante séquentielle, les IOPS aléatoires, les temps de latence et divers indicateurs de gestion d’espace.
Performances séquentielles
En écriture séquentielle, ec atteint 96 MiB/s alors que replicas2 double ce chiffre à 194 MiB/s. La lecture séquentielle reste plus élevée : 416 MiB/s pour ec contre 363 MiB/s pour replicas2. Cette différence reflète le coût du calcul d’érasure‑coding, qui consomme CPU et bande passante, tandis que la réplication simple profite d’un accès plus direct aux blocs.
Performances aléatoires et latence
Les IOPS d’écriture aléatoire (randwrite_iops) sont de 7 480 IOPS pour ec et de 9 004 IOPS pour replicas2. En lecture aléatoire, ec surpasse replicas2 avec 15 504 IOPS contre 11 236 IOPS. Les charges à 4 KB (randwrite4_iops) montrent un écart plus marqué : 9 973 IOPS pour ec et 17 524 IOPS pour replicas2. Les latences en mode inactif restent faibles (lat_idle_p99_ms ≈ 3–4 ms), mais sous charge elles explosent : lat_load_p99_ms atteint 2 734 ms (ec) et 2 936 ms (replicas2), indiquant que les files d’attente se remplissent rapidement lorsque le système est sollicité.
Gestion de l’espace, compression et résilience
Les deux configurations affichent un ratio de compression de 3,74 :1, avec des débits de compression en écriture de 308 MiB/s (ec) et 335 MiB/s (replicas2). Le processus de « reclaim » libère environ 80 % – 82 %** de l’espace disponible, avec des débits de 23 MiB/s (ec) et 26 MiB/s (replicas2). Les snapshots sont créés en 35 ms (ec) et 34 ms (replicas2), mais leur suppression reste coûteuse : plus de 2,8 s dans les deux cas.
En situation de disque presque plein (nearfull95 et nearfull99), la configuration ec montre une écriture très limitée (1,95 MiB/s** à 3,9 MiB/s), alors que replicas2 maintient des débits supérieurs à 138 MiB/s. Cette différence confirme que la réplication gère mieux les scénarios de saturation d’espace.
Le benchmark indique que les opérations enospc_delete_ok et enospc_recover_ok réussissent, que les scrubs (41 s pour ec, 48 s pour replicas2) ne détectent aucune corruption, et que l’intégrité des données reste assurée (data_intact = true).
