Sortie de DragonFly BSD 2.10

Posté par  (site web personnel) . Modéré par patrick_g. Licence CC By‑SA.
61
27
avr.
2011
FreeBSD

Le projet DragonFly BSD est issu, à l’origine, d’un désaccord technique entre les développeurs de FreeBSD et Matt Dillon, un des membres de la core team. Matt a choisi de continuer à se baser sur le socle de FreeBSD 4.x et d’évoluer à partir de là avec des solutions techniques originales.
Qu’il s’agisse du système des threads LWKT (pour Light Weight Kernel Threads) ou de son système de fichiers réparti HAMMER, nous avons là un système d’exploitation assez particulier et qui mérite le coup d’œil.

Le 26 avril est sortie la version stable 2.10 de DragonFly BSD, et il semble bien qu’il s’agisse d’un bon cru. Les performances augmentent significativement (voir ce comparatif sysbench entre les trois dernières versions) et le support matériel s’élargit, même si les architectures de processeur supportées restent limitées aux classiques i386 et amd64.

Nul doute que DragonFly BSD mérite d’avoir son logo dans la liste des sections LinuxFr, au lieu de devoir utiliser celui du cousin FreeBSD !

Traduction de la liste des principales nouveautés :

Support matériel

Cette version supporte bien plus de types de machines et de systèmes multiprocesseur que les précédentes. Cela est dû aux améliorations de l’ACPI et au support des interruptions APIC et ACPI.

Déduplication et HAMMER

Le système de fichiers HAMMER peut maintenant dédupliquer les volumes durant la nuit en mode batch et sans interrompre les opérations courantes. La commande « hammer dedup-simulate » peut être utilisée pour estimer les gains de place engendrés par une déduplication des données existantes.

Packet Filter (pf)

Pf a été mis à jour à partir de la version présente dans OpenBSD 4.4. La version qui était incorporée jusqu’à présent dans DragonFly était basée sur OpenBSD 4.2.

Mise à jour de la chaîne de compilation

DragonFly utilise maintenant GCC 4.4 comme compilateur par défaut. C’est le premier système BSD à franchir ce pas.

Nouvelle fonction d’agrégation de liens

Le système de pontage réseau (bridging) a été complètement réécrit. Des interfaces réseau d’une même machine peuvent être associées de façon transparente sous une seule adresse MAC, afin de réaliser une agrégation de lien (bonding). Ceci permet de multiplier la bande passante par le nombre de liens, mais aussi d’assurer une redondance en cas d’indisponibilité d’un lien.

Performances multiprocesseur

Le MPLOCK (le verrou principal qui, lorsqu’il est tenu, assure qu’un seul processeur travaille en espace noyau) a été supprimé de tous les recoins du système, à l’exception de la gestion de la mémoire virtuelle. DragonFly est l’un des premiers systèmes non académiques à utiliser un mécanisme de synchronisation qui n’est pas une [exclusion mutuelle] bloquante.

Performances générales

DragonFly offre des performances accrues par rapport aux versions précédentes, spécialement pour les machines qui utilisent AHCI ou qui implémentent swapcache(8).

Support ACPI

Mise à jour majeure du support ACPI dans le système et en particulier du routage des interruptions (interrupt routing).

Dans la liste complète des nouveautés, on peut également noter que les systèmes x86-64 peuvent désormais fonctionner avec 512 Gio de RAM et 63 processeurs. L’ordonnanceur a été amélioré et la bibliothèque libcrypt supporte le format SHA-256/512 (d’ailleurs, le chiffrement par défaut des mots de passe se fait maintenant en SHA-256). Enfin, le système de fichiers HAMMER, l’un des joyaux de DragonFly BSD, a reçu de nombreux correctifs pour améliorer ses performances et sa stabilité.

Plusieurs propositions du projet DragonFly BSD ont été acceptées dans le programme Google Summer of Code 2011 et nous pouvons donc espérer voir bientôt arriver PUFFS, le système de fichiers en espace utilisateur (équivalent de FUSE), des améliorations dans la couche de virtualisation, ou encore des disques en miroir (mirroring) dans le gestionnaire de volumes.

