Je suis l'auteur de la dépêche de 2012 et, en tant qu'utilisateur de btrfs, je dois bien admettre que son développement est frustrant tant il est lent. Pour autant, il n'est pas à l'arrêt. La mailing list des développeurs en atteste (en réagissant notamment à l'annonce de Redhat) : ça travaille toujours dessus. Peu d'améliorations visibles, beaucoup de polissage et de stabilisation. Il n'y a pas de mystère : si ça avance peu c'est que les hp, Redhat, Oracle, Facebook (l'employeur de Chris Mason, un des développeurs principaux) n'investissent pas assez dedans. S'ils mettaient chacun ne serait-ce que deux devs à temps plein, ça pourrait booster l'évolution de btrfs.
Quand je lis ces dépêches sur un développeur qui, d'un seul coup, se met en tête d'écrire un système de gestion de fichiers avec Copy on Write en partant de rien, ça me fait marrer. Même en étant un génie, cette personne ne va pas arriver à la stabilité d'un vénérable ZFS (qui a 7 ou 8 ans de plus que btrfs et un peu plus de développeurs actifs) en un jour.
Si je devais résumer les conseils d'utilisation heureuse de btrfs, je dirais :
Avoir un noyau aussi récent que possible
Avoir les outils btrfs les plus récents possibles
Ne pas laisser le nombre de snapshots s'envoler. Quelques centaines, ça reste gérable. Au delà ça rame de trop.
Éviter le RAID 5/6 (dernièrement réécrit en partie) mais le RAID 1, 0, 1+0, c'est bien stable.
Éviter la compression transparente (j'ai déjà été mordu... :) )
Les bases de données, les images de VM peuvent se fragmenter très vite sur un volume btrfs. L'option autodefrag y remédie en partie... mais pour les meilleures perfs brutes, mieux vaut ici partir sur de l'xfs ou de l'ext4.
La gestion des quotas par volume est aussi dans la sphère du "peu testé". À éviter.
Planifier des "scrub" (relecture et vérification des checksums des blocs) réguliers
Garder un œil sur les statistiques disque de btrfs, qui peuvent indiquer qu'un disque commence à exhiber des erreurs. En RAID1 ou 5, il est alors temps de remplacer le disque défectueux avant d'expérimenter des pertes de données
Les snapshots, même si ça ne sert pas très souvent, c'est quand même bien pratique... et la possibilité de transmettre (comme ZFS) ces derniers entre machines (entiers ou deltas entre 2 snaps), c'est aussi bien commode.
# Juste une histoire de ressources de développement
Posté par AP . En réponse au journal Btrfs ne serait plus le futur. Évalué à 10.
Je suis l'auteur de la dépêche de 2012 et, en tant qu'utilisateur de btrfs, je dois bien admettre que son développement est frustrant tant il est lent. Pour autant, il n'est pas à l'arrêt. La mailing list des développeurs en atteste (en réagissant notamment à l'annonce de Redhat) : ça travaille toujours dessus. Peu d'améliorations visibles, beaucoup de polissage et de stabilisation. Il n'y a pas de mystère : si ça avance peu c'est que les hp, Redhat, Oracle, Facebook (l'employeur de Chris Mason, un des développeurs principaux) n'investissent pas assez dedans. S'ils mettaient chacun ne serait-ce que deux devs à temps plein, ça pourrait booster l'évolution de btrfs.
Quand je lis ces dépêches sur un développeur qui, d'un seul coup, se met en tête d'écrire un système de gestion de fichiers avec Copy on Write en partant de rien, ça me fait marrer. Même en étant un génie, cette personne ne va pas arriver à la stabilité d'un vénérable ZFS (qui a 7 ou 8 ans de plus que btrfs et un peu plus de développeurs actifs) en un jour.
Si je devais résumer les conseils d'utilisation heureuse de btrfs, je dirais :
Les snapshots, même si ça ne sert pas très souvent, c'est quand même bien pratique... et la possibilité de transmettre (comme ZFS) ces derniers entre machines (entiers ou deltas entre 2 snaps), c'est aussi bien commode.
Bref, ne jetons pas le bébé avec l'eau du bain.