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
- Les nouveautés de DragonFly BSD 2.10 (395 clics)
- Télécharger DragonFly BSD (75 clics)
- [DLFP] Sortie de DragonFly BSD 2.6 et entretien avec Matt Dillon (147 clics)
- [DLFP] Sortie de DragonFly BSD 2.8 (83 clics)
# section Libellule BSD
Posté par Thomas Debesse (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
[^] # Re: section Libellule BSD
Posté par Bruno Michel (site web personnel) . Évalué à 6.
Pour proposer une section, il suffit de créer une demande dans le suivi avec le nom de la catégorie et une icône sous licence libre.
J'en profite pour signaler que nous recherchons une icône pour la section « Distribution ».
[^] # Re: section Libellule BSD
Posté par Gniarf . Évalué à 7.
bah au hasard
[^] # Re: section Libellule BSD
Posté par Julien . Évalué à -1.
Pourquoi c'est drôle ?
(non, «rhhaaaaaa, 'culer un mouton» n'est pas une réponse valide !)
[^] # Re: section Libellule BSD
Posté par psychoslave__ (site web personnel) . Évalué à 6.
Elles ne sont pas libre… C'est même écrit sur la page, et le pourquoi c'est quand même intégré à wikipédia.
[^] # Re: section Libellule BSD
Posté par Anonyme . Évalué à 4.
Ou encore :
- http://i69.servimg.com/u/f69/11/59/96/51/pez_au10.jpg
[^] # Re: section Libellule BSD
Posté par navaati . Évalué à 2.
Pourquoi pas le logo du poisson d'avril, là, Canterbury ?
# Système de fichiers et déduplication
Posté par Quzqo . É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 patrick_g (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 Quzqo . É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 pasBill pasGates . É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 Quzqo . É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 Albert_ . É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 Albert_ . É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 lasher . É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 Albert_ . É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 pasBill pasGates . É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 Kerro . Évalué à 5.
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.
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 Frédéric Perrin (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 Kerro . É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 zebra3 . É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 Quzqo . É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 Kerro . É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 pasBill pasGates . É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 Frédéric Perrin (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 barmic . É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 barmic . É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 pasBill pasGates . É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 Psychofox (Mastodon) . Évalué à 4.
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.
[^] # Re: Système de fichiers et déduplication
Posté par pasBill pasGates . Évalué à -2.
Les problemes potentiels avec j'y connais pas grand-chose, j'y ai jamais touche a part qu'en tant qu'utilisateur. Pour moi ca marchait.
[^] # Re: Système de fichiers et déduplication
Posté par Joris Dedieu (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 Psychofox (Mastodon) . Évalué à 5.
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.
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.
[^] # Re: Système de fichiers et déduplication
Posté par geb . Évalué à 4.
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 sifu . É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 claudex . É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 zebra3 . É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 Joris Dedieu (site web personnel) . Évalué à 4.
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 Tobu . Évalué à 1.
Venant de quelqu'un qui connait bien le RCU de Linux, je trouve cette affirmation surprenante.
[^] # Re: MPLOCK, BKL, même combat!
Posté par patrick_g (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.