Aller plus loin

  • # section Libellule BSD

    Posté par  (site web personnel) . Évalué à 7.

    en attendant la section, on peut déjà mettre un tag dragonflybsd ;-)

    ce commentaire est sous licence cc by 4 et précédentes

  • # Système de fichiers et déduplication

    Posté par  . Évalué à 3.

    Toujours à l'affut d'informations sur les distributions *BSD, merci pour cet article :)

    C'est bien la première fois que je vois fait mention de déduplication hors univers de sauvegarde (Backup & Restore) et je me demandais si d'autres FS/gestionnaire de volumes avaient dans leurs plans d'intégrer cette fonctionnalité, ou si certains le faisaient et que je suis passé à côté de l'information.
    Si l'espace de stockage n'est aujourd'hui plus un problème (pour 8To en raid5, le ticket d'entrée est aujourd'hui de l'ordre de 500 €), augmenter les volumes n'est pas sans poser de problèmes, notamment pour le temps de reconstruction en cas de panne.

    Si l'un de vous dispose de plus d'information sur les FS, leurs performances & avantages/inconvénients respectifs ainsi que sur leurs évolutions prévues/possibles notamment côté déduplication, je l'en remercie par avance (un truc didactique pour les nuls par exemple).

    Réflexion en passant : quand on voit les fonctionnalités offertes par ces FS (HAMMER, Ext3, Ext4, Xfs, ZFS, Reiserfs, ...) en comparaison des équivalents Fat32, Ntfs, HFS_Plus... on s'interroge sur la capacité d'innovation.

    • [^] # Re: Système de fichiers et déduplication

      Posté par  (site web personnel) . Évalué à 5.

      Je ne sais pas comparer ZFS et btrfs mais je sais juste que la déduplication arrive dans btrfs. Les patchs datent de janvier : http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg07720.html

      A noter qu'il s'agit d'une déduplication offline (parce que l'auteur, Josef Bacik, pense que la dedup online ne sert strictement à rien).

      • [^] # Re: Système de fichiers et déduplication

        Posté par  . Évalué à 3.

        Dommage de ne considérer que la déduplication offline.
        Même si les arguments de l'auteur semblent cohérents (overhead notamment), du fait que cela s'adresse (en général) à de gros volumes, j'imagine mal que les données ciblées ne soient pas tout ou partie accessibles 24/24 7/7.

    • [^] # Re: Système de fichiers et déduplication

      Posté par  . Évalué à 3.

      Réflexion en passant : quand on voit les fonctionnalités offertes par ces FS (HAMMER, Ext3, Ext4, Xfs, ZFS, Reiserfs, ...) en comparaison des équivalents Fat32, Ntfs, HFS_Plus... on s'interroge sur la capacité d'innovation.

      Marrant que tu dises ca, parce que ce systeme de deduplication il est dans NTFS depuis longtemps... (ca s'appelle single instance storage chez nous)

      • [^] # Re: Système de fichiers et déduplication

        Posté par  . Évalué à 6.

        Si je me fie au Single-instance_storage, cette fonctionnalité est disponible sans l'être pour certaines versions mais pas d'autres, sous le coup de moult brevets bien entendu. Bref, c'est accessible au commun des mortels... ou pas.
        Mais j'en conviens, cela existe. Il ne s'agit cependant pas de déduplication puisque c'est au niveau d'un fichier et non de blocks.
        Après lecture rapide, je vois cela comme une version "bas de gamme" de la déduplication.

        Mais j'avoue que j'entame à peine mon exploration du domaine.
        Merci pour l'info quoiqu'il en soit.

        • [^] # Re: Système de fichiers et déduplication

          Posté par  . Évalué à 4.

          Si c'est au niveau des fichiers c'est un truc qui existait bien 99. Les problemes de places sur les backups (tape) avaient pousse pas mal de monde a faire des scripts pour eviter d'avoir deux fois le meme fichier et a utiliser les link (d'ou le fait que la fonction tar les conserves...).

          Voir des patents datant de 99 sur ce genre de truc c'est une abberation totale. Non seulement il n'y a aucune innovation tellement l'idee est trivial et en plus il y a forcement du prior art. Apres que certaines versions de NTFS (amusant de savoir que NTFS est en fait un nom generique pour toutes une famille de systeme de fichier) ait implemente cela en premier au niveau systeme de fichier c'est possible mais il y a pas a casser 3 pattes a un canard.

        • [^] # Re: Système de fichiers et déduplication

          Posté par  . Évalué à 4.

          En meme temps si l'on en croit cette page sur les systemes de fichiers cela ne doit pas etre la meme chose ce que cite le gars de microsoft et ce qui est appelle data duplication car c'est bien mis que c'est pas supporte par NTFS. Alors maintenant il est possible que le collegue qui doit maintenir wikipedia a jour ait oublie de faire cela...

          Et de tout de facon NTFS a juste repris le systeme de fichier de OpenVMS et ajouter ou ameliorer quelques trucs, pas tres etonnant vu qu'ils ont le meme pere donc si cela se trouve ce dont il parle etait deja dans Files-11...

          • [^] # Re: Système de fichiers et déduplication

            Posté par  . Évalué à 2.

            Admettons que VMS ait eu un système de ce genre. Ça change quoi au fait qu'il (pBpG) a raison ? :) Que NTFS propose quelque chose depuis longtemps, et dont on ne parle que maintenant dans les systèmes Unix/Linux¹, je ne vois pas en quoi c'est un problème.

            ¹ En supposant qu'il s'agisse bien de la même fonctionnalité.

            • [^] # Re: Système de fichiers et déduplication

              Posté par  . Évalué à 0.

              Le probleme ce sont les brevets et que VMS ait eu cela ou pas peu etre tres important.

              De tout de facon il semblerait que ce n'est pas la meme chose ce dont il est question ici et le truc de NTFS.

        • [^] # Re: Système de fichiers et déduplication

          Posté par  . Évalué à 1.

          Après lecture rapide, je vois cela comme une version "bas de gamme" de la déduplication.

          Bas de gamme ? Vraiment ?

          Tu as souvent des fichiers differents avec des blocs identiques ? Rappelles toi que pour que ce soit le cas, il faut que les donnees commencent a un offset specifique (multiple de taille de cluster) et soient les memes sur toute la taille du cluster.

          Je vais dire sans prendre trop de risques que dans l'enorme majorite des cas, c'est vrai lorsque il s'agit de fichiers identiques, et rarement dans d'autres cas.

          • [^] # Re: Système de fichiers et déduplication

            Posté par  . Évalué à 5.

            Tu as souvent des fichiers differents avec des blocs identiques ?

            Moi oui, mais ce n'est pas le cas général. J'ai pas mal de machines virtuelles dont les disques contiennent un paquets de secteurs identiques (dont beaucoup de secteurs à zéro, maintenus à zéro chaque semaine par un script, bien pratique pour la compression des sauvegardes).
            C'est également le cas pour beaucoup de systèmes de sauvegarde. Bien que la déduplication puisse être gérée directement par le logiciel de sauvegarde.

            Rappelles toi que pour que ce soit le cas, il faut que les donnees commencent a un offset specifique (multiple de taille de cluster) et soient les memes sur toute la taille du cluster.

            C'est bien le problème de la plupart des systèmes de déduplication.

            • [^] # Re: Système de fichiers et déduplication

              Posté par  (site web personnel) . Évalué à 3.

              Le cas des blocs à l'intérieur d'un fichier qui ne contiennent que des zéros est déjà un cas particulier pour beaucoup de FS, et il n'y a pas besoin de sortir l'artillerie lourde de déduplication.

              • [^] # Re: Système de fichiers et déduplication

                Posté par  . Évalué à 2.

                Ca m'étonnerai beaucoup que tu puisses me montrer un FS qui vérifie si un fichier contient de zones à zéro. Il y a bien les systèmes de fichiers compressés, mais ça ne vérifie pas la présence de zones à zéro, mais la possibilité de compresser (le code ne contient nulle part une recherche de zone avec des zéros).
                Et attention, zéro != trou.

          • [^] # Re: Système de fichiers et déduplication

            Posté par  . Évalué à 3.

            Expliquez-moi ce dont vous avez besoin, je vous dirais comment vous en passer...

            Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

          • [^] # Re: Système de fichiers et déduplication

            Posté par  . Évalué à 2.

            Pour ce que j'en connais, j'ai plutôt envie de dire que cela peut (parfois) convenir à un l'usage d'un particulier chez qui il y a parfois/souvent plusieurs copie d'une même donnée.
            Dans un cadre professionnel, on peut espérer que l'organisation est plus rationnelle et que le véritable intérêt se situe au niveau de blocks.

            En pratique, je vois au moins plusieurs domaines pour lesquels des blocks identiques sont monnaie courante :
            * "Imagerie" (par exemple, données satellites ou capteurs plus généralement)
            * Sauvegarde
            * Virtualisation (comme évoqué par Kerro)
            * Haute disponibilité & réplication
            ...

            Par ailleurs, ce qui est réalisable au niveau fichier l'est logiquement au niveau block mais sans s'y limiter.
            Bref : déduplication block >> pseudo déduplication fichier

            Par ailleurs, associer le terme de déduplication à des fichiers revient à faire un équivalent de liens "hard", chose qui existe côté *nix depuis... pfffiou.

            • [^] # Re: Système de fichiers et déduplication

              Posté par  . Évalué à 2.

              Besoin très courant également: la messagerie.
              Il faut que ça fonctionne avec des blocs non alignés.
              Le cas typique est la boîte de 40 personnes, avec chaque message contenant le logo de l'entreprise. Et les indispensables fichier amusants (hum...) qui font quelques centaines de kilos dans le meilleur des cas, envoyés à la moitié de l'entreprise. Et qui reste des mois dans les corbeilles.

              Et aussi les PDF, les DOC, etc, qui sont des copies des uns et des autres. Avec à chaque fois le même logo, la même photo de la façade de l'entreprise, la même illustration d'une blonde souriante avec son casque téléphonique (je me demande si ça ne fait pas des vibrations dans tout le corps, car à chaque fois qu'il y a une photo d'une personne avec une casque téléphonique, c'est méga-sourire).
              Blocs non alignés également. Ca se voit bien avec les sauvegardes dédupliquées.

              • [^] # Re: Système de fichiers et déduplication

                Posté par  . Évalué à 0.

                Tout a fait, il y a plein de donnees dupliquees partout, c'est sur et certain.

                Mais dedupliquer cela alors que la donnee peut se situer n'importe ou est franchement a peu pres impossible a resoudre de maniere efficace (= qui prend pas trop de temps en terme d'analyse de donnees).

                Resultat, les seuls cas realistes sont :
                - par fichier
                - par blocs alignes

                Et mon petit doigt me dit que le 2eme a un cout assez eleve en regard du gain dans la plupart des cas (il y a toujours des exceptions)

                • [^] # Re: Système de fichiers et déduplication

                  Posté par  (site web personnel) . Évalué à 4.

                  Il suffit de faire le calcul. En dehors du texte (qui ne représentera pas une fraction significative de l'espace disque utilisé), les données binaires binaires compressées ressemblent à des données aléatoires (si ce n'est pas le cas, il faut changer de format pour stocker vos musiques ou vos photos...).

                  Le gain entre une déduplication par blocs ou par fichier se trouve parmi les blocs de données identiques, appartenant à des fichiers différents. On va donc considérer que deux blocs appartenant à deux fichiers différents n'ont pas de liens a priori entre eux. La probabilité de trouver une paire de blocs identiques se calcule bien.

                  Btrfs, ext4 et probablement beaucoup d'autres ont une taille de bloc qui est de 4kio. Cela fait 2^(8*4*2¹⁰) = 2^(2^15) blocs différents. D'après le paradoxe des anniversaires, il faut environ sqrt() de ce nombre pour avoir 50% de chances d'avoir une paire (une !) de blocs identiques. Cela fait 2^(2¹⁴) blocs. D'après Wolfram Alpha, ça fait 1,2×10⁴⁹³² (à comparer au nombre d'atomes dans l'univers, 10⁸⁵).

                  Ceci dit, on est parti sur une hypothèse de blocs complètement aléatoires (mais toujours sur des fichiers différents). Je vais faire une énorme concession, et considérer que l'espace auquel un bloc peut appartenir fait 2^(2¹¹). Il nous faut alors 2^(2¹⁰) = 2^1024 blocs = 1,8×10³⁰⁸ blocs. Nope, toujours aussi peu utile...

                  • [^] # Re: Système de fichiers et déduplication

                    Posté par  . Évalué à 2.

                    Je ne parle pas de déduplication de données mais le résultat est le même. Imaginons que ton utilitaire de copie utilise l'appel système sendfile() (ce n'est pas le cas du cp classique). Il deviendrais possible pour le système de fichier de faire du cow. Ça marche sur tout type de données et sans superflux.

                    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Système de fichiers et déduplication

        Posté par  . Évalué à 3.

        WinFS il sortiras un jour ?

        Si je ne me plante pas NTFS n'est pas 128bits et ne gère pas les snapshots, c'est ça ?
        Il a des optimisations pour les SSD ?

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: Système de fichiers et déduplication

          Posté par  . Évalué à 2.

          WinFS n'a jamais ete un systeme de fichier vraiment. C'etait une couche au dessus de NTFS. Si ca sortira un jour ? Bonne question, j'en sais rien.

          NTFS est 64bit mais quelque chose me dit qu'il se passera encore quelque temps avant que tu aies besoin d'un fichier de taille 2^64-1, et surtout que tu aies la capacite de stockage pour, et il gere les snapshots (je sais pas si il le fait de la meme maniere que ZFS par contre), ca s'appelle Shadow copies chez nous.

          Tu entends quoi par optimisations pour SSD ?

          • [^] # Re: Système de fichiers et déduplication

            Posté par  (Mastodon) . Évalué à 4.

            NTFS est 64bit mais quelque chose me dit qu'il se passera encore quelque temps avant que tu aies besoin d'un fichier de taille 2^64-1, et surtout que tu aies la capacite de stockage pour, et il gere les snapshots (je sais pas si il le fait de la meme maniere que ZFS par contre), ca s'appelle Shadow copies chez nous.

            Shadow copies, d'experience, ça semble marcher très mal. En tout cas c'est ce qui fait foirer aléatoirement pas mal de nos backups sur les serveurs windows.

            De même la seule fois où j'ai voulu l'utiliser (indirectement) sur un desktop, c'était avec le vmware converter et il m'a insulté pour me dire que le shadow copy foirait.

            À côté, un snap zfs c'est une commande, c'est instantané et je n'ai jamais vu un cas ou ça ne marchait pas.

            Jami: beabb2b063da0a2f0a2acaddcd9cc1421245d5de

    • [^] # Re: Système de fichiers et déduplication

      Posté par  (site web personnel) . Évalué à 4.

      zfs supporte la déduplication sous solaris et sous FreeBSD
      http://svnweb.freebsd.org/base?view=revision&revision=219089

    • [^] # Re: Système de fichiers et déduplication

      Posté par  (Mastodon) . Évalué à 5.

      C'est bien la première fois que je vois fait mention de déduplication hors univers de sauvegarde (Backup & Restore) et je me demandais si d'autres FS/gestionnaire de volumes avaient dans leurs plans d'intégrer cette fonctionnalité, ou si certains le faisaient et que je suis passé à côté de l'information.

      ZFS le supporte depuis quelques versions maintenant. Et c'est de la dedup online. Très pratique pour un système hébergeant des zones par exemple.

      Si l'un de vous dispose de plus d'information sur les FS, leurs performances & avantages/inconvénients respectifs ainsi que sur leurs évolutions prévues/possibles notamment côté déduplication, je l'en remercie par avance (un truc didactique pour les nuls par exemple).

      Je n'ai pas de tableau tout prêt, en tout cas il y'a une killer feature de hammerfs, les snapshots auto associés à l'outil "undo".

      Chez zfs il y'a aussi le time slider, une interface pour nautilus qui permet de naviguer à divers instants (via des snaps auto aussi). Je ne sais pas si ça a été porté pour les versions linux et freebsd de zfs.

      Jami: beabb2b063da0a2f0a2acaddcd9cc1421245d5de

    • [^] # Re: Système de fichiers et déduplication

      Posté par  . Évalué à 4.

      Si l'espace de stockage n'est aujourd'hui plus un problème (pour 8To en raid5, le ticket d'entrée est aujourd'hui de l'ordre de 500 €), augmenter les volumes n'est pas sans poser de problèmes, notamment pour le temps de reconstruction en cas de panne.

      La dé-duplication est aussi utile pour le cache.

      Typiquement, si tu utilises de la virtualisation par conteneur (lxc, openvz, vserver), c'est dommage de mettre 25x syslogd en cache. (Vserver intègre un hack à coup de liens physiques et d'attributs posix pour ça)

      Typiquement aussi, un hébergeur web. Combien tu penses avoir de copie identiques de wordpress-v-current.php ?

      Typiquement aussi, un fournisseur de mail, où les utilisateurs sont abonnés aux mêmes ML (de mémoire cyrus a un mécanisme interne pour ça) et vont donc pontiellement recevoir souvent les mêmes mails

      etc..

  • # Mais comment font-ils ?

    Posté par  . Évalué à 3.

    Ma question n'est pas un appel au troll.

    Je me demande toujours comment un OS comme celui-ci doit être considéré. C'est largement utilisable ou bien c'est un peu un OS de R&D ?

    On reproche souvent aux autres Linux et BSD d'avoir un support matériel (surtout récent) limité. J'ai du mal à voir comment un OS plus anonyme peut sérieusement ce positionner par rapport aux autres. DragonFly ne semblent pas spécialisée dans un domaine particulier.

    Forcément, les gars qui bossent dessus doivent être bons mais comment se faire une place au soleil par rapport aux autres ?

    Merci pour vos retours.

    • [^] # Re: Mais comment font-ils ?

      Posté par  . Évalué à 2.

      Déjà, tu peux très bien avoir un desktop, un serveur (et même un portable) qui fonctionne relativement bien sans avoir de support matériel poussé, il suffit de faire des concessions.

      « 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: Mais comment font-ils ?

        Posté par  . Évalué à 2.

        Justement, quel type de concessions ?

        Par exemple, si le support du WiFi est très limité à cause du support matériel, pas de point d'accès, etc.

        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

        • [^] # Re: Mais comment font-ils ?

          Posté par  (site web personnel) . Évalué à 4.

          Justement, quel type de concessions ?

          Il faut penser que c'est un OS principalement serveur. Il y aura plus de travail sur le support des cartes raid que des dungle dvb.

          Le support du materiel est relativement uniforme sur l'ensemble des *BSD. Il y a une façon d'écrire le code, un soucie de stabilité dans les appels systèmes, une tradition qui fait que le code est porté facilement (y compris vers d'autres OS qui n'ont rien a voir).

          DragonFlyBSD est plutot stable (je l'utilise en production sur des machines bien critiques et elles me foutent un paix royale). Par contre les devs veulent avancer vite sur certains points et ont des priorités bien claires. Tu peux donc avoir un truc annexe qui pète d'une version a l'autre sans prevenir (exemple http://bugs.dragonflybsd.org/issue1848 )

  • # MPLOCK, BKL, même combat!

    Posté par  . Évalué à 1.

    DragonFly est l’un des premiers systèmes non académiques à utiliser un mécanisme de synchronisation qui n’est pas une exclusion mutuelle (mutex) bloquante.

    Venant de quelqu'un qui connait bien le RCU de Linux, je trouve cette affirmation surprenante.

    • [^] # Re: MPLOCK, BKL, même combat!

      Posté par  (site web personnel) . Évalué à 3.

      C'est parce que tu as manqué la phrase en début de seconde partie de la dépêche : "Traduction de la liste des principales nouveautés :".

      Ce n'est donc que la traduction de l'annonce officielle se trouvant sur le site de DragonFlyBSD: "DragonFly is one of the few non-academic operating systems to use a primary sychronization mechanism that is not a blocking mutex".

      Ce n'est donc pas moi qui parle ;-)

Suivre le flux des commentaires

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