FreeBSD 9.2 est là

Posté par  (site web personnel) . Édité par ZeroHeure, Joris Dedieu, Benoît Sibaud, Nÿco et claudex. Modéré par ZeroHeure. Licence CC By‑SA.
Étiquettes :
40
1
oct.
2013
FreeBSD

FreeBSD 9.2 est sorti, apportant son lot de correctifs et de nouveautés.

Cette version sera supportée pendant un an, contrairement à FreeBSD 9.1 et FreeBSD 8.4 qui bénéficient de support sur le long terme et sont donc supportés pendant 2 ans.

FreeBSD Releases

Mises à jour

Tampons d'entrées/sorties non mappés

Un des gros points faibles de FreeBSD est le « Giant Lock », autrement dit le mutex global intégré au kernel. Ce mutex pose des soucis de performances en environnement multicoeurs/parallèle.

Le patch d'entrées/sorties non mappées permet de résoudre un problème de performances associé aux pages mémoires (KVA). Ces pages mémoire sont communes à l'ensemble des coeurs du processeur. Lorsqu'elles doivent être mises à jour fréquemment, le mutex pose des soucis de performances (accès concurrent à KVA). Le principe de ce patch est d'outrepasser KVA en n'y enregistrant pas les pages.

BPF et les performances réseau

Jusqu'à présent le support de BPF se faisait au prix d'une utilisation intensive des ressources afin de traiter les paquets (congestion).
Cette version 9.2 introduit la variable net.bpf.optimize_writer et des modifications sur le système de verrous rendant l'utilisation de BPF optimale sur des machines traitant énormément de paquets (cartes 10Gbps, par exemple).

ZFS

ZFS a subi quelques améliorations intéressantes :

  • la commande TRIM est désormais supportée, améliorant sensiblement la durée de vie des SSD ;
  • il est maintenant possible d'utiliser la compression LZ4 sur les zpool.

Pilotes

Cette nouvelle version est l'occasion de supporter de nouveaux pilotes, d'en supprimer d'autres et d'en mettre à jour.

  • Ajout du support de virtio dans le noyau GENERIC pour architectures x86 et amd64.
  • Ajout du support des cartes PCI-Express HighPoint DC Series Data Center HBA (DC7280 and R750).
  • Ajout du support de la commande ATA pass-though dans le pilote CAM.
  • Mise à jour des pilotes Intel e1000, améliorant les performances.
  • Mise à jour des pilotes Intel ixgbe.
  • Mise à jour des pilotes Chelsio cxgbe. La carte Chelsio T580-LP-SO-CR (2x40Gbps) est désormais officiellement supportée.
  • Mise à jour des pilotes NVMe (SSD en PCI Express).
  • Suppression du pilote firewire dans le noyau GENERIC (il est possible de le réactiver en compilant un noyau personnalisé).

Logiciels

FreeBSD est une distribution packagée. Elle embarque donc son lot de logiciels prêts à l'emploi.

On notera surtout:

  • OpenSSH 6.2p2
  • OpenSSL 0.9.8y
  • Sendmail 8.14.7
  • Support du protocole HTTP dans l'installeur de FreeBSD (bsdinstall).

Chargeur de démarrage

Le chargeur de démarrage a été mis à jour. Il est plus rapide et d'apparence plus coloré.

bootloader

Les plus malins auront noté l'allusion au film Die Hard. Vous pourrez d'ailleurs modifier le fichier loader.conf pour l'occasion, comme ci-dessous :

loader_logo="tribute"

tribute-bootloader

Processus de mise à jour

Pour ceux ayant une infrastructure FreeBSD, voici la procédure de mise à niveau de vos systèmes (testée et approuvée ce matin sur une dizaine de serveurs avec des rôles différents) :

freebsd-update fetch
freebsd-update -r 9.2-RELEASE upgrade
freebsd-update install
reboot
freebsd-update install

Si vous choisissez la mise à jour par les sources, sachez que FreeBSD utilisera dorénavant l'utilisateur auditdistd pour compiler les sources, et non plus l'utilisateur courant.

Conclusion

