DragonFlyBSD 6.2 et 6.4

Posté par  (Mastodon) . Édité par orfenor, aplc et vmagnin. Modéré par Pierre Jarillon. Licence CC By‑SA.
Étiquettes :
30
10
fév.
2023
DragonFly BSD

La nouvelle version du système à la libellule est sortie fin décembre 2022.
DragonFlyBSD est un système UNIX libre dérivé de FreeBSD 4.8 en juin 2003 lorsque Matthew Dillon anticipait des problèmes sur le nouveau noyau multithread et multiprocesseurs de FreeBSD 5. Les différences significatives par rapport à FreeBSD sont l'implémentation des lightweight kernel threads (LWKT), un système intégré au noyau pour les transferts de messages, et les systèmes de fichiers HAMMER et HAMMER2. HAMMER a longtemps fasciné du monde sur LinuxFr, comme en témoignent les trolls hors-sujet, sans doute déçus de ne pas voir venir Btrfs. Il reste utilisable, mais HAMMER2 est désormais le système de fichiers mis en avant par le projet, même si toutes les fonctionnalités prévues ne sont pas encore implémentées.

La série 6.2 amenait le support matériel des hyperviseurs type-2 grâce au portage de NVMM (NetBSD Virtual Machine Monitor, utilisé avec QEMU comme son équivalent KVM sous Linux), le portage du pilote AMDGPU depuis Linux 4.19, le redimensionnement du système de fichiers HAMMER2 et la possibilité expérimentale de le monter à distance.

La version 6.4 contient énormément de correctifs et de mises à jour du système de base.

Le projet compte trop peu de contributeurs réguliers et investis pour arriver à porter les pilotes graphiques les plus récents et les pilotes des cartes wifi. En effet la plupart des pilotes arrivent pour le noyau Linux et/ou FreeBSD. Ils nécessitent au minimum une adaptation, au pire une réécriture, voire une resynchronisation complète de certains sous-systèmes, telle la pile USB. L'alternative d'une couche de compatibilité est à l'étude (comme peuvent l'utiliser Haïku (OpenBSD compatibility layer et FreeBSD compatibility layer) ou FreeBSD avec le module Linux KPI).

Les principales nouveautés de cette version 6.4 pour les utilisateurs, sont :

  • des correctifs côté noyau
  • des correctifs concernant les système de fichiers, msdosfs et HAMMER2, dont un de niveau critique, qui pouvait notamment amener à une corruption du système de fichiers sur ce dernier dans certains cas
  • des améliorations côté réseau avec le support de l'Edimax EW-7811Un V2 par le pilote urtwn et quelques ajouts concernant les pare-feu ipfw et pf ainsi que le module if_bridge
  • ajouts de fonctionnalités à dsynth pour la construction des dports
  • de nombreuses mises à jour des outils utilisés dans le système de base :
    • vendor/awk - Upgrade to 20220912
    • vendor/bmake - Upgrade to 20220928
    • vendor/byacc - Upgrade to 20221106
    • vendor/dialog - Upgrade to 1.3-20220728
    • vendor/expat - Upgrade to 2.5.0
    • vendor/file - Upgrade to 5.43
    • vendor/ldns - Upgrade to 1.8.3
    • vendor/less - Upgrade to 608
    • vendor/libarchive - Upgrade to 3.6.1
    • vendor/libedit - Upgrade to 2022-10-30
    • vendor/libpcap - Update to 1.10.1
    • vendor/TCPDUMP - Update to 4.99.1
    • vendor/LIBRESSL - Update to 3.6.1 + local modifications
    • vendor/OPENSSH - Upgrade to 9.1p1
    • vendor/TCSH - Upgrade to 6.24.02
    • vendor/TNFTP - Upgrade to 20210827
    • libarchive - 3.6.1 import + adjustments
    • xargs - Sync with FreeBSD

Comme à l'accoutumée, il a fallu recompiler l'ensemble des ports pour cette version. Le processus de mise à jour reste inchangé et il est expliqué dans les notes de version détaillées.

Portage en cours de HAMMER2

