Le 3 octobre dernier est sorti la version 1.1.0 de stratis. Très bien me direz vous mais qu'est-ce que c'est ?
Stratis est un gestionnaire de volume pour linux qui se veut être une alternative aux fameux zfs/btrfs. Au lieux de chercher à tout faire, il réutilise autant que possible l'existant dans linux. Ainsi il réutilise device-mapper, LVM, multipath pour fournir un ensemble cohérent de fonctionnalités. L'objectif est d'avoir toute la gestion de volume (volume virtuel, snapshot,…) utilisable aussi vite que possible (n'est-ce pas btrfs ?…). La sortie de la version 1.0 en septembre de l'an dernier, 2 ans après le début du projet, semble montrer qu'ils ont réussi.
Pour la hype, stratis est implémenté en rust ^^
Pour le moment ça n'est pas équivalent en terme de fonctionnalité à un zfs.
Je suis loin d'être assez compétent pour véritablement comprendre/expliquer tout ce que fait stratis, mais peut être que la FAQ pourra répondre aux questions que vous vous posez ? Comme je n'ai vu passer de news à ce sujet, je me suis permis un p'tit journal.
La démarche me semble proche des containers LXC/docker, j'espère que le projet connaîtra le même succès.
Je place ce document sous licence CC0.
# DĂ©marche
Posté par damaki . Évalué à  2.
Dans quel sens ? Est-ce au sujet de la réutilisation et de l'aggrégation de fonctionnalités déjà existantes pour créer quelque chose de nouveau ?
[^] # Re: DĂ©marche
Posté par barmic 🦦 . Évalué à  4.
Oui le fait de partir du constat qu'il y a des briques déjà importantes dans le noyau mais qu'il faut quelque chose pour rendre l'ensemble utilisable par l'admin moyen.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Quel est le but de Stratis ?
Posté par damaki . Évalué à  6. Dernière modification le 15 octobre 2019 à 12:54.
J'ai beaucoup de mal Ă cerner Ă quoi sert vraiment ce projet.
Est-ce que ça sert à masquer la complexité d'utiliser LVM/mdadm en ayant un frontend plus sexy ?
Est-ce que ça sert plutôt à faciliter le développement d'UI façon QNAP et compagnie pour gérer un NAS ?
Autant, je vois tout de suite les problèmes potentiels, mais pas trop les gains pour l'instant. Je vois d'abord le fait de pousser XFS alors que la plupart des applis sous Linux sont plutôt testées juste pour fonctionner sous EXT4, le système de fichiers par défaut quasiment partout. Puis ensuite vient ce qui arrive avec toute surcouche, c'est à dire les fonctionnalités manquantes pour lesquelles il faut utiliser les vrais outils velus d'origine. Genre comment est-ce que je simule qu'un des lecteurs de mon pool vient de mourir et comment je remplace le disque ?
Je trouve ce projet très intriguant et ça me fait imaginer des fonctionnalités potentielles. Le premier truc qui me vienne à l'esprit est dm-integrity, hélas pas encore supporté directement dans LVM sans bricolage.
[^] # Re: Quel est le but de Stratis ?
Posté par Sytoka Modon (site web personnel) . Évalué à  5.
Moi je vois autour de moi que tous les gros volumes sont sous XFS… (ou ZFS) et qu'il y a très peu de soucis dessus. Je parle pas du / mais de partition au delà de 50To par exemple.
[^] # Re: Quel est le but de Stratis ?
Posté par jeancharlesc . Évalué à  1.
Effectivement, quel est l'apport de Stratis par rapport Ă ZFS par exemple? N'y a t-il pas un risque de dupliquer les efforts pour rien?
[^] # Re: Quel est le but de Stratis ?
Posté par barmic 🦦 . Évalué à  4.
Stratis permet justement de réutiliser ce qui existe déjà dans le noyau. De plus zfs n'est pas intégrable directement dans le noyau ce qui est problématique en terme de gestion de l'effort de développement.
Enfin de manière générale. Il faudrait établir si les développeurs de Stratis auraient travaillé ou non sur zfs et ça ne me semble pas être envisageable. RedHat n'ayant pas contribué à zfs.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Quel est le but de Stratis ?
Posté par barmic 🦦 . Évalué à  5.
Si j'ai bien compris c'est à peu prêt ça.
Chez RedHat c'est XFS depuis RHEL7 et de ce que j'ai vu les appli ayant le plus besoin de fs vérifient ext4 et xfs (à minima ils testent souvent zfs et btrfs aussi).
Ce n'est clairement pas ce que montre des projets comme docker ou lxc.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Quel est le but de Stratis ?
Posté par abriotde (site web personnel, Mastodon) . Évalué à  4.
Non ce que vous dites n'est qu'un des aspect. Le fondement c'est de se dire, revenons au concept de base d'UNIX : KISS. Autrement dis n'est t'il pas possible d'assembler des outils simples pour former un outils complexe et ainsi gagner en fiabilité/maintenabilité et autres avantages par rapport a un gros outils complexe.
L'inconvénient d'avoir de multiples outils qui permettent de faire un outils complexe à la main c'est qu'il faut maîtriser plein de fichiers de configurations différents, plein de démons indépendant… L'idée est donc de créer quelque chose de plus simple a comprendre, configurer et donc automatiser. Un peu comme un OS est le rassemblement d'un noyaux, d'une configuration, d'un gestionnaire de logiciels et de logiciels préinstallés.
La question qui se pose, est est-ce possible de faire aussi bien/efficace qu'un gros outils qui fait tout? Cette polémique se retrouve dans les noyaux monolitique vs micro-kernel, dans SystemD vs Init-V et bien d'autres cas…
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Quel est le but de Stratis ?
Posté par barmic 🦦 . Évalué à  3.
J'ai l'impression qu'il y a un autre aspect. Les développeurs du noyaux sont des gens extrêmement bons techniquement, mais ils n'envisagent pas ce qu'il font comme faisant parti d'un système d'exploitation complet. Leur objectif est juste d'avoir une fonctionnalité la plus efficace possible.
Si on regarde les cgroups, ils sont ajouté au noyau en 2007. Il aura fallu attendre 3 ans avec la fonctionnalité auto TTY et la vidéo qui allait avec pour montrer leurs efficacité puis systemd et docker pour en tirer pleinement parti.
Il faut des gens pour donner des cas d'utilisation à ce qui est fait dans le noyau. Et c'est tout à fait normal ça permet d'avoir un noyaux non opiniated et de laisser aux grecs toute la possibilité de créer leurs usages.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Quel est le but de Stratis ?
Posté par Firwen (site web personnel) . Évalué à  -1.
Et c'est trés bien comme ça, car c'est ça qui apporte de la diversité et une évolutivité permanente.
Si le développement kernel était fait "top-bottom", avec une vision d'ensemble consistante et des tools key in hands, tu aurais des features legacy de partout, impossible à enlever car utilisé en dependence à tous les niveaux.
Si j'avais envie de troller ( mais c'est pas Vendreid !), je dirai comme le Kernel Windows en fait.
[^] # Re: Quel est le but de Stratis ?
Posté par barmic 🦦 . Évalué à  1.
Tu pourrais lire jusqu'au bout avant de sauter sur le bouton répondre ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Quel est le but de Stratis ?
Posté par Firwen (site web personnel) . Évalué à  3. Dernière modification le 16 octobre 2019 à 10:38.
Non, ça m'aurait enlever toute possibilité de troller.
De Plus ça t'aurait également enlever la possibilité de répondre un commentaire de façon à moitié aigri par un commentaire complémentaire. Tout ceci aurait été largement dommageable.
[second degré je précise]
Mes excuses pour cette réponse un peu prompt de bon matin.
[^] # Re: Quel est le but de Stratis ?
Posté par abriotde (site web personnel, Mastodon) . Évalué à  1.
Cela va au delà , les fonctionnalité (cgroups et autres) ont été crées pour répondre à un besoin de sécurité, pour SELinux, les normes américaines entre autres. Mais il faut reconnaître que même si c'est utile, c'est extrêmement complexe à bien exploité.
Docker n'est en quelque sorte qu'un hack. Une utilisation détourné du système qui simplifie tout de manière génial. Ceci n'aurait sans doute pas été possible dans un produit bien conçus de A à Z, enfermé dans une boite noire. C'est la force de l'Open-Source l'agitation qui frémit autour.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
# btrfs
Posté par mahikeulbody . Évalué à  6.
btrfs a certes mis longtemps à devenir un système de fichiers mature mais maintenant que c'est le cas, quels seraient les avantages de Stratis que tu présentes comme un concurrent fonctionnel ?
[^] # Re: btrfs
Posté par damaki . Évalué à  3. Dernière modification le 15 octobre 2019 à 13:01.
Si j'ai bien compris le truc, c'est que comme ça n'invente rien et que ça ne fait qu'utiliser des fonctionnalités existantes (XFS sous Linux) et des outils existants (commandes ou APIs LVM, mdadm et compagnie), suffit de vérifier que ce sont les bonnes commandes lancées et c'est donc plus simple que de faire une non-reg complète sur un filesystem. Au final, ça reste du XFS sur LVM et donc ça pourrait avoir une bonne qualité rapidement et une adoption plus rapide.
[^] # Re: btrfs
Posté par mahikeulbody . Évalué à  4.
Cet argument, si on l'oppose à btrfs, ne tient pas vraiment puisque btrfs a déjà une bonne qualité (qui a certes pris beaucoup plus de temps à être obtenue que si on avait pu suivre un chemin de type Stratis au lieu de partir de zéro).
Les fonctionnalités ne sont donc pas tout à fait comparables puisque, sauf erreur de ma part, XFS ne permet pas les snapshots (il a en contrepartie d'autres qualités mais la comparaison des deux filesystems n'est pas le sujet ici).
[^] # Re: btrfs
Posté par Thomas Debesse (site web personnel) . Évalué à  2.
Clairement, si un hypothétique ext5 apportait les snapshots et autres copies sur écriture, je n’aurai aucun remord à mettre btrfs à la poubelle. C’est la seule chose pour laquelle j’utilise btrfs aujourd’hui, pour tout le reste je repose sur mdadm, lvm, etc.
C’est aussi pourquoi je suis assez circonspect à propos de Stratis : en choisissant XFS pour la partie FS, Stratis est fonctionnellement inférieur à ce que j’utilise déjà . Je ne dis pas non au fait de simplifier l’interface utilisateur, mais passer à Stratis serait fonctionnellement une régression pour moi.
damaki se demande si “Est-ce que ça sert plutôt à faciliter le développement d'UI façon QNAP et compagnie pour gérer un NAS ?” mais si ça simplifie le développement d’UI mais que ça ne propose pas les fonctionnalités déjà utilisées en production, ça ne pourrait simplifier que le développement d’UI que personne ne développe.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: btrfs
Posté par Thomas Debesse (site web personnel) . Évalué à  3. Dernière modification le 15 octobre 2019 à 21:46.
OK, je me réponds à moi-même, RedHat est en train d’implémenter la copie sur écriture dans XFS:
Tout ça sonne comme très intéressant pour le futur. D’ici à ce que ce soit disponible et fiable je continuerai de conseiller d’utiliser btrfs comme une brique essentielle de l’architecture du SI afin de mettre en œuvre dès maintenant les méthodes de travail rendues possibles par la copie sur écriture. Mais il sera possible de garder à l’idée que dans la décennie à venir certaines briques fonctionnelles pourraient être remplacées en conservant les mêmes méthodes de travail, typiquement en remplaçant btrfs par XFS tout en conservant l’architecture. Actuellement l’intérêt de btrfs est essentiellement de permettre dès aujourd’hui ces méthodes de travail sans avoir à attendre un temps incertain de stabilisation.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: btrfs
Posté par Crazy Diver . Évalué à  1.
En fait c’est déjà disponible dan RHEL8 (cf la release note)
Et Red Hat doit être relativement confiant si l'on compare btrfs, celui-ci n’était qu'en "Technology preview" de la RHEL 7.0 à la RHEL 7.4 et a été retiré via RHEL 7.5.
Dans le cas de Stratis Introduit en RHEL 8.0, il s'agit la aussi de Tech Preview.
Note: Chez Red Hat la Tech preview correspond à des briques non recommandées pour de la prod sur laquelle ils assurent quand même du support en best effort … traduction de la bêta sans l’appellation qui fait peur (cf: Technology preview)
[^] # Re: btrfs
Posté par Thomas Debesse (site web personnel) . Évalué à  4.
Il y a un problème de compréhension : btrfs fait plus qu’un système de fichier, de quelles briques de btrfs parle RedHat quand ils parlent de « technology preview » ?
Dans un schéma à la Stratis btrfs ne fait que système de fichier tandis que par exemple le raid est pris en charge par mdadm, donc le fait que par exemple le raid5 btrfs soit en technology preview en touche une sans faire bouger l’autre…
Actuellement on peut faire ça sous Linux :
L’idée de Stratis c’est de se dire « OK, btrfs a l’ambition de tout faire depuis le système de fichier jusqu’au matériel, raid inclus, mais à la place on préfère reléguer les opérations en dessous du système de fichier à des briques éprouvées (mdadm, lvm…) ». C’est dans son ambition à prendre en charge toutes ces couches que btrfs était en Technology Preview, mais btrfs pourrait être un composant Stratis.
C’est btrfs en tant que concurrent de Stratis qui était en « Technology Preview », alors que btrfs en tant que système de fichier uniquement n’est pas en concurrence avec Stratis et pourrait même en être une brique essentielle. Pour la couche système de fichier de Stratis RedHat pousse xfs pour ses propres raisons, certains s’étonnent qu’ils poussent xfs au lieu de ext4, mais ils auraient aussi pu pousser btrfs, reiserfs ou autre chose.
S’il y a des choses à améliorer dans la partie système de fichier de btrfs il serait aussi possible à RedHat d’investir du développement n’ayant pas d’autre intention que d’améliorer cette partie là , de la même manière qu’ils investissent du développement pour implémenter dans XFS des fonctionnalités. Ils ont certainement leur raison de privilégier le développement de nouvelles fonctionnalités expérimentales dans XFS plutôt que d’investir dans la stabilité de ces mêmes fonctionnalités qui ne sont plus expérimentales dans btrfs.
Ces choix sont forcément en partie politique et pas seulement technique. En effet, le fait que RedHat a choisi d’ajouter des fonctionnalité expérimentales dans xfs et non pas dans ext4 alors que ce dernier est le système historique de Linux montre que le choix de faire évoluer xfs et pas un autre système de fichier n’est pas seulement une question technique fondée sur le fait qu’xfs ou un autre système de fichier soit éprouvé ou non.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: btrfs
Posté par claudex . Évalué à  6. Dernière modification le 15 octobre 2019 à 23:12.
À ma connaissance, ils ont simplement plus de développeurs xfs qu'un autre système de fichier, ça explique pourquoi ils le priviégient (et vu qu'ils doivent assurer le support, il vaut mieux qu'ils aient des gens qui sachent répondre aux problèmes des clients).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: btrfs
Posté par Thomas Debesse (site web personnel) . Évalué à  4.
Merci, c’est le genre d’information importante que j’attendais ! Parce que oui, le choix de privilégier telle ou telle techno dépend d’autres facteurs que la simple techno elle-même : avoir une équipe formée et compétente sur l’une d’entre elle est un élément de décision très important.
En pratique je me dis que c’est peut-être aussi ce qui fait que tant de technos de virtualisations coexistent par exemple : des tas d’industries différentes ont développé des méthodes de travail avec chacune, ces industries ont de très bonnes raisons de privilégier la technologie qui est la mieux maîtrisée par leur équipe, on ne peut donc pas déduire de la seule information de ce choix que les autres technologies seraient intrinsèquement moins bonnes sur le plan technique, ou qu’elles seraient même à déconseiller.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: btrfs
Posté par mahikeulbody . Évalué à  2.
Exemple de l'argument donné plus haut contre btrfs.
[^] # Re: btrfs
Posté par Sytoka Modon (site web personnel) . Évalué à  3.
XFS est aussi très stable, très performant, gère des gros systèmes de fichier et la plupart des briques ont été ajoutés petit à petit. D'ailleurs, initialement, ils n'avaient pas prévu de pouvoir mettre tout cela puis, de mémoire, avec les extends, ils se sont rendus compte qu'au final, c'est possible de faire du cow sans coût énorme.
Je pense qu'il y a une bonne dynamique de développement communautaire sur XFS, mais en gardant des bases stables et très robustes. De mémoire, RH arrache par exemple les prises électriques de ses serveurs plusieurs fois, même au reboot, pour valider un système de fichier.
[^] # Re: btrfs
Posté par damaki . Évalué à  3.
Il manque encore les checksums, une de mes fonctionnalités préférées de btrfs et zfs. Mais vu que ça va bientôt arriver dans LVM, ça ne sera pas forcément utile dans XFS.
[^] # Re: btrfs
Posté par Sytoka Modon (site web personnel) . Évalué à  4.
La force de l'architecture en étage !
[^] # Re: btrfs
Posté par barmic 🦦 . Évalué à  5.
C'est le cas ? Je n'ai jamais vu mieux que « ça marche très bien tant que tu n'utilise w, x, y et bon faut être joueur pour utiliser z » par contre j'ai vu RedHat enlever toutes ses billes de btrfs.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: btrfs
Posté par damaki . Évalué à  5. Dernière modification le 15 octobre 2019 à 14:34.
Pareil. Mais j'ai le sentiment que c'est un problème de mauvaise doc et du manque de soin sur les outils fournis.
Jusqu'à récemment (2 ou 3 ans), les fonctionnalités de pool btrfs étaient connues pour être dangereuses et il était conseillé d'utiliser des RAID LVM ou mdadm à la place. btrfs-check en mode repair est déconseillé à l'usage si on regarde la doc. btrfs-balance est pas très clair. btrfs-scrub a une utilité claire malgré son mauvais nom, mais je ne comprends pas pourquoi on devrait le lancer une fois par mois si ça fait juste de la vérif des blocs.
Et la doc pour récupérer ses données en cas de pépin est pas terrible, pour déjà avoir eu des soucis lors du décès d'un serveur. J'ai rien perdu, hein, mais j'ai galéré pour trouver une méthode valide pour récupérer mes données.
Bref c'est un filesystem très complexe et faudrait un outillage et une doc au top pour que ça soit utilisable sur une vraie prod, je trouve. Après, j'imagine que si vous avez des maintainers de btrfs dans votre boîte ou un contrat de support, c'est probablement pas gênant.
[^] # Re: btrfs
Posté par Sytoka Modon (site web personnel) . Évalué à  3. Dernière modification le 15 octobre 2019 à 15:31.
Et comme ZFS est de plus en plus intégré… il est de plus en plus probable que Btrfs finisse comme ReiserFS j'ai l'impression, bien que sa conception soit plus récente et ait essayé d'éviter certaines chausse-trappes de ZFS.
[^] # Re: btrfs
Posté par damaki . Évalué à  2.
Je viens de découvrir que les incertitudes juridiques sur la licence de ZFS ont été levées. Je ne savais pas et ça me donne une soudaine envie de me ruer dessus.
[^] # Re: btrfs
Posté par mahikeulbody . Évalué à  2.
Je ne savais pas moi non plus et j'attends impatiemment sa disponibilité dans le kernel.
Au fait, ZFS est-il toujours un glouton en mémoire vive ?
[^] # Re: btrfs
Posté par damaki . Évalué à  3. Dernière modification le 15 octobre 2019 à 17:25.
Il ne sera pas disponible dans le kernel à cause des différences de licence. Cependant la licence ne gène pas l'inclusion dans une distro linux. Donc suffit de télécharger un paquet de votre distro favorite (zfs-dkms sur Debian) et le tour est joué.
C'est la déduplication de fichiers qui se goinfre de RAM et c'est désactivable. Même sans la déduplication, ça reste un chouette système de fichiers.
[^] # Re: btrfs
Posté par Kerro . Évalué à  4.
Ce n'est pas activé par défaut.
[^] # Re: btrfs
Posté par claudex . Évalué à  4.
Et heureusement, la consommation de RAM par la déduplication n'est pas bornée et s'il n'y a pas assez de RAM, le FS est illisible. Par contre, par défaut, ZFS utilise la RAM de manière assez agressive pour le cache.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: btrfs
Posté par Albert_ . Évalué à  2.
Euh le "leger" problème c'est que l'actuel proprio e zfs c'est Oracle est dans le genre je ne peux pas faire confiance je pense qu'ils sont au top de ma liste (c.f. l'histoire des API java).
Zfs c'est probablement genial mais c'est une bombe a retardement!
[^] # Re: btrfs
Posté par Psychofox (Mastodon) . Évalué à  2.
La licence est la CDDL, est libre. Oracle n'a pas de levier pour t'emmerder avec.
[^] # Re: btrfs
Posté par Firwen (site web personnel) . Évalué à  3.
La CDDL a une clause de non-agression concernant les brevets ?
Si ce n'est pas le cas, Oracle a peut-ĂŞtre une shit tonne de levier pour t'emmerder avec :
https://www.google.com/search?tbm=pts&q=ZFS%20oracle&*&cad=h
[^] # Re: btrfs
Posté par Sytoka Modon (site web personnel) . Évalué à  2.
Oracle a besoin de ZFS et Oracle a abandonné Solaris. Il est donc plus que probable qu'Oracle mettre à jour la licence de ZFS et la bascule sur la GPL. Enfin, c'est ce qu'il me semble le plus naturel s'ils ne veulent pas se couper l'herbe sous le pied (mais avec Oracle, tout est possible).
À noter que SGI avait donné de la même manière XFS au noyau il y a maintenant pas mal d'année ;-)
[^] # Re: btrfs
Posté par Psychofox (Mastodon) . Évalué à  2.
Le code de la variante openzfs tel qu'utilisé dans freebsd et linux a divergé énormément de la version de Oracle. Si Oracle changeait la licence de sa version (même pas sûr que ce soit possible s'ils avaient accepté des contributions sans close de transfert de copyright) ça n'affecterait pas openzfs et il faudrait demander à tous les contributeurs de openzfs d'accepter de changer la licence et backporter tous leurs patches.
Ça me parait autant improbable que titanesque.
[^] # Re: btrfs
Posté par Psychofox (Mastodon) . Évalué à  2.
La CDDL a une clause de licenciement sur l'utilisation des brevets.
Il y a juste deux mini clauses qui parlent de ne pas te protéger si un retrait, une modification ou l'association du code avec un autre type de code ou device pouvait changer la donne mais même avec ça je ne vois pas vraiment comment ils pourraient le défendre, et encore moins après tant d'années.
Du reste si Oracle devenait tout méchant ce serait ubuntu et les éventuels devs/projet qui le proposent qui seraient impactés. Pas toi l'utilisateur final.
[^] # Re: btrfs
Posté par Firwen (site web personnel) . Évalué à  2.
Ca je suis pas si sur. Aux grandes heures des menaces à coup de brevert par SCO et Microsoft, c'étaient les utilisateurs finaux ( professionels ) qui étaient visés, pas les développeurs.
Tu pourrais aisément imaginer une stratégie similaire par Oracle pour promouvoire "unbreakable Linux" face à Red Hat. Ça serait immensément stupide de mon point de vue, et contre productif… mais pas impossible.
[^] # Re: btrfs
Posté par Psychofox (Mastodon) . Évalué à  2.
Alors tu vas m'expliquer comme Oracle va savoir que toi, utilisateur final, tu utilises zfs sur ton NAS et avec quelles lois ils pourraient t'attaquer.
Les seuls réellement à risques ce sont les entreprises comme ubuntu, joyent, nexenta et dans une moindre mesure freenas qui fournissent et vendent des solutions basées sur zfs.
[^] # Re: btrfs
Posté par Firwen (site web personnel) . Évalué à  3.
Ce que tu fais toi sur ton NAS tout le monde s'en fout, incluant Oracle :)
Par contre, dans pour des négociations de licenses qui peuvent valoir plusieurs centaines de millions d'euros entre large entreprises, tout leverage est bon à prendre.
Au passage, Oracle a une réputation de requin en ce qui concerne ses licenses,sa propriété intellectuelle et l'aspect légal….
[^] # Re: btrfs
Posté par Psychofox (Mastodon) . Évalué à  2.
Oui ça je sais bien mais autant c'est difficile de leur cacher les bases oracle que tu fais tourner, autant à moins de faire tourner lesdites bases oracle sur zfs c'est quand même assez facile de garder ça pour toi.
Et ils n'ont aucun levier légal ni financier pour t'imposer de leur donner cette info.
[^] # Re: btrfs
Posté par Colin Pitrat (site web personnel) . Évalué à  7.
Pourquoi penses tu que les concepteurs de Btrfs vont finir en prison?
[^] # Re: btrfs
Posté par mahikeulbody . Évalué à  4. Dernière modification le 15 octobre 2019 à 16:52.
w, x et y problématiques se réduisent maintenant raid5/6. A ne pas confondre avec des fonctionnalités complémentaires qui ne sont pas encore toutes pleinement opérationnelles mais qui n'empêchent pas d'utiliser le FS de façon fiable.
Le fait que Redhat ne supporte plus btrfs ne signifie pas que le FS ne vaut rien, c'est un choix d'affectation de ressources. Tu aurais aussi pu voir que btrfs a intégré le kernel et que Mint le propose par défaut.
J'utilise au quotidien btrfs en raid1, y compris pour / avec Timeshift avant chaque mise à jour de ma Manjaro ce qui est d'un grand confort. Il est clair que si on veut un FS avec des snapshots, ZFS représente certainement un choix plus "robuste" à ce jour mais il n'est malheureusement pas disponible de façon simple dans Linux.
[^] # Re: btrfs
Posté par barmic 🦦 . Évalué à  4.
Le w c'est « récupérer les données en cas de problème c'est galère » et pas « envoyer mes snaphot sur mars ça marche pas bien parce qu'IPv6 est très peu présent là bas ». Le moins pire c'est le commentaire au dessus qui dit que c'est juste bien compliqué. Et les fonctionnalités complémentaires c'est l'intérêt de btrfs, si c'est pour faire la même chose qu'ext4 autant prendre ext4.
En terme de fiabilité, j'en suis désolé hein, mais j'ai une confiance bien plus grande envers RHEL que l'équipe de Mint. C'est un très mauvais message quand l'un des plus grands acteurs dit clairement « on préfère avoir une implémentation de ses fonctionnalités à coté via un nouveau projet plutôt que de continuer avec btrfs ».
J'ai utilisé pendant des années btrfs. Je n'ai rien contre lui, mais aujourd'hui, j'ai du mal à voir l'avenir. Entre son développement bien lent, l'arrivée de zfs et des trucs comme stratis.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: btrfs
Posté par mahikeulbody . Évalué à  6. Dernière modification le 15 octobre 2019 à 17:40.
Les fonctionnalités complémentaires auxquelles je faisais allusion sont des trucs comme les quotas, par exemple. Les snapshots fonctionnent et ça permet de faire des choses impossibles avec ext4.
J'ai cité Mint mais aussi et surtout l'inclusion dans le kernel.
Je ne savais pas que RHEL développait un nouveau FS avec du cow pour remplacer btrfs. J'en étais resté au fait qu'ils privilégiaient dorénavant XFS. Tu as un lien ?
[^] # Re: btrfs
Posté par mahikeulbody . Évalué à  4.
J'aurais pu aussi citer Suse, Synology ou Facebook.
[^] # Re: btrfs
Posté par Lawless . Évalué à  1. Dernière modification le 16 octobre 2019 à 10:41.
À noter que Linux Mint est un basée sur Ubuntu Linux, la principale différence étant le bureau, donc je doute que l'équipe Linux Mint travaille beaucoup sur le noyau et Btrfs. Le noyau doit être celui proposé par Ubuntu. Ubuntu préfère s'orienter vers ZFS en proposant des modules compilés de ZFS, malgré le fait que la FSF et la Software Freedom Conservancy affirment que c'est une violation de la GPL (GPL Violations Related to Combining ZFS and Linux).
Je pense que la comparaison de Red Hat doit se faire avec les quatre sociétés contribuant à Btrfs, à savoir Facebook, Fujitsu, SUSE et Oracle. C'est étrange qu'Oracle continue à contribuer à Btrfs alors qu'en parallèle Oracle continue de développer en version propriétaire Oracle ZFS (en opposition à OpenZFS) depuis dix ans. D'ailleurs on peut de demander ce qui se passerait si demain Oracle diffuse Oracle ZFS en GPL ? Est-ce que les contributeurs d'OpenZFS accepterait aussi de passer toutes leurs modifications apportés à OpenZFS depuis dix ans en double licence ? Est-ce que les deux projets pourraient être fusionnés et intégrés au noyau Linux ?
Le développement semble effectivement assez lent, voir l'historique des changements de Btrfs comparé à l'historique des changements OpenZFS
Cependant, mĂŞme si RHEL ne propose plus Btrfs, Fedora propose toujours Btrfs, tout comme Debian ou Ubuntu et bien entendu SUSE.
Le problème d'OpenZFS c'est qu'il ne sera jamais inclus au noyau, donc ça restera un projet en dehors du noyau avec tout cela implique (aucune revue des mainteneurs du noyau, régressions à cause du changement des développeurs du noyau qui n'ont rien à cirer d'OpenZFS) et aussi un problème de litige, Oracle pourrait très bien faire un procès à Canonical pour violation de licence, si demain Oracle juge que ZFS sous Ubuntu est préjudiciable à son activité. N'oubliez pas qu'Oracle est la société qui veut que les API soient soumises au droit d'auteur !
[^] # Re: btrfs
Posté par Loïs Taulelle ࿋ (site web personnel) . Évalué à  3. Dernière modification le 15 octobre 2019 à 17:12.
Beuh ?!
apt-get install spl-dkms spl zfs-dkms zfsutils-linux
Proverbe Alien : Sauvez la terre ? Mangez des humains !
[^] # Re: btrfs
Posté par mahikeulbody . Évalué à  3.
Il y a une différence entre simple et pas si compliqué. De plus, la fonctionnalité qui m'intéresse surtout dans btrfs (ou ZFS) ce sont les snapshots sur / (je les utilise comme des points de retour en cas de problème lors d'une mise à jour, pas comme une solution de backup). Or, configurer une Manjaro avec un / en ZFS, je ne sais pas faire simplement.
[^] # Re: btrfs
Posté par Psychofox (Mastodon) . Évalué à  4.
La killer feature de zfs ce sont l'envoi et la réception de snapshots, y compris incrémentaux.
C'est hyper pratique et léger pour faire du time-machine avec données déportées sur stockage distant.
[^] # Re: btrfs
Posté par ElVirolo (site web personnel) . Évalué à  3.
et chiffrés !
[^] # Re: btrfs
Posté par Loïs Taulelle ࿋ (site web personnel) . Évalué à  1.
[disclaimer, attention, un troll se cache dans cette réponse]
Ah ben oui, mais quand on utilise pas les bonnes distributions, aussi…
Un root chiffré en zfs, c'est possible depuis longtemps sur freebsd :o)
[/]
Proverbe Alien : Sauvez la terre ? Mangez des humains !
[^] # Re: btrfs
Posté par Lawless . Évalué à  2. Dernière modification le 16 octobre 2019 à 14:07.
D'ailleurs FreeBSD va migrer sur ZFS-on-Linux !
Quand à utiliser la bonne distribution, hormis le fait que FreeBSD n'est pas vraiment une distribution Linux, mon expérience personnelle de trois ans sur FreeBSD ne pas vraiment pas enthousiasmé sur ce système.
Le gros point noir, Ă mon humble avis, de FreeBSD sont les paquets qui sont juste des tarballs des sources en amont qui la plupart du temps marche, mais pas toujours.
Quand le système est installé, ça marche plutôt bien, mais les mises à jour peuvent vite tourner au cauchemar (pour moi en tout cas). Le système FreeBSD ressemble à une rolling release. Installer un paquet peut installer un dépendance qui va casser le fonctionnement d'un autre logiciel. Autre problème courant, j'ai un logiciel compilé en Port, le gestionnaire de paquets veut m'écraser le port compilé par la nouvelle version en paquet qui dépend d'un autre paquet que je veux mettre à jour ou installer.
Au début j'essayais de faire les mises à jour régulièrement, mais j'ai arrêté, une mise à jour des bibliothèques de Samba a fait planter Samba. J'ai voulu réinstaller Samba de zéro, je l'ai supprimé et là Samba 3 avait disparu du dépôt. J'ai dû migrer sur Samba 4 en urgence, en testant plusieurs versions avant d'en trouver un qui plantait pas. Depuis ce jour là j'ai arrêté les mises à jour.
Autre exemple, j'ai installé un module Perl, qui m'a installé une nouvelle version de Perl majeure (genre saut de Perl 5.25 à 5.26, donc fonctionnement en rolling release) tout fonctionnait, sauf qu'un jour j'ai redémarré le service SpamAssassin et qu'une expression rationnelle ne passait plus sur la nouvelle version de Perl. Ne voulant pas mettre à jour SpamAssassin (de peur de casser autre chose), j'ai corrigé l'expression rationnelle en éditant le fichier.
Parfois les dépendances ne fonctionnent pas, j'ai installé GraphicsMagick ou ImageMagick sur un système qui n'était pas à jour (vu que j'évitais de faire les mises à jour, n'ayant pas confiance au gestionnaire de paquets), cela ne fonctionnait pas car le gestionnaire de paquets avait omis de mettre à jour une dépendance que j'ai dû trouver et mettre à jour.
Pour finir quand le système est trop vieux, impossible d'installer un paquet. Exemple, j'ai un FreeBSD 11.1 et aucun paquet ne peut être installé. Cela change de Debian, j'ai récemment installé un paquet sur une Debian Sarge sortie en… 2005 !
Ensuite je ne suis pas un expert FreeBSD, peut-être qu'on peut éviter les problèmes cités ci-dessus. J'en garde l'impression qu'un serveur FreeBSD doit être mis à jour régulièrement pour fonctionner et je n'ai aucune confiance au système de paquets.
[^] # Re: btrfs
Posté par damaki . Évalué à  2. Dernière modification le 16 octobre 2019 à 20:44.
J'ai laissé tomber FreeBSD quand un bug est apparu dans le support de ma carte réseau 3Com. Quand tu pète des drivers réseau sur une nouvelle version d'OS, c'est pas très sérieux.
[^] # Re: btrfs
Posté par Psychofox (Mastodon) . Évalué à  3.
Bon pour pouvoir booter dessus sur un volume luks chiffré sur la dernière ubuntu j'ai quand même du préparer le pool à la main depuis un livecd, debootstraper la distro de base, préparer le ramdisk avec les options qui vont bien, installer grub à la popogne puis les paquets nécessaire pour avoir un bureau complet..
Donc pas hyper compliqué mais moins trivial que de passer par l'installeur de base.
[^] # Re: btrfs
Posté par claudex . Évalué à  4.
Il me semble qu'il y a toujours le cas oĂą tu te retrouve avec un fs en readonly quand tu n'as plus assez d'espace disque (donc, tu ne peux pas supprimer de fichier pour faire de la place) parce qu'il n'a plus de place pour Ă©crire les metadata.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: btrfs
Posté par Crazy Diver . Évalué à  1.
Il est à noter qu’en plus d’avoir retiré btrfs de RHEL7, Red Hat avance ses billes sur tous les fronts :
- en développant Stratis qui fait l’abstraction de LVM/XFS/Thin provisionning
- en ajoutant la COW dans XFS
- avec l’achat de Permabit pour VDO et l’intégrer a terme dans LVM (pour la dédupication/compression)
Ce qui via Stratis donne une alternative Ă ZFS et btrfs.
[^] # Re: btrfs
Posté par Thomas Debesse (site web personnel) . Évalué à  2.
Excellent ! J’ai hâte de voie ce que Stratis donnera quand tout cela sera stabilisé !
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: btrfs
Posté par mahikeulbody . Évalué à  2.
Il y a/aura du checksum sur les data et metadata (avec correction auto en cas de raid 1/…) ?
[^] # Re: btrfs
Posté par Sytoka Modon (site web personnel) . Évalué à  2.
La RHEL est une distribution orienté serveur avec support long terme. Si RH ne supporte plus Btrfs, c'est qu'ils considèrent qu'ils ne sont plus capables de fournir un vrai support sur 7 ans et que le système de fichier n'est pas assez robuste aux pannes. Donc ils ont estimé que trop de client auraient des soucis et qu'ils ne seront pas en état de les aider à récupérer des données.
En production, l'important est de ne pas perdre les données par une bête panne électrique ;-)
Cela ne signifie pas que Btrfs ne fonctionne pas dans un certain nombre d'autres cas.
[^] # Re: btrfs
Posté par mahikeulbody . Évalué à  3. Dernière modification le 16 octobre 2019 à 14:41.
btrfs résiste très bien à toutes sortes de pannes y compris la panne électrique (il y a même une remarque intéressante dans l'article ci-après à propos du raid5 qui pourtant n'est actuellement pas recommandé) :
https://unixsheikh.com/articles/battle-testing-data-integrity-verification-with-zfs-btrfs-and-mdadm-dm-integrity.html#btrfs-power-outage
Il est clair que btrfs n'a pas encore la maturité d'un ext4, xfs ou zfs mais il souffre d'un discrédit qui n'est plus justifié à ce jour (hormis sur des points clairement identifiés tel que le raid5). Selon ce que j'ai pu lire ici et là , beaucoup d'expériences négatives rapportées sont soit obsolètes aujourd'hui, soit relèvent de mauvaises manipulations post-incident (la faute à une documentation incomplète/perfectible ou mal suivie). J'ai clairement lu qu'on pouvait aussi se tirer très facilement une balle dans le pied avec zfs.
Facebook, Synology, etc… l'utilisent en production.
Le choix xfs+lvm+mdadm+… de RH est respectable mais n'est pas forcément révélateur de quoi que ce soit sur btrfs tant il existe de raisons non techniques ayant pu aboutir à ce choix plutôt que btrfs. On peut d'ailleurs se demander ce que deviendrait btrfs si on lui ajoutait les moyens mis sur stratis.
[^] # Re: btrfs
Posté par Sytoka Modon (site web personnel) . Évalué à  4. Dernière modification le 17 octobre 2019 à 17:43.
Justement, pour moi, il y a peu de moyen sur Stratis car l'objectif est d'avoir un système fonctionnel en partant de brique robuste et éprouvé. Donc on corrige ici ou là les implémentations "à la marge".
Le boulot fait dessus servira d'ailleurs à l'ensemble des systèmes de fichiers.
C'est une voie qui a été proposé dès le début mais il a été dit et redit par les partant de Btrfs qu'il n'y avait que la voie de ZFS qui s'occupe de tout qui était possible…
Perso, je ne suis pas mécontent qu'une voie plus traditionnel avec de la découpe par morceaux adaptable à tous les systèmes de fichier à terme soit déjà fonctionnelle.
# limitation d'un schéma en couches vs FS intégré ?
Posté par mahikeulbody . Évalué à  2. Dernière modification le 16 octobre 2019 à 09:11.
Il semble qu'il y ait un avantage à intégrer toutes les fonctions dans le FS vs. l'assemblage mdadm, lvm, fs.
Je ne retrouve malheureusement pas l'article (et je n'ai pas le temps de chercher davantage aujourd'hui) mais je crois me rappeler que cela concerne la correction d'erreur : mdadm + lvm + fs pourrait détecter une erreur grâce à un checksum mais ne saurait pas la corriger car la connaissance d'où se trouve la donnée redondée (en cas de raid1 par exemple) n'est pas dans la même couche.
[^] # Re: limitation d'un schéma en couches vs FS intégré ?
Posté par barmic 🦦 . Évalué à  2.
La question a était envisagé par l'équipe. Dans leur document de conception, ils expliquent que la couche 0 devrait être capable de le faire. Je ne sais pas comment ils prévoient de le faire, mais ils sont conscient de cette question.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: limitation d'un schéma en couches vs FS intégré ?
Posté par mahikeulbody . Évalué à  2. Dernière modification le 16 octobre 2019 à 10:35.
Je viens de jeter un œil sur le document que tu as linké. De ce que je comprends, ils vont pallier à ce problème en dupliquant les méta-données sur le même volume.
Mais cette solution ne peut s'appliquer aux données elles-mêmes (il est bien sûr hors de question de les dupliquer sur un même volume) => contrairement à btrfs ou zfs, stratis (ou toute autre solution basée sur des couches indépendantes) ne peut pas faire de correction d'erreurs sur les données même avec une configuration de type raid.
(sous réserve que j'aie bien compris, je ne suis pas un spécialiste des FS)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.