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.
Aller plus loin
- DragonFlyBSD (15 clics)
- Les nouveautés de la version 2.6 (2 clics)
- Les objectifs techniques de DragonFlyBSD (8 clics)
# Full disclosure
Posté par patrick_g (site web personnel) . Évalué à 10.
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 goom . Évalué à 6.
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 Etienne Bagnoud (site web personnel) . Évalué à 4.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Full disclosure
Posté par bubar🦥 (Mastodon) . Évalué à 4.
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 Ghis . Évalué à 3.
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 bubar🦥 (Mastodon) . Évalué à 2.
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 snt . Évalué à 5.
>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 patrick_g (site web personnel) . Évalué à 2.
# Matt Dillon et son homonyme
Posté par KamelPanic . Évalué à -2.
Je suis déçu quand j'ai compris que ce n'était pas lui. Ça aurait été beau si ça avait été vrai.
[^] # Re: Matt Dillon et son homonyme
Posté par Amine "nh2" Brikci-Nigassa (site web personnel) . Évalué à 1.
GNU's Not Unix / LINUX Is Not Unix Xernel
[^] # Re: Matt Dillon et son homonyme
Posté par Frédéric Perrin (site web personnel) . Évalué à 0.
# Boule cornue
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 6.
[^] # Re: Boule cornue
Posté par patrick_g (site web personnel) . Évalué à 2.
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 Ghis . Évalué à 6.
# buffer cache -> cache de tampons
Posté par meushi . Évalué à 1.
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.
[^] # Re: buffer cache -> cache de tampons
Posté par patrick_g (site web personnel) . Évalué à 2.
Merci.
[^] # Re: buffer cache -> cache de tampons
Posté par zebra3 . Évalué à 6.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: buffer cache -> cache de tampons
Posté par kowalsky . Évalué à 10.
# Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -2.
Ce commentaire a été supprimé par l’équipe de modération.
# 2.6.1
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 4.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.