Une information pas forcément liée directement à la version, mais qui peut intéresser, est le travail en cours de la part de Tomohiro KUSUMI, un développeur NetBSD à l'origine, de porter HAMMER2 vers FreeBSD puis vers NetBSD. La version 1.00 est sortie en novembre 2022 pour FreeBSD et en janvier 2023 pour NetBSD, il y a eu plusieurs versions correctives depuis. Pour l'instant le système de fichiers est utilisable dans une version proposée en lecture-seule via un port à installer (le support en écriture n'était pas prévue, mais finalement si, plus tard).

Aller plus loin

  • # à tester

    Posté par  (Mastodon) . Évalué à 5. Dernière modification le 10 février 2023 à 14:45.

    Je l'ai utilisé il y a quelques années comme NAS (quand hammer2 n'existait pas encore) mais je l'avais ensuite abandonné sans le retester parce qu'il manquait à mon avis un hyperviseur pour en faire le serveur multifonction dont j'avais besoin.

    Je n'avais pas réalisé qu'un hyperviseur était arrivé entre temps et vu que j'en termine avec les vps et que mes raspberry pi ne sont pas suffisantes pour l'autohébergement qui m'intéresse j'ai réinstallé mon cube miniitx sous almalinux la semaine dernière. Je crois qu'avant de poursuivre et d'y mettre des données importantes je dois tester de nouveau dragonflybsd. Quelqu'un pour un lien vers un papier sur les différences principales entre HAMMER et HAMMER2?

    J'avais aussi vu passer quelque part que quelqu'un avait porté hammer2 sur netbsd et je crois qu'il y a un autre projet pour openbsd mais est-il encore actif? Bien que j'apprécie ZFS, je n'ai jamais compris pourquoi aucune distro linux n'avait tenté le port de hammer qui a une licence qui le rend bien plus facile à intégrer au noyau.

    • [^] # Re: à tester

      Posté par  (site web personnel) . Évalué à 3. Dernière modification le 10 février 2023 à 16:03.

      Bien que j'apprécie ZFS, je n'ai jamais compris pourquoi aucune distro linux n'avait tenté le port de hammer qui a une licence qui le rend bien plus facile à intégrer au noyau.

      pour ZFS, la licence est problématique pour l'intégrer au noyau Linux (même si avec fuse ça peut le faire)

      pour HAMMER2, c'est du BSD mais ça prend du temps de passer d'un noyau BSD à un noyau Linux, je ne suis pas sûr que cela soit à une distribution de s'en charger :/

      => bref, ça donne plutôt envie d'attendre que cela soit prêt à remplir l'objectif initialement mis en avant :-) (et, oui, ça prend du temps :/ ext4 aussi a pris du temps…)

      Note : la page https://www.dragonflybsd.org/hammer/ indique quelques apports de HAMMER2

      • [^] # clustering et Single System Image

        Posté par  . Évalué à 4. Dernière modification le 12 février 2023 à 08:43.

        La partie sur le clustering n'est plus aussi intéressante qu'il y a 10 ans, je doute que ce soit encore un objectif majeur d'HAMMER2. En effet, on croyait beaucoup aux grappes de machines qui apparaissaient comme une machine unique. Ce qu'on appelle du Single System Image (SSI) : on prend un cluster de machine hétérogène, on installe le soft magique, et hop, toutes les machines n'en font plus qu'une ; les ressources CPU, disques, mémoire sont partagées et gérées de façons globales. Par exemple on a beaucoup parlé de Kerrighed ici-même. Jean Parpaillon, qui fut membre de l'équipe, pourrait peut-être en parler.

        Il me semble que les SSI sont plus ou moins abandonné parce que l'intéret s'est déplacé sur les machines virtuelles.

      • [^] # Re: à tester

        Posté par  (Mastodon) . Évalué à 4. Dernière modification le 11 février 2023 à 14:09.

        => bref, ça donne plutôt envie d'attendre que cela soit prêt à remplir l'objectif initialement mis en avant :-) (et, oui, ça prend du temps :/ ext4 aussi a pris du temps…)

        Ce sont des fonctionnalités que peu de FS ont, ça ne veut pas dire que hammer2 n'est pas déjà prêt pour les cas d'usages habituels de zfs, lvm+ext4/xfs, stratis+ext4/xfs ou btrfs.

        Perso j'ai une machine avec du btrfs et c'est la seule pour laquelle j'ai souffert une corruption de données du jour au lendemain ces 10 dernières années. Donc oui je suis interressé par les alternatives.

        • [^] # Re: à tester

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

          ça ne veut pas dire que hammer2 n'est pas déjà prêt pour les cas d'usages habituels de zfs, lvm+ext4/xfs, stratis+ext4/xfs ou btrfs.

          ah mais je n'ai pas dit ça ;- d'autant que Dragonfly l'a pris comme filesystem de prédilection, cela montre bien qu'il est abouti sur le §Filesystem Core

          Merci de vos précisions.
          Peut-être faudrait-il ajouter dans le statut du document DESIGN les priorités (révisées) et une indication de la stabilité (ou toute autre méthode, comme MoSCoW… utilisée dans les RFC) ?

          • [^] # Re: à tester

            Posté par  . Évalué à 4.

            Peut-être faudrait-il ajouter dans le statut du document DESIGN les priorités (révisées) et une indication de la stabilité (ou toute autre méthode, comme MoSCoW… utilisée dans les RFC) ?

            Je ne suis pas Matthew Dillon :-)

  • # Encore un portage pour HAMMER2

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

    Pour info, il y a visiblement un port en cours de Hammer2 vers OpenBSD : https://github.com/kusumi/openbsd_hammer2

Suivre le flux des commentaires

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