Sortie de DragonFly BSD 2.6 et entretien avec Matt Dillon

Posté par (page perso) . Modéré par baud123.
Tags :
40
6
avr.
2010
FreeBSD
Le projet DragonFly BSD est le petit poucet des systèmes d'exploitations de la famille BSD. Dans l'ombre de ses grands frères FreeBSD, OpenBSD et NetBSD, le projet initié par le développeur Matt Dillon cherche à se différencier par des choix techniques originaux.

La version 2.6 de DragonFly BSD vient d'être annoncée sur le site officiel et je vous propose une petite liste des nouveautés ainsi qu'un court entretien avec Matt Dillon qui a aimablement accepté de répondre à quelques questions. DragonFlyBSD

Le projet DragonFlyBSD est issu à l'origine d'une divergence technique, en 2003, entre l'équipe de FreeBSD et le développeur Matt Dillon. Alors que FreeBSD, pour répondre au défi des processeurs à plusieurs cœurs, allait prendre le difficile chemin des verrous à grain fin, Matt pensait qu'il fallait s'orienter dans une autre direction. Il a choisi de se baser sur la série éprouvée des FreeBSD 4.x pour la faire évoluer, selon ses choix à lui.

La principale différence avec FreeBSD - et Linux par la même occasion - c'est que la technique des verrous à grain fin, jugée trop complexe par Matt, n'est pas utilisée dans DragonFlyBSD.
À la place, c'est le système LWKT (pour Light Weight Kernel Threads) qui est utilisé. Il utilise un ordonnanceur par CPU (les processus sont donc compartimentés dans leur CPU et ils ne peuvent migrer qu'exceptionnellement avec un inter-processor interrupt (IPI)). Les mutex de FreeBSD sont remplacés par des sortes de jetons logiciels (serialized tokens) qui garantissent à un ensemble de threads qu'il n'y aura pas de conflit.