Cette nouvelle version de FreeBSD, bien que sans support à long terme, suit la logique d'innovation de cette 9e série de FreeBSD, basée sur l'optimisation des performances.

À manger sans se priver !

Aller plus loin

  • # Remarque

    Posté par  . Évalué à 5.

    (testée et approuvée ce matin sur une dizaine de serveurs avec des rôles différents)

    Marrant d'upgrader un serveur dès la sortie de la mise à jour. Dans le monde Windowsien je vois plutôt des sysadmin frileux qui se trimbalent encore du 2003 voire 2000 par peur de casser un truc lors de la mise à jour.

    • [^] # Re: Remarque

      Posté par  . Évalué à 5.

      Ça dépend ce qui tourne dessus, quand il y a des logiciels qui demande un environnement particulier, la mise à jour peut être vite casse gueule. Si tu as uniquement des logiciels de la distribution, c'est plus facile en général.

      « 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: Remarque

        Posté par  (site web personnel) . Évalué à 7. Dernière modification le 01 octobre 2013 à 18:39.

        Je suis de ton avis MTux. Néanmoins je surveille toujours les listes de diffusion afin de savoir à quoi m'attendre et ce qui sera peut être problématique à la sortie d'un release.
        9.2 est une release mineure de la série 9, elle ne devrait pas poser de souci, et c'est, dans le processus d'upgrade, c'est effectivement le cas, je n'ai rien eu à recompiler niveau ports tout était directement cohérent.

        FreeBSD est réputé pour sa stabilité et ce n'est pas pour rien :). En tout cas les Unmapped I/O sont une tuerie. Ca se sent vraiment à l'usage.

        Il faut savoir que sur les BSD un release est toujours très proche de la stabilité. Les seuls points noirs sont le matériel, surtout lorsque le support est récent (oui OpenBSD 5.3 et la carte broadcom 5720 de Dell, c'est à toi que je pense !)

        Par contre FreeBSD 10 sera une autre affaire. Entre le BHYVE et la suppression de GCC il risque d'y avoir des couac, la je testerai plus en profondeur.

        Veepee & UNIX-Experience

      • [^] # Re: Remarque

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

        il y a des logiciels qui demande un environnement particulier,

        C'est justement l'un des grands intérêts de FreeBSD. Les mises à jour du système de base ne pètent pas le fonctionnement des logiciels tiers. Même pour les versions majeures, un module de compatibilité est fournie (il faut faire gaffe quand même dans ce cas). Par exemple j'ai quelques serveurs en FreeBSD 9.1 qui font tourner des mysqld 3.23 compilés pour FreeBSD 5.5. Cela se traduit principalement par un module du noyau offrant une compatibilité au niveau de l'ABI ainsi qu'une libc compatible.

        Personnellement pour les montés de version mineure, je ne me pose même pas de question.

    • [^] # Re: Remarque

      Posté par  . Évalué à 5.

      Y'a aussi le fait que dans ce cas faut racheter une licence et toutes les CAL qui vont avec.

    • [^] # Re: Remarque

      Posté par  (site web personnel) . Évalué à 6. Dernière modification le 01 octobre 2013 à 20:04.

      J'oubliais de préciser, ce release est attendu depuis près d'un mois, il y avait des RC à n'en plus finir (RC4 je crois voire RC5), afin de stabiliser le système. Le point que je surveillais était un deadlock NFS qui était apparu sur la 9.2, mais il a été résolu.
      En terme de veille, les listes de diffusion de FreeBSD sont vraiment bien, car c'est en voyant l'expérience des utilisateurs et les différents problèmes qu'on peut voir si un release avance bien. Hormis ce deadlock qui paraissait inquiétant il n'y avait pas vraiment d'autre problème énoncé sur les listes, on pouvait donc être confiant :)

      Veepee & UNIX-Experience

      • [^] # Re: Remarque

        Posté par  . Évalué à 3.

        C’est vrai que, j’ai eu assez peur en voyant les rapports de bogues rapportés par la communauté et les discussions qui ont suivies, alors que la RC était sortie…

        Par ailleurs, j’ai suivi, sur mon serveur, les versions suivantes :

        9.1-RELEASE -> 9-STABLE (compilée à la main) -> 9.2-RC1 -> 9.2-RC4 -> 9.2-RELEASE

        J’étais passé sur stable pour pouvoir utiliser poudriere avec ZFS, il y avait des bogues avec le système de fichier qui empêchait de démonter les volumes et de les réutiliser. Maintenant tout est bon.

        Tout s’est super bien déroulé, j’avais eu quelques appréhensions sur le passage du système compilé sur la branche stable à la RC via les binaires, mais pareil, aucun problème. Les jails sont en parfait état, c’est chouette quoi.

      • [^] # Re: Remarque

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

        Hormis ce deadlock qui paraissait inquiétant il n'y avait pas vraiment d'autre problème énoncé sur les listes, on pouvait donc être confiant :)

        J'ai pas mal de soucis sur VFS encore (et visiblement je suis pas le seul)… Point de salut avec 9.2-RELEASE ici (c'était trop tard). Ama ça mérite un errata.

        les pixels au peuple !

  • # Avenir de ZFS?

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

    Qu'est ce qu'il va se passer à propos du support ZFS maintenant qu'oracle ne file plus le code?

    • [^] # Re: Avenir de ZFS?

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

      Pour le moment on a OpenZFS qui est apparu, reliant les communautés BSD et Solaris autour de ZFS. La version 28 de ZFS est la dernière. Elle intègre un système de "plugins" pour ZFS. Maintenant reste à voir l'innovation autour de ZFS, le code étant sous licence CDDL et les développeurs bridés. L'idéal serait de réécrire le code de ZFS afin de le libérer (licence BSD), mais je ne pense pas que ce sera pour tout de suite.

      Veepee & UNIX-Experience

      • [^] # Re: Avenir de ZFS?

        Posté par  . Évalué à 2.

        L'idéal serait de réécrire le code de ZFS afin de le libérer (licence BSD), mais je ne pense pas que ce sera pour tout de suite.

        Si ça arrive un jour, il intégrera probablement le noyau linux au passage.

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

  • # Encore un Giant Lock ?

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

    Un des gros points faibles de FreeBSD est le « Giant Lock », autrement dit le mutex global intégré au kernel.

    Heu, je suis surpris là. Je croyais que depuis les versions 7, FreeBSD avait fini par remplacé le Giant Lock au profit de locks plus fins ou d'une approche lockless. Est ce à dire que, finalement, ils seraient en retard là dessus vis à vis de DragonFlyBSD ?

    • [^] # Re: Encore un Giant Lock ?

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

      Certaines parties du code ne peuvent pas être aussi finement gérées au niveau des mutexes. C'est le cas de KVA qui est l'autoroute de gestion des pages mémoire, et c'est un point extrêmement difficile à gérer au niveau parallélisation.

      Boote un FreeBSD et tu verras que le giant lock se manifeste plusieurs fois lors du boot lorsqu'il charge tes drivers, notamment. Après je suis pas expert du noyau, mais je sais que ce giant lock est le problème principal de tous les BSD (OpenBSD mettant le plus de temps à s'en séparer). Si je ne dis pas de bêtises il me semble que DragonFly est légèrement en avance sur FreeBSD de ce point de vue.

      Veepee & UNIX-Experience

      • [^] # Re: Encore un Giant Lock ?

        Posté par  (site web personnel) . Évalué à 4. Dernière modification le 01 octobre 2013 à 19:08.

        Si je ne dis pas de bêtises il me semble que DragonFly est légèrement en avance sur FreeBSD de ce point de vue.

        Oui il semblerait. En fait, si je ne me trompe pas, le Giant Lock dans DragonFlyBSD n'est plus qu'au niveau du VFS et il y a toujours un effort de réduire son usage. Après, l'architecture multi-threading de DragonFlyBSD diffère des autres BSD ; celle-ci s'appuie sur une approche de synchronisation par tokens qui peuvent transiter d'un CPU à l'autre.

    • [^] # Re: Encore un Giant Lock ?

      Posté par  . Évalué à 10.

      Pour ce qui est du giant lock,(appelé MPLock dans BSD si je me souviens bien), je ne sais pas, par contre il y a bien un point où ils ne sont pas novateurs par rapport à DragonFlyBSD dans ce paragraphe, c'est les unmapped buffers. DragonFly a introduit xio (désolé, pas de page de manuel, oui c'est assez triste) il y a 9ans. Il s'agit d'une implémentation de buffers non mappés.

      Je vais essayer de résumer la situation telle que je la comprends, une partie des informations est peut être erronée, mais il me semble que le problème n'est pas le Giant Lock.
      Un noyau unix présente aux applications une abstraction du matériel, et permet aux applications de partager celui ci. Les buffers jouent une place importantes dans cette tâche, car ils permettent de gérer des données d'entrée/sortie. Ils sont notament présents dans la couche VFS (systèmes de fichier) ou dans la pile réseau. L'interface couramment utilisée sous BSD s'appelle uio, elle date des temps anciens d'unix qui échappent à mes maigres talents d’archéologue. Hormis les détails d'implementation parce que ça stoque plus d'infos qu'un simple buffer, il s'agit de buffers classiques, qu'on peut résumer à un espace de mémoire et la taille du buffer. Si on veut allouer un nouveau buffer simple, il faut allouer de la mémoire virtuelle sur le tas, soit dans celle du noyau, soit dans le tas processus utilisateur.

      Pour allouer des buffers sur le tas, il faut créer un mapping mémoire et reserver un espace contigu dans la mémoire virtuelle. Cette opération modifie la table des pages. Les noyaux BSD, (comme linux) que l'espace mémoire du noyau ne soit pas un espace distinct : il s'agit juste d'une zone mémoire mappée dans la "hight memory", c'est à dire le haut de l'espace d'addressage virtuel de chaque processus. C'est à dire que tout les processus en cours d'execution partagent ce mapping. S'il on crée un buffer, on doit donc informer tout les cpu que le mapping de cette zone à changé. Cela implique une synchronisation par Inter process interupt du TLB pour invalider l'ancien mapping. Il s'agit donc d'un point de contention sur les systèmes SMP.

      Les buffers non mappés répondent à ce problème. Au lieu de mapper de la mémoire physique dans l'espace d'addressage, le buffer est une liste de page mémoire physique telle que représentées par le système de gestion de la mémoire virtuelle. Quand on veut écrire ou lire le buffer, on peut modifier directement et une à une ces pages mémoire physique. Bien évidement, c'est moins intuitif qu'un simple memcpy d'un block contigu de mémoire, mais en fournissant une api intuitive, le gain est substantiel. En effet, pour créer un buffer, il suffit desormais de trouver assez de page mémoire physique disponibles, et de les verouiller pour informer le système de gestion de la mémoire qu'elles sont utilisées. Il y a bien sûr là encore des verrous à traiter, mais avec un système de verrou à grain fin dans la gestion de la mémoire, les collisions sont beaucoup plus rare, il n'y a plus de synchronisation de tout les cpu à chaque fois. Ce gain peut être très important, il semble que les premières utilisations de xio sous dragonfly étaient pour un système de passage de message pour applications en espace utilisateur, et les archives de l'époque affirme que le gain était de 20%.

    • [^] # Re: Encore un Giant Lock ?

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

      Je croyais que depuis les versions 7, FreeBSD avait fini par remplacé le Giant Lock au profit de locks plus fins ou d'une approche lockless.

      Ben en fait, ils ont croisé le monstre du lockless.

      Pardon aux familles, pas pu résister…

      Prochainement, je vous proposerai peut-être un commentaire constructif.

  • # Erreurs

    Posté par  . Évalué à 3.

    Le lien pour BPF devrait être http://fr.m.wikipedia.org/wiki/Filtre_BPF.

    On n'écrit pas «9è» (ou «9ème» d'ailleurs) mais «9e».

    Écrit en Bépo selon l’orthographe de 1990

Suivre le flux des commentaires

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