Oui, et de loin franchement.
Ses fonctionnalités sont déjà largement en avance par rapport à celles de reiserfs (et reprennent comme tu le signale les bonnes propriétés de celui-ci).
Le plus important (à mes yeux, concernant un système de fichier, et en comparaison avec reiserfs) est qu'il promet d'être très activement maintenu, suscitant l'intérêt vif et la participation de développeurs critiques chez IBM, Red Hat, SUSE, Oracle, Intel. Cette diversité est prometteuse, car elle signifie que bientôt chacune de ces sociétés sera capable de gérer les bugs rencontrés par ses clients, donc en mesure de proposer et supporter officiellement ce système de fichiers, de l'affiner pour ses workloads spécifiques, etc. Par contraste, reiserfs est désormais en mode "maintenance faible" chez SUSE et Mandriva, son développeur principal ne participe plus, et il n'est tout simplement pas supporté par Red Hat (autrement dit : peu de chances d'améliorations fonctionelles, désormais, à la différence de ext4, XFS et btrfs).
Une fonctionnalité bluffante pas décrite dans la dépêche, et pas faisable avec les outils actuels (LVM) : btrfs permet de faire des snapshots d'un répertoire quelconque du système de fichier (par ex. juste le /etc). D'autre part, il n'est pas nécessaire de réserver de l'espace disque dès le départ pour pouvoir faire ses snapshots (comme avec LVM). Ce sont de petits détails, mais il y en a beaucoup comme ça, et ils chacun peu, je pense, changer la vie des sysadmins :).
Pour répondre à la question de Michel plus haut :
> Par contre comment se débrouille Btrfs par rapport à la "concurrence" sur SSD ?
Pour le moment btrfs ne fait pas grand chose de spécifique pour les SSD. En pratique : la routine de recherche permettant de trouver de l'espace libre et utilisable parmi les extents alloués dispose d'un raccourcis/court-circuit dans le cas du SSD.
Mais il est prévu d'essayer de tirer le meilleur partis, de façon spécifique, des SSD, c'est d'ailleurs pour ça qu'une option de montage spécifique "ssd" est déjà intégrée.
XFS (depuis peu, et de façon encore expérimentale) et btrfs intègrent des fonctionnalités de gestion des périphériques multiples (normalement dévolues aux couches MD et LVM du noyau) précisément pour se permettre ce genre d'optimisations : en connaissant précisément la couche physique (le matériel sous-jacent), ils pourront décider au mieux de l'agencement des données. Par exemple, dans un aggrégat de disques durs et de SSD : placer les métadonnées (nécessitant beaucoup d'accès aléatoires) sur le SSD et les données dont l'accès est plus séquentiel sur disque dur, ou encore (et parce que, pour des raisons de fiabilité, btrfs permet de dupliquer les métadonnées critiques) savoir comment répartir les diverses copies sur des disques effectivement physiquement différents est difficile lorsque cette information est masquée par l'agrégation LVM ou MD.
Et aussi : btrfs (comme ZFS en fait) peut (si monté en conséquence) s'assurer de l'intégrité des données à l'aide de checksums (pour le moment, uniquement des crc32). S'il a un accès direct aux disques physiques (direct = pas déjà agrégé / masqué par une couche raid sous-jacente), il peux décider de chercher une copie en bon état du bloc concerné, puis la dupliquer de nouveau sur le disque où la copie était mauvaise (mais dans un autre bloc), voir prendre des décisions pertinentes au sujet des blocs contigus ou du disque lui-même. Un gestionnaire RAID classique, lui, ne pouvant pas accéder aux informations du fs, se contentera de mettre le disque entier offline dès qu'il détectera le problème. C'est une problématique importante, justement, pour les SSD (dont certains blocs peuvent "vieillir" sans que l'ensemble du périphérique soit à jetter), et en fait, avec les gros disques modernes (le risque d'une panne globale du disque est aussi grand qu'auparavant, mais le risque d'avoir un ou deux blocs défectueux augmente au fur et à mesure que les disques grossissent en capacité).
Ou encore : sur un système RAID classique (logiciel avec mdadm ou lvm, ou matériel), la couche RAID permet d'avoir une seule taille de stripe, définie à la construction de l'agrégat. Ce choix n'est pas optimal pour tout les cas, même lorsque le système de fichier est proprement aligné sur les stripes (par ex. avec l'option "stride" d'ext3/ext4) : les lectures/écritures séquentielles de gros fichiers bénéficient de larges stripes, tandis que les petites écritures (métadonnées, par ex.) bénéficient de petites stripes (sans quoi, les écritures successives seront mal réparties sur les divers disques physiques de l'array). Or le système de fichier dispose de ses informations (taille probable des lectures/écritures) ; il est donc en mesure de prendre de très bonnes décisions en allouant des stripes de taille dynamique selon ses besoins spécifiques.
Je signale au passage que sur ce point (la fameuse "rampant layering violation") cette dépêche est fausse.
Je suppose qu'elle a été écrite à partir de l'article de patrick_g sur Wikipédia, qui se base sur des informations juste mais datées. En pratique, Chris Mason avait l'intention d'essayer de faire un fs qui communique et délègue aux couches pertinentes (d'où le texte dans l'article de WP), mais s'est aperçu ensuite qu'il devait gérer l'essentiel dans le système de fichiers lui-même pour pouvoir exploiter de façon optimale les périphériques multiples (cf. plus haut), les snapshots, etc.
En somme, l'intention de départ était bien, effectivement, de ne pas "violer" les divers "block layers" du noyau, mais ce qui s'est réellement passé c'est que la mentalité des développeurs Linux a globalement évolué sur ce point, et que ce type de "violations" est désormais considéré comme légitime (dans une certaine mesure). Le paradigme a simplement changé, les développeurs Linux ne sont pas obtus.
[^] # Re: Reiserfs
Posté par herodiade . En réponse à la dépêche Btrfs intègre le noyau Linux dès la prochaine version 2.6.29. Évalué à 10.
Oui, et de loin franchement.
Ses fonctionnalités sont déjà largement en avance par rapport à celles de reiserfs (et reprennent comme tu le signale les bonnes propriétés de celui-ci).
Le plus important (à mes yeux, concernant un système de fichier, et en comparaison avec reiserfs) est qu'il promet d'être très activement maintenu, suscitant l'intérêt vif et la participation de développeurs critiques chez IBM, Red Hat, SUSE, Oracle, Intel. Cette diversité est prometteuse, car elle signifie que bientôt chacune de ces sociétés sera capable de gérer les bugs rencontrés par ses clients, donc en mesure de proposer et supporter officiellement ce système de fichiers, de l'affiner pour ses workloads spécifiques, etc. Par contraste, reiserfs est désormais en mode "maintenance faible" chez SUSE et Mandriva, son développeur principal ne participe plus, et il n'est tout simplement pas supporté par Red Hat (autrement dit : peu de chances d'améliorations fonctionelles, désormais, à la différence de ext4, XFS et btrfs).
Une fonctionnalité bluffante pas décrite dans la dépêche, et pas faisable avec les outils actuels (LVM) : btrfs permet de faire des snapshots d'un répertoire quelconque du système de fichier (par ex. juste le /etc). D'autre part, il n'est pas nécessaire de réserver de l'espace disque dès le départ pour pouvoir faire ses snapshots (comme avec LVM). Ce sont de petits détails, mais il y en a beaucoup comme ça, et ils chacun peu, je pense, changer la vie des sysadmins :).
Pour répondre à la question de Michel plus haut :
> Par contre comment se débrouille Btrfs par rapport à la "concurrence" sur SSD ?
Pour le moment btrfs ne fait pas grand chose de spécifique pour les SSD. En pratique : la routine de recherche permettant de trouver de l'espace libre et utilisable parmi les extents alloués dispose d'un raccourcis/court-circuit dans le cas du SSD.
Mais il est prévu d'essayer de tirer le meilleur partis, de façon spécifique, des SSD, c'est d'ailleurs pour ça qu'une option de montage spécifique "ssd" est déjà intégrée.
XFS (depuis peu, et de façon encore expérimentale) et btrfs intègrent des fonctionnalités de gestion des périphériques multiples (normalement dévolues aux couches MD et LVM du noyau) précisément pour se permettre ce genre d'optimisations : en connaissant précisément la couche physique (le matériel sous-jacent), ils pourront décider au mieux de l'agencement des données. Par exemple, dans un aggrégat de disques durs et de SSD : placer les métadonnées (nécessitant beaucoup d'accès aléatoires) sur le SSD et les données dont l'accès est plus séquentiel sur disque dur, ou encore (et parce que, pour des raisons de fiabilité, btrfs permet de dupliquer les métadonnées critiques) savoir comment répartir les diverses copies sur des disques effectivement physiquement différents est difficile lorsque cette information est masquée par l'agrégation LVM ou MD.
Et aussi : btrfs (comme ZFS en fait) peut (si monté en conséquence) s'assurer de l'intégrité des données à l'aide de checksums (pour le moment, uniquement des crc32). S'il a un accès direct aux disques physiques (direct = pas déjà agrégé / masqué par une couche raid sous-jacente), il peux décider de chercher une copie en bon état du bloc concerné, puis la dupliquer de nouveau sur le disque où la copie était mauvaise (mais dans un autre bloc), voir prendre des décisions pertinentes au sujet des blocs contigus ou du disque lui-même. Un gestionnaire RAID classique, lui, ne pouvant pas accéder aux informations du fs, se contentera de mettre le disque entier offline dès qu'il détectera le problème. C'est une problématique importante, justement, pour les SSD (dont certains blocs peuvent "vieillir" sans que l'ensemble du périphérique soit à jetter), et en fait, avec les gros disques modernes (le risque d'une panne globale du disque est aussi grand qu'auparavant, mais le risque d'avoir un ou deux blocs défectueux augmente au fur et à mesure que les disques grossissent en capacité).
Ou encore : sur un système RAID classique (logiciel avec mdadm ou lvm, ou matériel), la couche RAID permet d'avoir une seule taille de stripe, définie à la construction de l'agrégat. Ce choix n'est pas optimal pour tout les cas, même lorsque le système de fichier est proprement aligné sur les stripes (par ex. avec l'option "stride" d'ext3/ext4) : les lectures/écritures séquentielles de gros fichiers bénéficient de larges stripes, tandis que les petites écritures (métadonnées, par ex.) bénéficient de petites stripes (sans quoi, les écritures successives seront mal réparties sur les divers disques physiques de l'array). Or le système de fichier dispose de ses informations (taille probable des lectures/écritures) ; il est donc en mesure de prendre de très bonnes décisions en allouant des stripes de taille dynamique selon ses besoins spécifiques.
Je signale au passage que sur ce point (la fameuse "rampant layering violation") cette dépêche est fausse.
Je suppose qu'elle a été écrite à partir de l'article de patrick_g sur Wikipédia, qui se base sur des informations juste mais datées. En pratique, Chris Mason avait l'intention d'essayer de faire un fs qui communique et délègue aux couches pertinentes (d'où le texte dans l'article de WP), mais s'est aperçu ensuite qu'il devait gérer l'essentiel dans le système de fichiers lui-même pour pouvoir exploiter de façon optimale les périphériques multiples (cf. plus haut), les snapshots, etc.
En somme, l'intention de départ était bien, effectivement, de ne pas "violer" les divers "block layers" du noyau, mais ce qui s'est réellement passé c'est que la mentalité des développeurs Linux a globalement évolué sur ce point, et que ce type de "violations" est désormais considéré comme légitime (dans une certaine mesure). Le paradigme a simplement changé, les développeurs Linux ne sont pas obtus.
Voyez cette paire de réponse de Christophe Hellwig (développeur de XFS) et Chris Mason (développeur de btrfs) à Andrew Morton qui s'interrogeait récemment sur cette question de "layering violation" :
http://thread.gmane.org/gmane.comp.file-systems.btrfs/1601/f(...)
http://article.gmane.org/gmane.comp.file-systems.btrfs/1764