Une autre originalité de DragonFlyBSD est son système de fichiers réparti HAMMER dont la page de présentation explique les caractéristiques (contrôles d'intégrité, pas besoin de fsck, snapshots instantanés etc).

Le but final de DragonFlyBSD, pas encore atteint, est d'obtenir un système à image unique pour les clusters (un seul OS réparti sur plusieurs machines) au lieu d'un cluster traditionnel (plusieurs OS pour plusieurs machines).

Nouveautés

Après la version 2.4 en septembre dernier, c'est maintenant la version 2.6 de DragonFlyBSD qui est disponible.
Voici une courte liste des nouveautés. À noter que plusieurs nouveautés proviennent d'autres BSD, ce qui montre qu'en dépit du fork initial la « pollinisation croisée » fonctionne toujours et que les relations entre les équipes de développement sont bonnes.

  • La nouvelle fonction de swapcache pour les disques flash SSD permet un haut niveau de performances. On peut ainsi se servir d'un SSD pour cacher les données d'un système de fichier présent sur un disque traditionnel. Il faut compter environ 1 Go de SSD pour cacher 2 million d'inodes et DragonFlyBSD gère jusqu'à 512 Go de swap par périphérique en mode 64 bits. Matt Dillon décrit ses tests dans ce post sur la liste de diffusion.
  • Le code du système de fichiers temporaire en mémoire vive tmpfs a été importé de NetBSD par Naoya Sugioka. Contrairement à l'ancien système MFS, il ne nécessite pas de dupliquer les données.
  • Le système de fichiers HAMMER propose maintenant une fonction d'enregistrement de tous les changements (REDO log) qui permet d'améliorer les performances de fsync sans dégrader les fonctions de récupération rapide de HAMMER.
  • Les snapshots du système de fichiers HAMMER qui allaient auparavant dans /snapshots vont maintenant, comme l'indique la page de man, dans /var/hammer.
  • La couche de compatibilité Linux (Linuxulator) est mise à jour. Elle permet maintenant de faire fonctionner Java ou Flash.
  • L'infrastructure de watchdog, qui sert à redémarrer en cas de blocage permanent, a été importée depuis OpenBSD.
  • Le code ACPI et d'opencrypto ont, eux, été importés depuis FreeBSD.
  • Les performances des entrées/sorties non séquentielles ont été significativement améliorées.
  • L'accéléromètre des portables de type Thinkpad est désormais géré par le pilote aps(4).
  • Les processeurs de type Geode LX sont pris en charge et le pilote glxsb(4) permet de profiter des fonctions intégrées de cryptographie.
  • La gestion de l'architecture x86_64, ajout plus récent que le x86 qui était au début la seule architecture prise en charge, s'améliore dans cette nouvelle version.
  • Mise à jour des programmes externes (GCC 4.4.2; OpenSSH 5.3p1; Sendmail 8.14.4; Bind 9.5.2-P3; Binutils 2.20 etc).

Pour avoir une idée de quelques fonctions qui seront sans doute introduites dans les versions futures de DragonFlyBSD, on peut consulter la page du Google Summer of Code 2010 qui liste les projets retenus.

Entretien

À l'occasion de la sortie de DragonFlyBSD 2.6, j'ai envoyé quelques questions au leader du projet, Matt Dillon et il a bien voulu y répondre pour les lecteurs de LinuxFr.

patrick_g : DragonFlyBSD est moins connu que Free/Net/OpenBSD. Combien de codeurs ou testeurs font partie de l'équipe ?

Matt Dillon : Nous avons environ 12 codeurs sérieux et environ 50 personnes au total. Je dirais que nous avons quelques centaines d'utilisateurs... ce ne sont pas des gros chiffres. La plupart des nouveaux utilisateurs sont attirés par le système de fichier HAMMER.

patrick_g : Vous avez forké FreeBSD à la suite de désaccords techniques. Est-ce-que vous continuez à penser que les choix de FreeBSD étaient mauvais ?

Matt Dillon : Oui. Je crois que DragonFlyBSD a été capable d'atteindre une meilleure stabilité au fil du temps et qu'il a été amélioré.

patrick_g : Pourquoi le modèle de sérialisation des tokens est meilleur que celui des mutex à grains fins ?

Matt Dillon : Les différences vont plus loin que ça. Par rapport aux autres, le modèle de sérialisation des tokens a un double avantage :
1) ne pas subir les deadlocks, puisqu'ils sont automatiquement déverrouillés quand un thread bloque explicitement et verrouillés à nouveau ensuite.
2) permettre les appels aux sous-systèmes qui n'ont pas la connaissance de quels tokens sont actuellement détenus. Comme les tokens sont suivis par l'ordonnanceur, ce dernier peut efficacement déterminer quels sont les threads exécutables qui peuvent acquérir tous leurs verrous et s'exécuter.

Nous utilisons trois types de verrous. Les tokens sont principalement utilisés pour le scan à longue durée des listes comme les scans au mount. Les verrous de type lockmgr sont utilisés pour les verrous qui doivent être tenus au travers des conditions de blocage. Enfin les spinlocks sont utilisés pour les accès exclusifs de courte durée.

L'autre différence majeure par rapport aux autre modèles est le fait que nous utilisons une localisation des données par processeur pour de nombreux sous-systèmes. Cela permet de les coder de façon aisée et sans verrous.

patrick_g : les buts techniques de DragonFlyBSD sont très impressionnants, mais la partie la plus connue est HAMMER. Comment tient-il la comparaison avec les autres systèmes de fichiers ?

Matt Dillon : la comparaison lui est très favorable. Le scan des répertoires est un peu plus lent qu'il pourrait l'être (quelque part entre ext et reiser, mais pas aussi mauvais que reiser). Avec les récentes améliorations sur REDO/fsync, les performances de fsync sont maintenant extrêmement bonnes ; et, avec la nouvelle gestion de swapcache, qui est capable de cacher plus de 64 millions d'inodes sur un SSD, la performance de recherche de fichiers est très bonne.
Les performances de lecture/écriture de fichiers sont également très bonnes.

