Journal Stratis 1.1.0

Posté par .
20
15
oct.
2019

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 . Évalué à 2 (+1/-0).

    La démarche me semble proche des containers LXC/docker, j'espère que le projet connaîtra le même succès.

    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 . Évalué à 4 (+3/-0).

      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.

  • # Quel est le but de Stratis ?

    Posté par . Évalué à 6 (+5/-0). Dernière modification le 15/10/19 à 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 (page perso) . Évalué à 5 (+3/-0).

      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 . Évalué à 1 (+1/-0).

        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 . Évalué à 4 (+3/-0).

          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.

    • [^] # Re: Quel est le but de Stratis ?

      Posté par . Évalué à 5 (+4/-0).

      Est-ce que ça sert à masquer la complexité d'utiliser LVM/mdadm en ayant un frontend plus sexy ?

      Si j'ai bien compris c'est à peu prêt ça.

      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.

      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).

      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 ?

      Ce n'est clairement pas ce que montre des projets comme docker ou lxc.

      • [^] # Re: Quel est le but de Stratis ?

        Posté par . Évalué à 4 (+3/-0).

        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…

        • [^] # Re: Quel est le but de Stratis ?

          Posté par . Évalué à 3 (+2/-0).

          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.

          • [^] # Re: Quel est le but de Stratis ?

            Posté par (page perso) . Évalué à -1 (+0/-3).

            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.

            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 . Évalué à 1 (+0/-0).

              Tu pourrais lire jusqu'au bout avant de sauter sur le bouton répondre ?

              • [^] # Re: Quel est le but de Stratis ?

                Posté par (page perso) . Évalué à 3 (+2/-1). Dernière modification le 16/10/19 à 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 . Évalué à 1 (+0/-0).

            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.

  • # btrfs

    Posté par . Évalué à 6 (+4/-0).

    (n'est-ce pas btrfs ?…)

    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 . Évalué à 3 (+2/-0). Dernière modification le 15/10/19 à 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 . Évalué à 4 (+2/-0).

        ça pourrait avoir une bonne qualité rapidement […]

        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).

        XFS sur LVM

        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 (page perso) . Évalué à 2 (+0/-0).

          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 (page perso) . Évalué à 3 (+1/-0). Dernière modification le 15/10/19 à 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 . Évalué à 1 (+0/-0).

              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 (page perso) . Évalué à 4 (+3/-1).

                si l'on compare btrfs, celui-ci n’était qu'en "Technology preview"

                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 :

                [système de fichier : xfs/ext4/btrfs]
                 |
                [gestion de volume : lvm]
                 |
                [chiffrement : luks]
                 |
                [cache en écriture : bcache]
                 |
                [raid : mdadm]
                 |
                [disques physique]
                

                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 (page perso) . Évalué à 6 (+3/-0). Dernière modification le 15/10/19 à 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 (page perso) . Évalué à 4 (+2/-0).

                    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 . Évalué à 2 (+0/-0).

                      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.

                      Exemple de l'argument donné plus haut contre btrfs.

                  • [^] # Re: btrfs

                    Posté par (page perso) . Évalué à 3 (+1/-0).

                    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 . Évalué à 3 (+2/-0).

              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 . Évalué à 5 (+4/-0).

      maintenant que c'est le cas

      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.

      • [^] # Re: btrfs

        Posté par . Évalué à 5 (+4/-0). Dernière modification le 15/10/19 à 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 (page perso) . Évalué à 3 (+1/-0). Dernière modification le 15/10/19 à 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 . Évalué à 2 (+1/-0).

            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 . Évalué à 2 (+0/-0).

              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 . Évalué à 3 (+2/-0). Dernière modification le 15/10/19 à 17:25.

                Je ne savais pas moi non plus et j'attends impatiemment sa disponibilité dans le kernel.

                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é.

                Au fait, ZFS est-il toujours un glouton en mémoire vive ?

                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 (page perso) . Évalué à 4 (+1/-0).

                  C'est la déduplication de fichiers qui se goinfre de RAM et c'est désactivable.

                  Ce n'est pas activé par défaut.

                  • [^] # Re: btrfs

                    Posté par (page perso) . Évalué à 4 (+1/-0).

                    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 . Évalué à 2 (+1/-1).

              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 . Évalué à 2 (+0/-0).

                La licence est la CDDL, est libre. Oracle n'a pas de levier pour t'emmerder avec.

                • [^] # Re: btrfs

                  Posté par (page perso) . Évalué à 3 (+1/-0).

                  La licence est la CDDL, est libre. Oracle n'a pas de levier pour t'emmerder avec.

                  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 (page perso) . Évalué à 2 (+0/-0).

                    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 . Évalué à 2 (+0/-0).

                      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 . Évalué à 2 (+0/-0).

                    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 (page perso) . Évalué à 2 (+0/-0).

                      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.

                      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 . Évalué à 2 (+0/-0).

                        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 (page perso) . Évalué à 3 (+1/-0).

                          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.

                          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 . Évalué à 2 (+0/-0).

                            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 (page perso) . Évalué à 7 (+5/-0).

            il est de plus en plus probable que Btrfs finisse comme ReiserFS j'ai l'impression

            Pourquoi penses tu que les concepteurs de Btrfs vont finir en prison?

      • [^] # Re: btrfs

        Posté par . Évalué à 4 (+2/-0). Dernière modification le 15/10/19 à 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 . Évalué à 4 (+3/-0).

          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 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.

          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.

          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'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.

          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.

          • [^] # Re: btrfs

            Posté par . Évalué à 6 (+4/-0). Dernière modification le 15/10/19 à 17:40.

            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.

            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.

            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.

            J'ai cité Mint mais aussi et surtout l'inclusion dans le kernel.

            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 ».

            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 . Évalué à 4 (+2/-0).

            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.

            J'aurais pu aussi citer Suse, Synology ou Facebook.

          • [^] # Re: btrfs

            Posté par . Évalué à 1 (+0/-0). Dernière modification le 16/10/19 à 10:41.

            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 ».

            À 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 ?

            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.

            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 (page perso) . Évalué à 3 (+2/-0). Dernière modification le 15/10/19 à 17:12.

          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.

          Beuh ?!

          apt-get install spl-dkms spl zfs-dkms zfsutils-linux
          C'est pas si compliqué.

          • [^] # Re: btrfs

            Posté par . Évalué à 3 (+1/-0).

            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 . Évalué à 4 (+2/-0).

              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 . Évalué à 3 (+2/-0).

                La killer feature de zfs ce sont l'envoi et la réception de snapshots, y compris incrémentaux. 
                

                et chiffrés !

            • [^] # Re: btrfs

              Posté par (page perso) . Évalué à 1 (+0/-0).

              [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)

              [/]

              • [^] # Re: btrfs

                Posté par . Évalué à 2 (+1/-0). Dernière modification le 16/10/19 à 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 . Évalué à 2 (+1/-0). Dernière modification le 16/10/19 à 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 . Évalué à 3 (+1/-0).

            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 (page perso) . Évalué à 4 (+1/-0).

          w, x et y problématiques se réduisent maintenant raid5/6

          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 . Évalué à 1 (+0/-0).

          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 (page perso) . Évalué à 2 (+0/-0).

            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 . Évalué à 2 (+0/-0).

            Il y a/aura du checksum sur les data et metadata (avec correction auto en cas de raid 1/…) ?

        • [^] # Re: btrfs

          Posté par (page perso) . Évalué à 2 (+0/-0).

          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.

          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 . Évalué à 3 (+1/-0). Dernière modification le 16/10/19 à 14:41.

            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.

            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 (page perso) . Évalué à 4 (+2/-0). Dernière modification le 17/10/19 à 17:43.

              si on lui ajoutait les moyens mis sur stratis.

              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 . Évalué à 2 (+0/-0). Dernière modification le 16/10/19 à 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 . Évalué à 2 (+1/-0).

      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.

      • [^] # Re: limitation d'un schéma en couches vs FS intégré ?

        Posté par . Évalué à 2 (+0/-0). Dernière modification le 16/10/19 à 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)

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.