# Bcachefs : la fin chez Debian **URL:** \ **Category:** Pause Café\ **Created:** [Septembre 12, 2024, 5:45 UTC](https://www.debian-fr.org/t/bcachefs-la-fin-chez-debian/90328 "2024-09-12T17:45:25Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Verner](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/v/34f0e0/32.png) [@Verner](https://www.debian-fr.org/u/Verner)\ **Post date:** [Septembre 12, 2024, 5:45 UTC](https://www.debian-fr.org/t/bcachefs-la-fin-chez-debian/90328/1 "2024-09-12T17:45:25Z")
Avis aux utilisateurs de [bcachefs](https://bcachefs.org/). Le dernier filesystem **bcachefs** sensé être « _mieux que_ » btrfs ou zfs ne sera plus disponible dans la prochaine version stable de Debian (trixie) pour rasion de support/maintenance. → [Orphaning bcachefs-tools in Debian – Jonathan Carter](https://jonathancarter.org/2024/08/29/orphaning-bcachefs-tools-in-debian/) ---
**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\ **Post date:** [Septembre 13, 2024, 7:14 UTC](https://www.debian-fr.org/t/bcachefs-la-fin-chez-debian/90328/2 "2024-09-13T07:14:15Z")
> [@Verner](#): > > **bcachefs** sensé être « _mieux que_ » btrfs Du fait d el’historique « The COW filesystem for Linux that won’t eat your data » 🙂 Mais btrfs s’est amélioré depuis; mais il n’est pas facile à prendre en main. ---
**Author:** ![Verner](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/v/34f0e0/32.png) [@Verner](https://www.debian-fr.org/u/Verner)\ **Post date:** [Octobre 11, 2025, 10:38 UTC](https://www.debian-fr.org/t/bcachefs-la-fin-chez-debian/90328/3 "2025-10-11T10:38:17Z")
> [@](#): > > Avis aux utilisateurs de [bcachefs](https://bcachefs.org/) - **suite** Malgré les relations tendues entre équipes de développement noyau et bcachefs, bcachefs reste finalement fourni par le noyau, **mais** son status passe de « Supported » , à «  **Externaly maintained**  ». ![btrfs_20251011](https://www.debian-fr.org/uploads/default/original/2X/4/4df853ba7eaa41a019039d943ed2acc6e4d9bafd.png) La justification est double: - ne pas pénaliser les utilisateurs ayant adopté bcachefs de manière anticipée; - permettre d’avoir du retour d’expérimentation en nombre pour débuguer/améliorer bcachefs. bcachefs doit donc être encore considéré ‹ en développement ›, sans garantie de pérennité. Alors que reste-t-il en alternative à **ext4** , compatible Debian ? **xfs** est éprouvé, mais trop ancien pour présenter un intérêt fonctionnel en 2025. **zfs / btrfs** : dans un mouchoir de poche en spécification. **zfs** : bonne réputation mais gros point négatif: pas intégré au noyau pour raison de license. Il reste donc **btrfs** qui dispose d’une excellente et impressionnante documentation de référence ( [btrfs.readthedocs](https://btrfs.readthedocs.io/en/latest/index.html) ) , et directement fourni par le noyau, assurant une mise à jour sans effort: `/lib/modules/$(uname -r)/kernel/fs/btrfs/btrfs.ko.xz` Il existe bien sûr de multiples synthèses et traductions de prise en main qui permettent de prendre ses points de repère et d’identifier les points à connaître avant adoption. Ayant adopté btrfs depuis plusieurs mois pour un usage simple, je ferai _éventuellement_ une synthèse des points qui me semblent utiles à connaître avant adoption. **Remarque plus générale** : → comparer des file-systems est un exercice difficile, et ne peut se faire avec 3 clics dans une poubelle internet remontant à 15 ans. btrfs est né en 2010, et utilisé sur des milliers de serveurs face~book. Se faire une idée à la lecture d’un utilisateur qui s’énerve parque-qu’il a saturé une partition avec des snapshots incontrolés, qui s’est automatiquement auto-protégée en passant en status « ro » (read-only) n’a aucune valeur pour se faire un avis. Se faire un avis à partir de l’adoption ou abandon de btrfs par une compagnie **privée** (R.H. par exemple) aboutira aussi à une conclusion erronée. La prise en main de btrfs demande un peu de calme et de sérénité. btrfs s’adresse particulièrement à ceux qui fuient les montages LVM/ext4/RAID fragiles en manipulation.