Je ne suis pas dans le business qui consiste à faire des comparaisons de performances mais je note que HAMMER dispose de fonctions, comme la récupération instantanée, l'historique à grain fin ou la prise d'empreintes (snapshotting) automatique, que la plupart des autres systèmes de fichiers n'ont tout simplement pas, ou pas avec le niveau d'intégration de HAMMER.
L'historique à grain fin a un petit impact sur les performances et tend à dégrader plus spécialement les benchmarks que les vrais chiffres en production, parce que la maintenance se déroule sur une durée de 24 heures au lieu de se faire instantanément.

La prise d'empreinte (snapshotting) est incroyablement puissante. Comme elle est automatique, vous pouvez compter sur le fait que vous avez au moins les 60 derniers jours (la durée peut évidemment être changée) sous forme de snapshots. Il est trivial d'accéder à ces snapshots (un simple cd ) si vous avez besoin de récupérer quelque chose ou pour faire une comparaison, ou pour tout autre raison.
Le mirroring en flux non mis en queue est aussi très puissant.

patrick_g : Pourquoi les autres BSD n'ont pas importé HAMMER dans leurs dépôts ?

Matt Dillon : C'est à eux de décider s'ils veulent le faire ou pas. De façon générale, les interactions du cache de tampon sont difficiles à porter.

patrick_g : Selon vous est-ce que DragonFlyBSD est encore loin de son but mythique d'un cluster avec une image système unique ?

Matt Dillon : C'est difficile à dire mais je pense qu'il nous reste environ deux ans de boulot. J'avais dit ça aussi, il y a deux ans. Le but continue d'être repoussé car nous choisissons d'améliorer les choses qui fonctionnent déjà, comme HAMMER.

patrick_g : Merci beaucoup Matt d'avoir répondu à mes questions.
  • # Full disclosure

    Posté par (page perso) . Évalué à 10.

    Comme Matt m'a complètement largué dans ses réponses techniques et que j'ai du faire une traduction à l'aveuglette de son interview je me permet de coller ci-dessous l'original. Cela permettra aux gens calés de corriger mes faux-sens et, peut-être, d'expliquer de quoi il retourne aux pauvres peóns que nous sommes.

    Q: DragonFlyBSD is less known than Free/Net/OpenBSD. How many developpers/testers are part of the team ?

    We have about 12 serious coders and about 50 people total. I'd say we have a few hundred users... not huge numbers. Most new users are attracted by the HAMMER filesystem.

    Q: You forked FreeBSD due to technical disagreements. Do you still think the FreeBSD choices were wrong ?

    Yes. I believe the DragonFly has been able to achieve better stability over time as it has been improved.

    Q: Why the serializing tokens model is better than the fine-grained mutex model ?

    There are more model differences then that. The serializing tokens have the two-fold advantage of being (1) deadlock-free because they are automatically unlocked when a thread explicitly blocks and relocked on resume, and (2) allow subsystem calls which do not have to have any knowledge of which tokens might already be held. Because tokens are tracked by the scheduler the scheduler itself can efficiently determine which runnable threads can actually acquire all their locks and run, verses other models.

    We use three types of locks. The tokens are primarily used for long-duration list scans such as mountlist scans. Lockmgr locks are used for locks which must be held across blocking conditions. And spinlocks are used for short-duration-only exclusive access.

    The other major model difference is that we use per-cpu data localization for numerous subsystems which allowed them to be coded in a straightforward manner without locks.

    Q: The technical goals of DragonFlyBSD are very impressive but the most known part is HAMMER. How does it compare to the other modern file systems ?

    It compares very well. Directory scans a bit slower than they could be (somewhere inbetween ext and reiser, but not as bad as reiser).
    With the recent REDO/fsync enhancements our fsync performance is now extremely good and with the new swapcache support capable of caching 64+ million inodes on a SSD the file lookup performance is extremely good.
    File read/write performance is very good.

    I'm not in the business of doing specific performance comparisons but I will note that HAMMER has features, such as instant recovery, fine-grained history, and automatic snapshotting. Most other filesystems just don't have these features or do not have them integrated anywhere near as well as they exist in HAMMER.

    The fine-grained history impacts performance a little and tends to impact benchmarks more than it does production operation because maintainance occurs on a 24-hour clock instead of instantly.

    The snapshotting is incredibly powerful and since it is automatic you can just assume that you have the last 60 days worth of snapshots available (the default retention can be changed of course) and trivially CD into them on the live system if you need to recover something or do a comparison or whatever.
    The non-queued streaming mirroring is also incredibly powerful.

    Q: Why the others BSD didn't import HAMMMER in their trunks ?

    It's up to them whether they want to or not. Generally speaking the buffer cache interactions are difficult to port.

    Q: According to you how far is DragonFlyBSD of the mythical SSI clustering goal ?

    It's hard to say but I think still at least 2 years away. I said this 2 years ago too. The goal keeps on getting pushed back in favor of improving things we already have working, such as HAMMER.
    • [^] # Re: Full disclosure

      Posté par (page perso) . Évalué à 6.

      heu ... si Matt t'a complètement largué dans ses réponses techniques, je doute pouvoir t'aider plus dans la traduction :D

      En tout cas merci pour ce coup de projecteur sur DragonFlyBSD que je ne testerai pas de toute façon.

      Il est toujours étonnant de voir la diversité des OS quand on prend la peine de creuser un peu le sujet et mettre ça en regard avec le non diversité des OS dans les circuits traditionnels de distribution.
    • [^] # Re: Full disclosure

      Posté par (page perso) . Évalué à 4.

      J'utiliserais plutôt "instantanée" au lieu d'"empreinte" pour snapshot. Les snapshot étant des états du système de fichier à un moment donné, exactement comme une photo.

      "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

    • [^] # Re: Full disclosure

      Posté par . Évalué à 4.

      Merci beaucoup pour cette dépêche, très instructive.
      Je découvre totalement Hammer, que je ne connaissais ni d'eve ni d'adam \o/ Je "connaissais" vaguement le choix des serialized tokens et de faire tourner de manière cloisonnés des process sur des cpu, avec un ordonnanceur par cpu (peut être pour avoir un peun suivi les débuts de df-bsd au travers d'articles?), mais je n'avais jamais entendu parler de hammer \o/.

      On notera (ou on corrigera -merci d'avance-) que cela semble aussi paradoxalement ne pas aller que vers du cluster, mais également vers un fonctionnement où le "noyau" initial n'est plus qu'un hyperviseur, et d'autres "noyaux" tournent au dessus. Non ?

      Qu'en est il de l'aspect "bloat" du noyau de df-bsd ? Est ce que ces choix initiaux, concernant l'ordonnancement et la gestion par cpu, vont/peuvent conduirent vers un éclatement du bloat pour laisser la place à des micro-noyaux spécialisés ? Merci pour d'éventuels éclairages.

      /me imagine un futur lointain potentiel, dans un délire à peine voilé, un "noyau" graphique tournant sur le gpu.
      • [^] # Re: Full disclosure

        Posté par . Évalué à 3.

        Dépêche qui fait plaisir à lire, merci.
        Cela dis je reste un peut sur ma faim concernant cet OS, je me demande aussi (et entre autre):
        - En gros, que manque t'il encore à l'OS pour pouvoir commencer à tourner en tant qu'OS SSI sur un cluster ?
        - Des Industriels s'impliquent t'ils dans le projet (par exemple SGI qui fait actuellement des cluster SSI qui tournent sous Linux) ?
      • [^] # Re: Full disclosure

        Posté par . Évalué à 2.

        Un embryon de pistes ici :
        http://fr.wikipedia.org/wiki/Noyau_de_syst%C3%A8me_d%27explo(...)

        Où (on/j') apprends que df-bsd est déjà un noyau hybride.

        (Et où je rends compte ne pas avoir employé le bon vocabulaire pour micro-noyau et hyperviseur, où j'ai désigné une fonction et non une architecture. Il s'agissait donc plus de l'idée d'un noyau hybride qui continuerai de s'enrichir et en même temps ferai évoluer les modules vers plus "d'autonomie et de distribution" de ceux-ci)
  • # .

    Posté par . Évalué à 5.

    >La nouvelle fonction de swapcache pour les disques flash SSD
    >permet un haut niveau de performances. On peut ainsi se servir d'un
    >SSD pour cacher les données d'un système de fichier présent sur un
    >disque traditionnel. Il faut compter environ 1 Go de SSD pour cacher 2
    >million d'inodes et DragonFlyBSD gère jusqu'à 512 Go de swap par
    >périphérique en mode 64 bits. Matt Dillon décrit ses tests dans ce
    >post sur la liste de diffusion.

    On peut ainsi se servir d'un SSD pour cacher *les méta-données* et les données d'un système de fichier présent sur un disque traditionnel. Il faut compter environ 1 Go de SSD pour cacher 2 millions d'inodes (méta données).
    • [^] # Re: .

      Posté par (page perso) . Évalué à 2.

      yep tu a raison, les inodes concernent les métadonnées. Merci de la correction.
  • # Matt Dillon et son homonyme

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

    Je ne suis pas très au fait de ceux qui bossent sur DragonFly mais en lisant le titre j'ai tout de suite pensé à l'acteur.
    Je suis déçu quand j'ai compris que ce n'était pas lui. Ça aurait été beau si ça avait été vrai.
  • # Boule cornue

    Posté par (page perso) . Évalué à 6.

    Le petit logo qui illustre l'article, connu affectueusement sous le surnom de « boule de geisha », est celui de FreeBSD, pas de DF ! Les amis de la libellule ne vont pas être contents...
    • [^] # Re: Boule cornue

      Posté par (page perso) . Évalué à 2.

      Ben oui mais y'a pas de thème DragonFlyBSD sélectionnable quand on propose une dépêche.
      J'ai juste fait comme pour les news précédentes...mais c'est vrai qu'un thème DF-BSD ce serait mieux.
      • [^] # Re: Boule cornue

        Posté par . Évalué à 6.

        Soit il va falloir un thème pour chaque BSD (Free, net, open, dragonfly...). Soit un pour les BSD en général.
  • # buffer cache -> cache de tampons

    Posté par . Évalué à 1.

    la traduction de ''buffer cache'' serait plutot ''cache de tampons'' (mais on utilise aussi le terme anglais dans les cours francophones).

    Il s'agit comme son nom l'indique d'une cache de buffer qui se situe dans le noyau et qui sert entre autre a diminuer le nombre d'acces au disque afin de maximiser les perfs.
  • # Hammer locked ?

    Posté par . Évalué à 0.

    Toujours épatant de suivre la progression de DragonFlyBSD.

    Pour la petite histoire, je suis ravi de voir que Hammer est en phase de finition (stabilisé ?). Je commençais à m'inquiéter pour le système de stockage réparti de Zino côté référentiel de confiance Tera, ne voyant pas d'alternative crédible ;o)

    Sinon, la discussion sur les 3 niveaux de verrous est un peu môle. On aurait bien vu un développement un peu plus couillu sur le détail des conditions de blocage, mais bon, je fais la fine bouche, et puis au fond, pas mieux :-)

    // deadly embraced... euh Joke inside.

    Merci Patrick-g.
    • [^] # Re: Hammer locked ?

      Posté par . Évalué à -2.

      Aïe aïe...
      "patrick_g", pardon.
      L'est pas au point mon générateur automatique, ça doit être dans les paramètres du "awk" où sur le moteur de règles. Bon sang, j'ai pourtant bien précisé "Do NOT alter names" ...in order to be well pertinented :-)
  • # 2.6.1

    Posté par (page perso) . Évalué à 4.

    On peut noter qu'une version corrective 2.6.1 est juste sortie dans la foulée. Par contre, j'ai du mal à voir ce qu'elle corrige par rapport à la 2.6, et j'ai la flemme de parcourir le CVS...

Suivre le flux des commentaires

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