Sortie du noyau Linux 3.9

67
29
avr.
2013
Linux

La sortie de la version stable 3.9 du noyau Linux vient d’être annoncée par Linus Torvalds.
Le nouveau noyau est, comme d’habitude, téléchargeable sur les serveurs du site kernel.org.

Pour cette version, on voit surtout la poursuite de travaux de longue haleine (nettoyage/regroupement des architectures ARM, refonte de la gestion des modes d’affichage des puces graphiques Intel…), des traditionnelles corrections de bogues et optimisations (LZO, gestion de l’énergie…) même si quelques nouveautés se démarquent (gestion des ventilateurs de certaines puces graphiques NVIDIA, prise en charge des RAID 5 et 6 sous Btrfs, prise en charge de certaines architectures ARM par KVM, possibilité d’utiliser un SSD comme cache d’une autre unité de stockage…).

À noter, une nouveauté déconnectée des notes de cette version mais apparue pendant son développement : Xen est dorénavant un projet de la Fondation Linux (lire la dépêche dédiée).

Le détail des évolutions, nouveautés et prévisions est dans la seconde partie de la dépêche.

Merci aux participants à la rédaction de cette dépêche : Davy Defaud, Batchyx (notamment la partie réseau), jcr83, Jiehong, Sidonie Tardieu, yogitetradim, baud123, Étienne Bersac (notamment la partie virtualisation), detail_pratique, Martin Peres, Mali, Maxime, Xavier Claude, Jarvis, alpentux, Nils Ratusznik, Tata Jeanette, kripteks, Strash, Akiel et patrick_g (notamment la partie statistiques).

Sommaire

La phase de test

RC-1

La version RC-1 a été annoncée par Linus le 3 mars :

« Cela fait deux semaines, (OK, treize jours, mais c’est suffisamment proche), la fenêtre d’intégration est désormais fermée, et j’ai arrêté la version 3.9-rc1.

Je ne sais pas si c’est seulement moi, mais cette fenêtre d’intégration a connu plus de moments “Uhhuh” que d’habitude. J’ai arrêté le processus d’intégration plusieurs fois à cause de bogues qui semblaient vraiment effrayants, mais heureusement à chaque fois les gens ont été aussi présents que les paparazzi autour de Justin Bieber. Un grand merci à Peter, Ted et Rafael (et également aux personnes ayant rapporté les bogues !) pour leur réactivité. Ça aurait pu être bien pire.

Comme d’habitude, il y a des changements partout. Nous avons deux nouvelles architectures (Metag et ARC) et des tonnes de travaux sur ARM (comme d’habitude) avec encore plus de plates‐formes passant sous le giron générique. Les développeurs MIPS ont essayé de rivaliser en nettoyant les espaces dans leur code, mais ceux d’ARM sont restés en tête en termes de changements sur leur plate‐forme.

Nous avons également des mises à jour de presque tous les systèmes de fichiers, même si Btrfs (code initial RAID 5 & 6, instantanés et performances de fsync) et ext4 (perforation, cache des extents et aussi performances de fsync) ont bénéficié des plus grands changements.

Mais la plupart des mises à jour (environ 60 %) sont du côté des pilotes, comme d’habitude. Les principales se trouvent dans le processeur graphique, le réseau, la [branche de] recette — staging —, le contrôleur de broches pinctrl, le son ; mais il y en a un peu partout.

Il y a pas mal de trucs, et, comme à l’accoutumée, même le résumé des modifications est vraiment trop long pour être posté ou survolé. Je vous suggère d’utiliser git pour vérifier la partie qui vous intéresse.

Linus »

RC-2

La version RC-2 est sortie le 10 mars :

« Salut, les choses ont été raisonnablement calmes. Bien sûr, Dave Jones a créé un peu de désordre avec Trinity, ce qui nous a tous agité un brin ; mais Al est de retour, et espérons qu’il est désormais occupé à chevaucher virtuellement à notre rescousse sur son cheval blanc. Mais sinon, tout s’est bien passé pendant cette phase de RC.

Le diffstat est raisonnablement plat (un bon signe), avec les pilotes de réseau sans fil qui sortent du rang. Ceci est principalement dû à un nouveau pilote pour le contrôleur USB Gigabit ASIX AX88179_178A.

À part ces pilotes réseau, nous avons eu des mises à jour DRM, md et GPIO, Btrfs, réseau, ARM, son… Des trucs un peu partout, mais rien de terriblement inquiétant. Considérant que certaines RC2 sont trop longues pour pouvoir publier le résumé de leurs modifications, je suis content.

Et maintenons les choses ainsi ! OK ?

Linus »

RC-3

La version RC-3 a été annoncée le 17 mars :

« Pas aussi petite que la -rc2, mais cette dernière était exceptionnellement calme. Il y avait donc clairement des choses en attente qui sont arrivées pour cette -rc3, avec des pilotes réseau et USB dans le peloton de tête. Mais il y a aussi divers pilotes, des mises à jour d’architectures, des corrections sur Btrfs, etc.

Linus »

RC-4

La version RC-4 a été annoncée le 23 mars :

« Une semaine plus tard, voici une nouvelle -rc. Et les choses ne se sont pas calmées, ce qui démontre que la gentille petite version -rc2 était certainement une exception. Mais je suis optimiste, bon sang, et je vais continuer à espérer que les choses vont changer, et que la semaine à venir sera ennuyeuse et dépourvue du moindre travail réel.

Cela vaudrait mieux, car ce sont les vacances de printemps et les enfants sont là. Qu’importe.

Bien que ça n’ait pas été aussi calme que je l’aurais voulu, ce n’est pas pour autant que les choses ont été incroyablement passionnantes non plus. La plupart des modifications sont vraiment assez triviales. La majeure partie du travail est terminée dans les pilotes (DRM, md, net, mtd, USB, son), mais aussi dans les mises à jour des plates‐formes (PowerPC, ARM, SPARC, x86) et le travail sur les systèmes de fichiers (CIFS, ext4).

Allez la tester,

Linus »

RC-5

La version RC-5 est, elle, sortie le 31 mars :

« Nouvelle semaine, nouvelle -rc.

Je suis comme la poste américaine : “Ni la neige, ni la pluie, ni la chaleur, ni l’obscurité de la nuit” ne m’empêcheront de faire des sorties hebdomadaires de -rc. De petites vacances comme Pâques ? Bah, fumisteries. Cela pourrait bien retarder le courriel de sortie de quelques heures parce qu’un homme doit se goinfrer d’un étrange dessert de saison (et les desserts de Pâques finlandais sont plus étranges que bien d’autres), mais ça n’arrêtera pas la progression inéluctable vers la publication 3.9 finale.

Donc la voici. Une pimpante nouvelle version prête à sortir n’attendant plus qu’à être testée.

Rien de particulier ne se distingue. Les mises à jour du DRM Exynos et des pilotes IBM RamSan sont un peu plus grosses que le reste, une mise à jour de L2TP… Le reste étant de plutôt petits correctifs un peu partout. La plupart sont des pilotes (block, net, media, TTY, USB), du réseau et des mises à jour de systèmes de fichiers (Btrfs, NFS). Quelques mises à jours d’architectures (x86, ARC).

Les choses semblent se calmer un peu, et tout semble en bonne voie pour la sortie de la 3.9 dans quelques semaines.

Linus »

RC-6

La version RC-6 a été annoncée le 7 avril :

« Les choses semblent en bonne voie et la semaine a été plutôt ennuyeuse. Beaucoup de petites corrections, quelques retours en arrière. Du réseau, des petites corrections sur les architectures (ARM, MIPS, S/390, Alpha, TILE, x86), des pilotes, des mises à jour mineures des systèmes de fichiers (GFS2, ext4, une minuscule correction des attributs étendus de ReiserFS). Rien d’enthousiasmant ne se distingue, je pense que le résumé des modifications qui suit dresse un bon état des lieux pour les gens qui se complairaient dans les détails…

Les choses semblent en bonne voie, ce qui signifie qu’à moins que quelque chose n’apparaisse, la RC7 sera probablement la dernière RC, comme d’habitude.

Linus »

RC-7

La version RC-7 a été annoncée le 14 avril :

« Nouvelle semaine, nouvelle -rc.

Il s’agit majoritairement de divers correctifs d’une ligne, avec quelques corrections de pilotes légèrement plus grosses. La plus intéressante (pour moi, et probablement personne d’autre) est une correction pour un bogue plutôt subtile d’invalidation du cache TLB qui ne touche que les PAE [extension d’adresse physique] 32 bits, en raison de la façon étrange dont ça fonctionne. Même dans ce cas, vous ne serez touché que dans des cas de correspondances particulièrement alambiqués, néanmoins nous suspectons cette erreur d’être la cause des bogues déclenchés par Google Chrome, tels que :

chrome: Corrupted page table at address 34a03000
*pdpt = 0000000000000000 *pde = 0000000000000000
Bad pagetable: 000f [#1] PREEMPT SMP

Cependant, ce problème est si rare que nous n’avons pas pu vérifier que cela le résout réellement.

Ceci étant dit, ce bogue est nettement plus commun (et par “nettement plus commun”, je veux dire “toujours littéralement impossible à rencontrer, à moins d’être vraiment malchanceux”) sur des machines récentes qui ont un plus gros cache TLB et qui auraient pu tourner sans problème en mode 64 bits sans ce dégoutant avorton qu’est le PAE x86, et une petite voix en moi me dit que toute personne rencontrant ce problème sur une telle machine n’a probablement que ce qu’il mérite.

Mais si vous avez vu des messages comme celui‐ci, et que vous fonctionnez toujours en PAE, essayez la nouvelle -rc.

Le reste des corrections est sans doute plus pertinent pour la plupart des gens, mais eh, celle du PAE m’a titillé l’esprit. Quoi qu’il en soit, allez la tester, malgré le problème de PAE.

Linus »

RC-8

La version RC-8 a été annoncée le 21 avril :

« Oui, j’espérais vraiment (et je l’avais à l’origine prévu) sortir la version 3.9 finale ce week‐end, mais nous avons eu suffisamment de problèmes pour que je ne me sente pas à l’aise avec ça. C’était limite, aucun des problèmes n’était énorme ; et peut‐être aurais‐je pu me contenter de baptiser cette -rc en version 3.9 et ouvrir la fenêtre d’intégration. Mais eh, une semaine supplémentaire ne fera pas de mal.

Le gros des changements concerne ici le réseau (à la fois le cœur et les pilotes), mais il y a des corrections de bogues sur les architectures (SPARC, x86, ARM et PowerPC) et divers trucs. Deux ou trois retours en arrière et un peu de nettoyage. Le résumé des modifications donne une idée du détail. Rien en soi n’aurait dû retarder la sortie de la 3.9 à mon sens, mais j’espérais une semaine plus calme.

S’il vous plaît, ne m’envoyez plus de demandes d’intégration, à moins que ce soit quelque chose de vraiment critique, et donnons‐nous pour objectif une sortie très calme de la version 3.9 le week‐end prochain. D’accord ?

Linus »

Le détail des nouveautés

Mise en veille « suspend freeze » pour tous et PowerClamp pour processeurs Intel

Cette version du noyau introduit PM_SUSPEND_FREEZE, un nouveau mode de mise en veille.

Il sagit d’un mode de mise en veille intermédiaire, permettant un réveil plus réactif que suspend-to-RAM (alias PM_SUSPEND_MEMORY) mais en contrepartie moins économe en énergie (le processeur tourne toujours mais au ralenti, car les traitements en cours sont interrompus).

Ce nouveau mode bénéficiera principalement aux ordiphones et tablettes.

Un autre ajout de cette version est cette fois spécifique aux processeurs Intel ; il s’agit de PowerClamp, un pilote qui permet de limiter la consommation processeur en utilisant ses capacités de mise en veille — C state — plutôt qu’en jouant sur la vitesse de son horloge.

Du côté d’ARM

Ce noyau, dans la lignée de ce qui est fait depuis la version 3.7 apporte de nombreuses améliorations concernant la prise en charge des architectures ARM.

Le travail de nettoyage et d’harmonisation devrait se poursuivre encore pendant une ou deux versions, mais le travail effectué peut déjà être mesuré, dans le sens où 18 systèmes mono‐puces (SoC) sont maintenant pris en charge en mode « multi‐plate‐forme » (le but étant d’arriver à : « un même noyau pour tous » à l’identique des architectures x86).

Pilotes graphiques pour vos PC

Intel

Intel continue de préparer l’arrivée des futurs processeurs Haswell (successeurs des Ivy Bridge, dont la sortie est prévue pour le 4 juin prochain et qui sont pleinement pris en charge par le noyau depuis la version 3.8.2) et Valley View (SoC à base de processeur Atom) qui, rappelons‐le, utilisent tous deux un cœur graphique de même génération que celui équipant les actuels processeurs Ivy Bridge (Gen7).

Parallèlement, les pilotes des générations actuelles poursuivent leur importante refonte de la gestion des modes d’affichage entamée avec la version 3.7, avec cette fois la reprise du modeset locking (voir le billet de Daniel Vetter à ce sujet).

Nouveau (pilote libre pour puces NVIDIA)

Le pilote Nouveau offre finalement la possibilité de gérer (manuellement ou automatiquement) le ventilateur sur les puces NV40 et NV50 (équipant les cartes GeForce 6xxx à 9xxx et les puces graphiques 1xx à 3xx). Ce point avait été évoqué lors la sortie de la version 3.7. Cette fonctionnalité est cependant désactivée par défaut, en attendant qu’assez de testeurs aient pu valider le comportement du ventilateur dans toutes les situations.

Toujours dans la catégorie gestion énergétique, Nouveau vérifie maintenant la température de la carte et peut éteindre l’ordinateur si celle‐ci devient critique (environ 130 °C). Cette fonctionnalité est activée par défaut sur les cartes ayant une sonde de température interne (non I²C), à l’exception des NV50 (GeForce 8800, pas la famille des NV50). Le support des NV50 devrait être intégré dans la version 3.10.

Par ailleurs, les fonctionnalités DMA-BUF/PRIME (permettant de gérer les systèmes intégrant deux puces graphiques, la plus puissante — mais aussi la plus gourmande — devant prendre le relais quand le besoin se fait sentir) ont été intégrées avec une licence permettant aux pilotes non libres d’en faire usage (ce qui devrait être rapidement le cas, comme l’énonce cette dépêche). NVIDIA peut ainsi bénéficier du travail effectué par la communauté tout en gardant son pilote fermé : chacun appréciera (ou pas). Pour plus de détails, le lecteur pourra se référer à la dépêche saluant la sortie de la version 3.3 du noyau.

Radeon (pilote libre pour puces ATI/AMD)

Les puces AMD de la famille Oland (équipant les cartes de la série Radeon HD 8500 et 8600) sont désormais prises en charge, ainsi que la prochaine génération de puces APU (puce intégrant le processeur central et le processeur graphique), Richland.

Systèmes de fichiers

La nouveauté à souligner est que Btrfs (liste des changements) prend désormais en charge les RAID 5 et 6 (en plus des RAID 0 et 1).

Pour rappel, il y a trois gros avantages à implémenter le RAID dans le système de fichiers au lieu de laisser ce travail à une couche d’abstraction.
Premièrement, la restauration est potentiellement beaucoup plus rapide, car il n’y a besoin de restaurer que les morceaux qui contiennent des données, alors qu’une couche d’abstraction est obligée de toujours restaurer le disque entier.
Deuxièmement, il est possible d’avoir différents types de RAID au sein d’un même système de fichiers, comme les données en RAID 0 et les métadonnées en RAID 1.
Enfin, en cas de corruption de données sur un RAID 0, Btrfs peut se baser sur les sommes de contrôle des métadonnées pour déterminer quelle copie est valide. De même, un correctif améliore aussi les performances de fsync.

Concernant les autres systèmes de fichiers :

Un bogue avait été découvert dans la version 3.0 qui affectait les performances du système de journal d’ext4, JDB2, a été corrigé (liste des changements).

La prise en charge des espaces de noms d’utilisateurs a été introduite précédemment, elle est maintenant disponible pour les systèmes de fichiers CIFS, NFS, Ceph, OCFS2 et quelques autres, mais pas dans XFS. Or, il n’est pas possible d’activer ces namespaces si un système de fichiers qui ne les gère pas est aussi activé, ce qui veut dire que la fonctionnalité ne pourra pas être intégrée dans la plupart des distributions. Pour rappel, cette fonctionnalité permet de donner les droits d’administration à un utilisateur sur une partie restreinte du système de fichiers sans qu’il puisse utiliser ces droits hors de ladite partie.

Réseau

IPv6

L’implémentation d’IPv6 a reçu plusieurs améliorations dans ce noyau. En particulier, des problèmes de sécurité liés à l’implémentation des technologies de transition 6rd et 6to4 sont maintenant corrigibles dans le noyau Linux. Le problème se situe au niveau de l’encapsulation et la décapsulation d’IPv6 à l’intérieur d’IPv4 : l’attaquant peut, dans certains cas, contrôler les adresses de provenance qui seront utilisées lors de l’encapsulation et les adresses de destination qui seront utilisées après la décapsulation. Cela permet de masquer la véritable origine d’une attaque ou d’attaquer le réseau dans lequel se trouve le relais 6to4 ou 6rd.

Ces problèmes et leurs solutions sont détaillés dans les RFC 3964 et 5969. Le correctif de Hannes Frederic Sowa n’implémente qu’une partie des vérifications de ces RFC. Le reste pouvant déjà être corrigé par l’administrateur réseau avec des règles iptables et l’activation du filtrage du chemin inverse (reverse path filtering).

Divers correctifs pour la multidiffusion de groupe sur IPv6, le multicast IPv6, ont également été intégrés dans ce noyau : les trafics de nœud local — node‐local — et interface locale — interface‐local — ne fuiteront plus, et on ne demandera plus aux cartes réseau de recevoir ce type de trafic. En revanche, le noyau rejoindra désormais automatiquement tous les types de groupes all‐nodes et all‐routers (si le routage est activé). Auparavant, uniquement link‐local all‐nodes et link‐local all‐routers étaient automatiquement rejoints.

Enfin, netconsole, qui permet de faire transiter les messages du noyau à travers le réseau, gère maintenant IPv6 en plus d’IPv4.

Netfilter

Ce noyau 3.9 introduit un nouveau système pour marquer des sessions. Jusqu’à présent, l’administrateur réseau qui souhaitait différencier des types de sessions (par exemple, pour privilégier des sessions par rapport à d’autres, ou pour simplifier ses règles de filtrage) n’avait à sa disposition qu’une « marque de connexion » (connmark) sous la forme d’un entier arbitraire de 32 bits. Souvent, cet entier était utilisé comme un masque de bits, ce qui pose certains problèmes : 32 bits ne sont parfois pas suffisants, et il faut que les administrateurs et logiciels se mettent d’accord sur la signification de chaque bit.

Ces problèmes peuvent maintenant être évités avec les connlabels, ou étiquettes de session. Cette nouvelle fonctionnalité de Netfilter permet à un administrateur réseau d’attacher une ou plusieurs étiquettes à une session. C’est équivalent à utiliser connmark comme un masque de bits, sauf qu’il est possible de mettre jusqu’à 128 étiquettes sur une connexion au lieu de 32. Et iptables a été modifié pour que l’administrateur réseau puisse utiliser des noms plutôt que des numéros d’étiquettes.

Une autre fonctionnalité a été ajoutée dans Netfilter : la possibilité d’utiliser un filtre « Berkeley Packet Filter » comme règle iptables. Il était déjà possible de filtrer le contenu des paquets avec u32, mais de manière extrêmement limitée. BPF offre un langage de filtrage plus avancé, avec embranchements, opérations arithmétiques, registres et compilation à la volée sur certaines architectures.

Cela tire parti du fait que BPF était déjà couramment utilisé en tant que filtre d’interface de connexion (socket). Par exemple, les filtres pcap-filter utilisés notamment par tcpdump sont traduits en un programme BPF, et il est donc possible d’utiliser toutes leurs fonctionnalités avec iptables.

Interfaces de connexion

Il est maintenant possible de verrouiller un filtre BPF sur une interface de connexion (socket), de telle sorte qu’il ne puisse pas être enlevé. Cela permet à un processus de verrouiller un filtre sur une interface de connexion privilégiée, avant de se défaire de ses privilèges ou de l’envoyer à un processus non privilégié.

Ce noyau implémente désormais l’option SO_REUSEPORT sur les types d’interface de connexion usuels. Cette option permet à plusieurs processus d’écouter sur un même port, les demandes de connexions étant réparties équitablement entre les différents processus. Couplé à la parallélisation du traitement des paquets (introduit dans le noyau 2.6.35 par le même auteur, Tom Herbert, travaillant chez Google), cela permet d’augmenter les performances des serveurs multicœurs.

Ponts réseau (bridges)

Ce noyau implémente maintenant le filtrage des réseaux locaux virtuels (VLAN) dans les ponts réseaux — bridges — de manière native. Chaque port dispose maintenant d’une liste de réseaux locaux virtuels autorisés, ceux ne faisant pas partie de cette liste seront filtrés en entrée et en sortie du port.

Virtualisation

ARM

KVM prend désormais en charge les processeurs ARM Cortex A15. Pour information, Xen supportera ARM à partir de la version 4.3 prévue cet été.

Les pilotes permettant l’ajout à chaud de processeurs et de mémoire vive du côté « invité », DomU, sont inclus. La suppression à chaud, elle, n’est pas encore prise en charge.

Les entrées‐sorties virtuelles VFIO ont été étendues pour permettre l’accès direct aux cartes VGA aux systèmes invités.

Les pilotes VMCI ont été inclus : ils gèrent la communication entre un hyperviseur VMware et un système GNU/Linux invité. Ils sont notamment utilisés pour le partage de dossiers.

dm-cache

Une nouvelle cible du gestionnaire de correspondance de périphériques, le device-mapper, a fait son apparition : dm-cache. Il permet, par exemple, d’utiliser un disque SSD local comme cache d’un périphérique réseau. À noter que ce n’est pas ni bcache (par Google), ni EnhanceIO (issu de Facebook), ni la solution de VISA qui a été reprise, mais une nouvelle implémentation Red Hat, par Joe Thornber et Heinz Mauelshagen (concepteur de la première version de LVM).

Cette version est beaucoup plus avancée : promotion et déchéance de blocs du cache, modularisation des politiques du cache, meilleure gestion de la concurrence et de la saturation du cache, de la surveillance — monitoring —, etc. Le code est conséquent, mais il réutilise une partie de thin-provisionning, notamment pour les méta‐données.

Pour l’instant, seules deux politiques sont incluses dans le noyau : multiqueue qui gère l’écriture dans le cache en écriture différée — writeback — et écriture immédiate — writethrough —, et cleaner qui permet de nettoyer progressivement tous les blocs modifiés — dirty blocks — via une écriture différée. Il suffit de basculer la politique d’un volume vers cleaner pour synchroniser le cache vers le disque original.

LVM ne sait pas encore tirer parti de cette nouvelle cible, mais vous pouvez déjà la tester avec dmsetup.

Autres nouveautés

Un peu anecdotique peut‐être en 2013, mais toujours sympathique : les pilotes libata prennent dorénavant en charge ZPODD — zero power optical device drives —, afin que les lecteurs de disques optiques compatibles ne consomment quasiment aucune énergie lorsqu’ils ne contiennent aucun disque.

La (dé)compression LZO est dorénavant bien plus rapide, le code du noyau ayant intégré les derniers développements en la matière, qui tirent parti au mieux des architectures récentes (x86 comme ARM).

Les développeurs ne baissent pas les bras et continuent de tenter de dompter les fonctions de gestion de l’énergie ASPM de nos systèmes (on se souvient des difficultés rencontrées récemment à ce sujet).

Signalons également que les processeurs Synopsys ARC qui équipent des SoC que l’on retrouve dans de nombreux produits électroniques grand public, comme les boîtiers TV, sont désormais pris en charge, tout comme les puces NFC MicroRead d’Inside Secure, et les puces Wi‐Fi de la série 7000 qu’Intel devrait commercialiser dans les prochains mois (peut‐être en association avec les processeurs Haswell).

Enfin, du côté des SoC ARM, la prise en charge du cœur processeur graphique ARM du Tegra s’est améliorée, avec l’ajout de la prise en charge des planes (sorte de compositeur matériel), de la synchronisation verticale et du basculement de page (page flipping).

The cgroup controller for regulating disk read and write speeds now correctly supports hierarchical control groups where CFQ is used as the I/O scheduler. This does not yet apply to I/O throttling, however (1, 2 and others).

Changes to the kernel’s memory management can reduce latencies produced by “stable pages” (1 and others). Since Linux 3.0, stable pages protect data already delivered to the kernel for writing but not yet written from further modification. This is important for processes such as checksum calculation and filesystem‐implemented compression. More detail can be found in this LWN.net article.

  Source : H-online

Statistiques

En ce qui concerne les statistiques du cycle de développement du noyau 3.9, le site LWN.net a publié son traditionnel article récapitulatif.
En termes de modifications, le total s’établit à 11 802 au 21 avril, alors qu’il était de 12 394 pour le noyau précédent (le record absolu). Le point notable de ce cycle 3.9 est que le record du nombre de développeurs différents a été battu, puisqu’il s’établit à 1 364.

Les contributeurs les plus prolifiques sont Takashi Iwai, qui a écrit 265 modifications pour améliorer les pilotes de son de la couche ALSA, et H. Hartley Sweeten et ses 259 modifs portant sur le nettoyage du sous‐système Comedi (périphériques d’acquisition de données).
En termes de lignes de code, c’est Paul Gortmaker qui remporte la timbale avec 34 927 lignes modifiées. Paul s’est concentré sur la suppression de plusieurs pilotes réseau obsolètes, et le noyau s’est allégé de plus de 34 000 lignes suite à ce nettoyage de printemps.

Si l’on regarde le classement des entreprises, on constate que Red Hat a cédé sa première place au profit d’Intel (1 050 modifications contre 1 185). C’est la première fois que la firme de Santa Clara s’empare ainsi de la tête du classement, et cela démontre sa détermination à fournir des pilotes libres pour toutes ses lignes de produits.

Enfin, pour ceux qui s’intéressent au développement à long terme du noyau, on peut noter que Jonathan Corbet, le fondateur du site LWN.org, a donné sa traditionnelle conférence Linux Weather Forecast lors du sommet 2013 de la Fondation Linux. La vidéo est fort intéressante, puisqu’elle propose une rétrospective sur un an (depuis le noyau 3.3, en mars 2012).
Sur cette période d’à peine un an, ce sont plus de 68 000 modifications qui ont été intégrées et 3 172 développeurs différents qui ont participé à l’évolution de Linux. En résumé, il n’y a pas d’inquiétude à avoir quant au rythme d’évolution !

  • # Perforation

    Posté par . Évalué à  10 .

    Pour ceux, comme moi, qui se demandent à quoi sert la "perforation", citée en RC-1 (si j'ai bien compris le lien) : il semble que cela permette de libérer une zone dans un fichier, mais sans que cela n'influe sur la taille du fichier.
    À quoi cela sert-il ? Un commentaire prend pour exemple le cas d'un OS virtualisé, à qui on a attribué 8Go (représenté dans l'OS hôte par un fichier de même taille).
    Lorsque une suppression de données par l'OS virtualisé a lieu, la perforation, au niveau de l'OS hôte, permet de libérer les clusters qui contiennent lesdites données, mais tout en les laissant associés au fichier de 8Go.

  • # nouveauté pour l'utilisateur desktop ?

    Posté par . Évalué à  10 .

    J'ai l'impression que plus cela va et moins, il y a de nouveauté qui concerne directement les utilisateurs bureautiques. Il y a des nouvelles pour les architectures embarqués, pour les serveurs, l'usage réseau avancé.

    J'en viens presque à regretter les débats enflammés concernant les schedulers IO ou process. J'ai l'impression aussi que certaines avancés noyaux auraient besoin d'application user-space "sérieuse" pour être correctement exploité (fonctionnalité de btrfs, netfilter, cgroups, etc…). Et que ce n'est pas encore le cas.

    Qu'en pensez-vous ?

    "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

    • [^] # Re: nouveauté pour l'utilisateur desktop ?

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

      A mon avis le fait que ça se calme au niveau du noyau est plutôt une bonne nouvelle. C'est ce qui va permettre aux gens qui développent en user-space de travailler, justement, puisqu'ils sauront quelle technologie utiliser, avec un certain espoir que tout ne change pas trois mois plus tard.

    • [^] # Re: nouveauté pour l'utilisateur desktop ?

      Posté par . Évalué à  2 .

      J'ai l'impression aussi que certaines avancés noyaux auraient besoin d'application user-space "sérieuse" pour être correctement exploité (fonctionnalité de btrfs, netfilter, cgroups, etc…). Et que ce n'est pas encore le cas.

      Les dites applications utiliseraient des fonctionnalités non portables et se feraient dégommer à vue…

      Ca bouge la où les gens on des besoins suffisamment marqués pour payer des devs noyaux. Pour l'instant professionnellement tout le monde se fou du desktop au sens historique, il ne reste donc actuellement que des hobbyists pour faire ca. Et l'histoire à un peu montré que si tu voulais pousser des gros trucs il fallait être solide et soutenu, cf. CK. Ca marche déjà suffisamment bien pour que ca ne bouge plus, game over.

      • [^] # Re: nouveauté pour l'utilisateur desktop ?

        Posté par . Évalué à  -10 .

        Donc on réinstalle Windows sur nos machines ? ;-)

      • [^] # Re: nouveauté pour l'utilisateur desktop ?

        Posté par . Évalué à  3 .

        Il y a pourtant pas mal de fonctionnalité sympa qui aurait du sens dans plusieurs catégories : comme le copy-on-write pour le système de fichiers pour éviter que les fichiers en double prennent plus de place et pour faciliter l'usage de de lib statique plus rapide que les lib dynamique (pour économiser de la ram), la migration de processus pourrait être intéressant pour lancer un application sur machine à migrer sur une autre de façon native (gestion de panne, envois sur un server pour avoir plus de puissance de calcul, etc…).

        Il pourrait faire en sorte que les forks soient plus rapide (~1000/s pour des machine ghz, c'est pas beaucoup), etc…

        "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

        • [^] # Re: nouveauté pour l'utilisateur desktop ?

          Posté par . Évalué à  3 .

          Je ne dis absolument pas qu'il n'y a rien à faire. Je dis que pour les besoins actuels, avec les machines actuelles, ca marche suffisamment bien pour que ca vivote sans plus. Le coût de dev ne serait pas rentabilisé.

          Après pour le côté desktop, l'user-land rame aussi derrière les avancés noyaux pour des raisons de portabilité. Quand tu fais un soft tu veux pas dépendre de btrfs ou de tel syscall ou interface, tu vises le plus large possible (et quand tu ne le fais pas on t'insulte pendant quelques années). La seul exception étant les softs internes qui ont de gros besoin de performance et ou on maîtrise toute la chaîne. Mais on en revient aux serveurs. Bref on tourne en rond.

        • [^] # Re: nouveauté pour l'utilisateur desktop ?

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

          pour faciliter l'usage de de lib statique plus rapide que les lib dynamique (pour économiser de la ram)

          Peux-tu élaborer ?

          • [^] # Re: nouveauté pour l'utilisateur desktop ?

            Posté par . Évalué à  1 .

            Les distrib linux utilisent un tout cohérent de lib de soft qui les utilise. Linux sait mutualiser les accès à la même lib. Le problème est de construire un tout cohérent, une distribution.

            Il est dans l'air de faire du partage de page de code identique issue de lib compilée en statique, le but serait de faire un dépot générique de logiciel Linux, qui ne dépendent pas de la version des libs installées (ou de la version du compilo). Cette fonctionnalité permet de réduire l'empreinte mémoire, tout en ayant un mécanisme de distribution de logiciel généraliste.

            On pourrait imaginer un concept de store indépendant des distributions, ou encore que chaque projet propose son logiciel en download.

            "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

            • [^] # Re: nouveauté pour l'utilisateur desktop ?

              Posté par . Évalué à  4 .

              C'est ce que fait stali.

              Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

              • [^] # Re: nouveauté pour l'utilisateur desktop ?

                Posté par . Évalué à  5 .

                C'est ce que fait stali.

                J'aurais plutôt dit « c'est l'objectif de stali ».

                Stali est un projet intéressant, mais ni actif ni abouti. Il n'apparait pas dans les dépôts de suckless. La nouvelle la plus récente que j'ai pu trouver à ce sujet est ici. L'image proposée en téléchargement date de 2009.

                Je cite la « roadmap » de 2010 :

                Prio 1: userland (nearly finished, expect early April)
                Prio 2: complete system (expect late April)

                Pas tenue, donc. Apparemment, ils ne peuvent pas travailler dessus, et stali est encore un projet plus qu'une distribution. Ce qui est dommage, je trouve, parce que j'aime bien ce que fait suckless, et que je serais curieux de ce que ça donnerais si ce projet aboutissait.

                Mais peut-être que d'en parler va donner envie à certain d'aller proposer de l'aide ? ;-)

            • [^] # Re: nouveauté pour l'utilisateur desktop ?

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

              J'avais compris que tu disais que le copy on write allait aider dans ce cas.
              Mais je ne vois pas comment ça peux aider.

              Les libs compilée statiquement ne sont par définition pas partagée.

              • [^] # Re: nouveauté pour l'utilisateur desktop ?

                Posté par . Évalué à  0 .

                En fait, c'est un peu plus que le copy-on-write, c'est le système utilisé pour économiser la mémoire des VM. Il s'agit de partager les pages mémoires ayant un contenu identique. C'est le contenu qui sert d'adressage pour détecter des pages identiques. Cela arrive avec les libs statiques.

                "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

                • [^] # Re: nouveauté pour l'utilisateur desktop ?

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

                  Je ne crois pas. Quand une bibliothèque est liée statiquement a un exécutable, seul les fonctions utilisées sont incorporées. Et puis la résolution des adresses sera différente. Même en position independent code il y aura des décalages. Donc en gros, je ne sais pas si des pages pourront être partagées.

                  • [^] # Re: nouveauté pour l'utilisateur desktop ?

                    Posté par . Évalué à  0 .

                    "seul les fonctions utilisées sont incorporées."

                    C'est très récent que les linkers optimisent les symboles non utilisés. Avant, il ne faisait rien du tout. Je serais même curieux de voir si ils font quoi que ce soit niveau optimisation d'un ".a".

                    "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

                    • [^] # Re: nouveauté pour l'utilisateur desktop ?

                      Posté par . Évalué à  6 .

                      C'est très récent que les linkers optimisent les symboles non utilisés.

                      C´est le B.A.BA de l´édition de lien statique, même. Tous les éditeurs de liens que j´ai croisés savent faire ça : seuls les symboles utilisés sont liés.

                      Je serais même curieux de voir si ils font quoi que ce soit niveau optimisation d'un ".a"

                      Normal qu´ils ne fassent rien (de plus) : un .a ce n´est qu´une collection de .o. Une archive de .o comme un tarball, mais sous un format différent.

                      Hop,
                      Moi.

                      • [^] # Re: nouveauté pour l'utilisateur desktop ?

                        Posté par . Évalué à  0 .

                        Cela fait longtemps que je n'ai pas fait de test, mais je crois que tu te trompes. Les linkers qui font le ménages, c'est nouveau (gold pour gcc, de mémoire).

                        "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

                        • [^] # Re: nouveauté pour l'utilisateur desktop ?

                          Posté par . Évalué à  9 .

                          Les linkers qui ne prennent que ce qu'il faut dans une bibliothèque statique, ça existe depuis des lustres. Autrement un bête HelloWorld compilé en gcc -static ferait un binaire de plusieurs méga.

                          Par contre les linkers qui font le ménages dans les .o pour un binaire final c'est un peu plus récent.

                        • [^] # Re: nouveauté pour l'utilisateur desktop ?

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

                          Quand bien même on activerait aucune optimisation (et ce serait bien dommage), le linkeur fait toujours les relocations qui rendent le partage difficile voir impossible.

                        • [^] # Re: nouveauté pour l'utilisateur desktop ?

                          Posté par . Évalué à  7 .

                          Les linkers qui font le ménages, c'est nouveau.

                          Oh que non. À l´édition de lien, tous les symboles nécessaires, et seulement les symboles nécessaires, qui viennent de .o ou de .a sont /tirés/ vers le binaire final. Ça a toujours été le cas. Le premier éditeur de liens que j´ai utilisé (quelque chose comme en 1990?) le faisait déjà.

                          Tu peux faire le test : installe une vielle distro (genre une slack des années 90, facile aujourd´hui dans une machine virtuelle), génère un librairie statique énorme (genre quelques Mebioctets), et fait un petit programme simple qui se contente d´appeler un et un seul symbole de cette librairie, et lie le en statique : tu verras qu´il ne fait pas la taille de ta librairie.

                          gold pour gcc

                          gold est un éditeur de liens ; gcc est (un peu plus qu´)un compilateur. gold, c´est binutils, pas gcc.

                          Hop,
                          Moi.

                        • [^] # Re: nouveauté pour l'utilisateur desktop ?

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

                          Ca va dépendre sans doute de ce que tu appelles "nouveau", mais de mon point de vue 10 ans (pour Visual Studio, de mémoire c'est dans mini Visual Studio 2003 qu'on a ça) c'est une éternité en informatique, après pour les trucs à la bourre de chez bourre genre GCC avec gold en 2008 (et le Link Time Optimization en 2009 encore de mémoire), à voir si 4-5 ans c'est "nouveau". Même une RHEL/CentOS (le truc utilisé qui change le moins en Linux) est sortie entre temps.

                        • [^] # Re: nouveauté pour l'utilisateur desktop ?

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

                          Au boulot j'ai un gcc 2.8.1 (mars 1998) avec lequel on compile en statique (pas le choix, GNAT 3.14 ne savait pas encore faire des bibliothèques dynamiques) et j'avais tenté l'expérience : il fait bien le tri des symboles utilisés par le programme.

      • [^] # Re: nouveauté pour l'utilisateur desktop ?

        Posté par . Évalué à  6 .

        Les dites applications utiliseraient des fonctionnalités non portables et se feraient dégommer à vue…

        Oh, allez…. c'est pas comme si on pouvait pas parler de systemd sans déclencher un troll quand même si?

      • [^] # Re: nouveauté pour l'utilisateur desktop ?

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

        Les dites applications utiliseraient des fonctionnalités non portables et se feraient dégommer à vue…

        Ça me fait penser à un OS proprio qui s'interdisait d'innover pendant des années pour garder la compatibilité avec les anciennes applis 32, euh, 16, euh 8bit.

        Sauf que là, on parle de code open source. Donc, si systemd, puisqu'on parle de lui, ne tourne pas sur d'autres OS, c'est juste une question de manpower, pas de droit ou de manque d'accès au code source.

        Et donc, pour moi, je trouve vraiment contre-productif et infondé la volonté de certains de rester sur des systèmes bourrés de hack, pas adaptés aux usages d'aujourd'hui, juste parce que "ça me sert pas, j'ai pas envie de comprendre et donc c'est nul".

        Oui, vive Gnome 3, vive systemd :)

        (Je ne monte plus mes clés usb à la main, je ne charge plus mes pilotes à la main, je sélectionne mon réseau wifi dans une belle gui avec des jolies zicones, et j'ai pas l'impression d'être plus débile ou d'avoir régressé dans ma quête d'un OS libre)

    • [^] # Re: nouveauté pour l'utilisateur desktop ?

      Posté par . Évalué à  7 .

      J'en viens presque à regretter les débats enflammés concernant les schedulers IO ou process

      Pour ma part, le BFS et le BFQ évitent à ma machine (et à d'autres) d'avoir :
      - un CPU sous utilisé (lors de compilations par exemple)
      - le bureau qui gèle lorsqu'il y a une forte/très moyenne charge I/O

      Vive linux-ck, en somme.

      Le BFS n'a aucune chance d'être intégré au kernel (et ck n'a pas envie de batailler à nouveau), par contre pour le BFQ je n'en sais rien.

      "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

      • [^] # Re: nouveauté pour l'utilisateur desktop ?

        Posté par . Évalué à  1 .

        Il y a juste un point qui m'intrigue dans le document que tu cites (le 2nd):

        The only way is to rewrite it to work that way, or
        to have more than one scheduler in the kernel. I don't want to do the former,
        and mainline doesn't want to do the latter.

        La dernière fois que j'ai fouillé dans les options de compilation du noyau il me semblait pourtant avoir vu plusieurs schedulers ?
        C'est pas comme si je remets en cause les dires du monsieur, vu ma compréhension (ou mon manque de compréhension plutôt) de la chose, je m'abstiens volontiers, mais j'aimerai comprendre tout de même…

        • [^] # Re: nouveauté pour l'utilisateur desktop ?

          Posté par . Évalué à  2 .

          Il y a un seul ordonnanceur de processus, le CFQ. A moins que je me trompes, mais j'en doute.

          Il y a par contre plusieurs ordonnanceurs d'entrées/sorties (CFQ, deadline, noop)

          "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

    • [^] # Re: nouveauté pour l'utilisateur desktop ?

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

      . J'ai l'impression aussi que certaines avancés noyaux auraient besoin d'application user-space "sérieuse" pour
      être correctement exploité (fonctionnalité de btrfs, netfilter, cgroups, etc…).

      Alors btrfs, y a :
      https://blogs.oracle.com/wim/entry/btrfs_root_and_yum_update

      Cgroups, y a :
      - systemd
      - lxc ( et genre les gens qui utilisent des lxc pour steam : https://www.stgraber.org/2012/11/16/running-steam-in-a-lxc-container/ )

      En fait, le souci, c'est que tout ça, ça implique d'avoir une idée du fonctionnement du système, et donc implique d'avoir un admin pour gérer les choses. Je vois à la rigueur comment on peut utiliser les cgroups et lxc pour lancer une application dans un mode de compatibilité, ça serait peut être utile sur une station bureautique. Mais ça intéresse pas les distributions, et les utilisateurs qui savent faire le font dans leur coin, et les autres savent pas donc font pas. Mais tu veux faire quoi de bureautique avec cgroups, btrfs ou iptables ?

      En fait, ça me rappelle aussi alsa et pulseaudio. Une partie des soucis de pulseaudio était due à des bugs alsa non repéré car dans du code non utilisé de cette façon avant.

      Donc oui, faudrait des trucs, et pour ça, faut juste se bouger et coder.

      • [^] # Re: nouveauté pour l'utilisateur desktop ?

        Posté par . Évalué à  0 .

        Les cgroups pourrait être décidé par la distrib pour éviter les ralentissements de gui.

        les fonctions avancés de btrfs pourrait inclus dans les gestionnaires de fichiers.

        "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

        • [^] # Re: nouveauté pour l'utilisateur desktop ?

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

          Les cgroups pourrait être décidé par la distrib pour éviter les ralentissements de gui.

          Ce n'est pas ce que permet systemd ?

          « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

          • [^] # Re: nouveauté pour l'utilisateur desktop ?

            Posté par . Évalué à  1 .

            Pas avec la même finesse, il me semble.

            "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

            • [^] # Re: nouveauté pour l'utilisateur desktop ?

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

              systemd n’utilise pas toutes les fonctionnalités des cgroups.

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

              • [^] # Re: nouveauté pour l'utilisateur desktop ?

                Posté par . Évalué à  3 .

                Le principal problème c'est que, si en effet systemd place chaque service dans un cgroup séparé, cela n'apporte pas grand chose pour un usage desktop car la plupart des applications y sont lancées dans la session utilisateur et du coup elles se retrouvent toutes dans le même cgroup (systemd-cgls pour s'en convaincre)

  • # Btrfs RAID 5

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

    Juste pour information, je suis hyper intéressé pour voir comment ça peut tourner même si je sais que c'est pas pour maintenant en production…
    Quelqu'un aurait un article qui permettrait de voir les capacités ?

  • # Raid 1 et non Raid 0

    Posté par . Évalué à  5 .

    Enfin, en cas de corruption de données sur un RAID 0, Btrfs peut se baser sur les sommes de contrôle des métadonnées pour déterminer quelle copie est valide. De même, un correctif améliore aussi les performances de fsync.

    Il n'y a pas de redondance sur un raid 0, il faut donc lire
    Enfin, en cas de corruption de données sur un RAID 1/5/6

    • [^] # Re: Raid 1 et non Raid 0

      Posté par . Évalué à  1 .

      Il n'y a pas de redondance sur un raid 0, il faut donc lire
      Enfin, en cas de corruption de données sur un RAID 1/5/6 …

      Les fichiers ne sont pas dupliqués sur les RAID 5/6, il faut donc lire :
      Enfin, en cas de corruption de données sur un RAID 1…

      • [^] # Re: Raid 1 et non Raid 0

        Posté par . Évalué à  4 .

        redondance n'implique pas duplication.

        un code correcteur d'erreur a des information redondantes, et pourtant il ne duplique pas les données.

  • # Liste des matériels supportés

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

    C'est peut-être hors sujet, mais y a t'il un site qui recense le matériel supporté en plus pour chaque version du noyaux ?

    C'est un truc qui me bloque pour réinstaller un Linux hors VM sur ma machine, le driver réseau est pas dans le noyaux et sur des distribs genre fedora qui met à jour le noyaux régulièrement, c'est pas une solution de devoir recompiler un pilote externe.

    Sinon oui, il y a de moins en moins d'avancée orientée pour le desktop (à par les pilotes graphiques). Mais la vraie question, c'est plutôt qu'est-ce que peux faire le noyaux pour impacter un système desktop à part améliorer la gestion des ressources ?

    • [^] # Re: Liste des matériels supportés

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

      le driver réseau est pas dans le noyaux et sur des distribs genre fedora qui met à jour le noyaux
      régulièrement, c'est pas une solution de devoir recompiler un pilote externe

      Comment dire? Connais-tu les distributions type Mageia et Debian qui intègrent la recompilation à la volée des pilotes lors d'une mise à jour du noyau?

      ⚓ À g'Auch TOUTE! http://agauch.fr

    • [^] # Re: Liste des matériels supportés

      Posté par . Évalué à  4 .

      C'est peut-être hors sujet, mais y a t'il un site qui recense le matériel supporté en plus pour chaque version du noyaux ?

      Il y a le site KernelNewbies (c'est un peu l'équivalent anglophone de ces dépêches linuxfr) : http://kernelnewbies.org/Linux_3.9_DriverArch
      (la page ne semble pas encore très à jour mais tu peux naviguer dans les anciennes versions tu verras que c'est très complet).

      • [^] # Re: Liste des matériels supportés

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

        Ah merci, c'est exactement quelque chose du genre que je cherchais.

        Pour mon problème de pilote, c'est un truc qu'il est pas dans les dépôts Fedora, donc ça devient moins marrant à maintenir à la main, surtout si on à pas vu que y a une mise à jour du noyaux, on se retrouve.. sans net. J'ai rien contre les distribs qui mettent à jour toutes seules comme ça, juste que j'ai plus le temps de m'embêter à configurer mon système.

    • [^] # Re: Liste des matériels supportés

      Posté par . Évalué à  1 .

      ça ne concerne que le pci :
      http://kmuto.jp/debian/hcl/

    • [^] # Re: Liste des matériels supportés

      Posté par . Évalué à  5 .

      Si c'est un PC fixe, une petite carte réseau à 5€ devrait faire l'affaire :)
      Sinon je suis curieux de connaitre la référence de ta carte, c'est quand même très rare.
      Comme l'ont dit certains il y a DKMS qui peut piloter la compilation d'un module après une mise à jour du kernel. C'est ce que font les modules akmod sur Fedora.

  • # LZO

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

    Sur l'amélioration du code de l'algorithme LZO c'est quand même très impressionnant de voir les chiffres. En compression on passe de 150 Mo/sec à 434 Mo/sec et en décompression on passe de 468 Mo/sec à 1210 Mo/sec !
    Les systèmes de fichiers qui peuvent optionnellement utiliser LZO pour compresser leurs données (Btrfs par exemple) disent merci au noyau 3.9.

    • [^] # Re: LZO

      Posté par . Évalué à  2 .

      Je me demande si xz en profite ?

      Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

      • [^] # Re: LZO

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

        Non seul l'algo LZO est ainsi optimisé. C'est d'ailleurs un de ses auteurs (Markus Oberhumer, le O de LZO) qui a écrit le code.
        XZ est conçu pour atteindre de gros ratios de compression au détriment de la vitesse alors que pour LZO c'est le contraire.

        • [^] # Re: LZO

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

          Voilà, parce que LZMA ≠ LZO ;-)

          ⚓ À g'Auch TOUTE! http://agauch.fr

    • [^] # Re: LZO

      Posté par . Évalué à  3 .

      En compression on passe de 150 Mo/sec à 434 Mo/sec et en décompression on passe de 468 Mo/sec à 1210 Mo/sec !

      Ces chiffres se rapportent-ils à la quantité de données en entrée ou en sortie du traitement de compression/décompression ?
      Je suppose que c'est l'entrée, mais je souhaite être sûr de bien comprendre…

      • [^] # Re: LZO

        Posté par . Évalué à  1 .

        En entré en compression et en sortie en décompression, j'imagine.

        "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

    • [^] # Re: LZO

      Posté par . Évalué à  1 .

      En effet, superbe amélioration de LZO, mais comme on peut le voir dans la même page, il y a LZ4 qui est encore supérieur, cf http://code.google.com/p/lz4/ (comparatif intéressant avec gzip et Snappy, également).

  • # superbes statistiques

    Posté par . Évalué à  -6 .

    Merci patrick_g pour ses statistiques mises avec amour

  • # RAID dans BRTFS

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

    Je suis plus que dubitatif de ces monstres monolithiques qui font tout et le café. Pour finalement, un peu de perfs mais beaucoup d'inconvénients.

    Premièrement, la restauration est potentiellement beaucoup plus rapide, car il n’y a besoin de restaurer que les morceaux qui contiennent des données, alors qu’une couche d’abstraction est obligée de toujours restaurer le disque entier.

    Rien n'empêche d'avoir un système non-monolithique et en même temps de restaurer que ce qui est nécessaire. Il faut juste avoir à disposition, une liste des bloques utilisés. Cela impliquerait d'ajouter un méthode d'obtention de la liste au niveau des fs.

    Deuxièmement, il est possible d’avoir différents types de RAID au sein d’un même système de fichiers, comme les données en RAID 0 et les métadonnées en RAID 1.

    Idem., que précédemment mais avec 2 listes de bloques.

    Avec la méthode implémentée, il devient impossible d'utiliser ces RAIDs sur d'autre fs, du fait du caractère monolithique. Tout ce code restera cantonné à BRTFS et ne sera pas réutilisable par les autres fs.

    • [^] # Re: RAID dans BRTFS

      Posté par . Évalué à  1 .

      Séparer pour réutiliser, c'est pas mal, mais cela empêche toute optimisation du au fait que le FS dispose forcément de plus d'information que la couche VFS.

      "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

      • [^] # Re: RAID dans BRTFS

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

        L'idée serait justement d'exposer ces informations à la couche supérieure. (via de nouvelles interfaces)

        • [^] # Re: RAID dans BRTFS

          Posté par . Évalué à  6 .

          Si tu ne simplifies pas les interfaces entre les couches, tu ne fait que déverser les problèmes aux autres couches, qui ne peuvent plus les gérer.

          "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

      • [^] # Re: RAID dans BRTFS

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

        Exactement comme pour les commandes de base unix. sort, uniq, cat, |, <, >, diff … seraient plus efficace si chacun de ces outils étaient dédiés à un seul format de fichier et que les communications n'étaient pas des flux non formatés mais structurés. Ils seraient également tellement plus efficace de faire une de fusionner sort, uniq, cat et la gestion des flux pour faire un bon gros mmap des bois.

        Mais ils seraient tellement moins utiles, tellement moins importants, tellement moins des briques de base et il faudrait les re-développer pour tous les cas.

        Et tout ça pourquoi ? Un peu de perfs.

        • [^] # Re: RAID dans BRTFS

          Posté par . Évalué à  2 .

          C'est exactement ça, un peu de perf (économie de machine, d'énergie). Mais aussi de simplification de design (systemd ?).

          Une fois que les couches s'empilent, on ne peut plus parler de simplification.

          "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

          • [^] # Re: RAID dans BRTFS

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

            Elles ne s'empilent pas. Ce sont des composants séparé. C'est un self-service : tu n'utilises que ce dont tu as besoin. Pas de raid et bien pas de code pour. Pas de snapshots, et bien pas de code pour. Il n'y a absolument pas de fortes dépendances entres ces composants. Tu peux, par exemple, très bien vouloir utiliser du raid sans FS (il y a pleins de raisons à ça).

            C'est dans le monolithique que cela s'empile. Tu embarques tout en permanence.

            • [^] # Re: RAID dans BRTFS

              Posté par . Évalué à  3 . Dernière modification : le 30/04/13 à 11:19

              Parce que dans 90% des cas, tu en as besoin. Sur ta pile, si tu commences à sortir de la pile "habituelle", tu peux avoir un paquet d'ennuis aussi. Il y a aussi des fonctionnalités non utilisé ou mal transmis. C'était le cas du trim, par exemple.

              Regarde l'état des autotools, des piles de soft dont plus personne ne comprends plus rien, mais qui fonctionnent mais n'évolue plus.

              Pareil pour le système de démarage standard unix, dont chaque distrib faisait sa tambouille qui était lent.

              "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

        • [^] # Re: RAID dans BRTFS

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

          faire une de fusionner sort, uniq, cat et la gestion des flux pour faire un bon gros mmap des bois

          tu veux dire perl ?

          ou tu parles de sort -u peut être ?

          Ou peut être de busybox ( busybox étant le shell le plus distribué au monde, merci android ) ?

          Mais ils seraient tellement moins utiles, tellement moins importants, tellement moins des briques de base et
          il faudrait les re-développer pour tous les cas.
          Et tout ça pourquoi ? Un peu de perfs.

          Et c'est pour ça que tout le monde code en bash/sh/ksh/zsh, car les perfs, ça sert tellement à rien :)

          • [^] # Re: RAID dans BRTFS

            Posté par . Évalué à  2 . Dernière modification : le 30/04/13 à 11:58

            D'ailleurs, c'est marrant les techno java. Ils font un langage simplifié pour aider au développement, puis un IDE qui fait le café (eclipse). Puis, il ajoute une couche d'abstraction (les EMF), qui génère du code par dessus. Ensuite, il greffent un tas d'outils de gestion (les MDT).

            De loin, la pile n'a pas l'air si belle. Faire de l’introspection et des bibliothèques n'auraient pas été plus simple ?

            "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

            • [^] # Re: RAID dans BRTFS

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

              On ne parle pas de couche d'abstraction mais d'outils indépendant discutant entre eux.

              Je trouve le modèle de java pourri, également. Mais cela n'a rien à voir.

              • [^] # Re: RAID dans BRTFS

                Posté par . Évalué à  1 .

                C'est pareil. Sauf que dans ton cas, tu pense à des outils en ligne de commande.

                "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

          • [^] # Re: RAID dans BRTFS

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

            Ou peut être de busybox ( busybox étant le shell le plus distribué au monde, merci android ) ?

            Jusqu'à présent, les outils fournis par busybox sont toujours modulables et réutilisables par d'autres. Ici, ce n'est pas le cas. Je peux toujours faire un « sort | monprogramme ».

            Est-ce que ext4/fat va pouvoir réutiliser les systèmes de raid, snapshots et … ?

            Et c'est pour ça que tout le monde code en bash/sh/ksh/zsh, car les perfs, ça sert tellement à rien :)

            1) J'ai dit un peu de perfs. Entre bash et C, il y a beaucoup de perfs.
            2) Ce que tu me dis c'est : je peux couper des pommes avec un canif, pourquoi ne pas couper un chêne avec ? Rien à voir avec ce dont on parle.

            Il faut comparer le comparable. Je suis pour l'utilisation du bon langage pour la bonne chose.

            • [^] # Re: RAID dans BRTFS

              Posté par . Évalué à  5 . Dernière modification : le 30/04/13 à 12:19

              "Est-ce que ext4/fat va pouvoir réutiliser les systèmes de raid, snapshots et … ?"

              Non et alors ? Est-ce que je peux faire des regexp perl avec bash ?

              Et il n'est pas question d'un peu de perf, quand la reconstruction d'un raid peut prendre plusieurs dizaine d'heure.

              "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

              • [^] # Re: RAID dans BRTFS

                Posté par (page perso) . Évalué à  4 . Dernière modification : le 30/04/13 à 22:09

                Comparé à ce que je dis dans le premier commentaire c'est très peu de différence de perf. La restauration d'un raid est dominée par les accès disques et principalement par les données en elle-mêmes. Avec une liste des bloques exposée par les fs (de façon optionnelle si pas implémenté, on fallback sur l'actuel), on garde les avantages des 2 cotés :

                • On ne restaure que les bloques utilisés
                • On garde l'orthogonalité : d'autres fs peuvent utiliser le raid et le code n'est pas dupliqué dans le noyau
                • La perf perdue est négligeable par rapport aux accès disques

                Rappel : Sous linux, le temps processeur est négligeable grâce à un encoding astucieux. Un raid avec un simple disque de parité est un simple xor des autres. Un raid avec 2 disques de parité est donné par le xor pour le premier disque et 1 D_1 + 2 D_2 + 22 D_3 + \ldots + 2{n-1} D_n (Je ne sais pourquoi le moteur ne veut pas de mon image). Donc, tout se calcule très facilement dans le champ fini GF(28) (Dans lequel, les opérations +/* sont très efficaces). Juste des XOR est des shifts et tout reste linéaire par rapport au nombre de disques. Donc, c'est très limité au niveau cpu cfr. The mathematics of RAID-6.

                • [^] # Re: RAID dans BRTFS

                  Posté par . Évalué à  1 .

                  La correction d'erreur à ce niveau n'a pas d'intérêt, vu que chaque disque en est blindé. De mémoire, pour un secteur de 4k, il y a bien 1k de code correcteur.

                  Le problème de ton approche est de savoir d’où tu sors ta liste de secteur utilisé. Est-ce que le fs doit parcourir tout le disque pour les trouver ? Que faire en cas d'erreur ?

                  "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

                  • [^] # Re: RAID dans BRTFS

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

                    La correction d'erreur à ce niveau n'a pas d'intérêt, vu que chaque disque en est blindé. De mémoire, pour un secteur de 4k, il y a bien 1k de code correcteur.

                    Les bras m'en tombe o Dans RAID, il y a R comme Redundant. Les erasures codes sont la méthode utilisée pour restaurer en cas de défaillance. Ce sont des codes correcteurs sur un canal avec effacement (pas de corruption, juste la perte de donnée).

                    Je t'ai donné le lien vers les mathématiques de ces codes, tu n'as pas besoin de bien te souvenir : juste de lire.

                    Le problème de ton approche est de savoir d’où tu sors ta liste de secteur utilisé. Est-ce que le fs doit parcourir tout le disque pour les trouver ? Que faire en cas d'erreur ?

                    Comment fais-tu dans la version monolithique ? C'est le même avec une interface entre les deux.

                    • [^] # Re: RAID dans BRTFS

                      Posté par . Évalué à  1 .

                      Ton code est du Reed-Solomon. Il n'a rien d'extraordinaire.

                      "Comment fais-tu dans la version monolithique ? C'est le même avec une interface entre les deux."

                      Pas vraiment, car la façon de corriger peut venir de multiple endroit, selon la données contenu.

                      "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

                      • [^] # Re: RAID dans BRTFS

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

                        Ton Le code du noyau est du Reed-Solomon . Il n'a rien d'extraordinaire. et est optimisé intelligemment pour le cas avec 2 disques

                        mmh

                        Pas vraiment, car la façon de corriger peut venir de multiple endroit, selon la données contenu.

                        Tu peux traduire ?

                        • [^] # Re: RAID dans BRTFS

                          Posté par . Évalué à  1 .

                          Ton cluster à corriger peut être une meta data ou un contenu de fichier. Une meta data peut être un truc dupliqué, peut être recalculer facilement ou être protégé par un code ECC. Le fichier peut avoir un statut différente (fichier courant, snapshot, fichier "effacé" dont se fout des erreurs).

                          "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

                          • [^] # Re: RAID dans BRTFS

                            Posté par (page perso) . Évalué à  2 . Dernière modification : le 02/05/13 à 15:14

                            Ce n'est toujours pas plus clair.

                            Un raid c'est à la louche (n data + k redondance):

                             --------   --------     --------   ------------     ------------
                            | Disk_1 | | Disk_2 |...| Disk_n | |  Disk_n+1  |...| disk_n+k   |
                             --------   --------     --------   ------------     ------------
                            | Data   | | Data   |   | Data   | | Redondance |   | Redondance |
                             --------   --------     --------   ------------     ------------
                            
                            

                            Le tout étant découpé en bloques et donc réparable par bloques. Très fréquemment, le code correcteur est divisé en 2 parties :

                            • Un code à effacement MDS, souvent limité à k = 2 (donc, 2 pannes tolérées - comme pour le code de linux) ;
                            • Un code de détection des erreurs (crc, md5, sha, …).

                            Au-dessus de cette structure vue comme un seul device, on met un fs. Ce dont je parle c'est de mettre en place un mécanisme d'échange d'information entre

                            • le FS : qui a connaissance des bloques utilisés
                            • le RAID : qui gère la réplication/correction/détection

                            Le RAID pour limiter les reconstructions peut utiliser l'information des bloques utilisé par le FS et faire son boulot que sur ceux-ci. C'est exactement la même source d'info que dans le cas, j'ai « un FS qui fait le café ». Ce qui change c'est :

                            • La méthode de communication
                            • L'orthogonalité préservée (Code réutilisable par différents FS moyennant modification mineure et optionnelle)
                            • [^] # Re: RAID dans BRTFS

                              Posté par . Évalué à  1 .

                              Non, ce n'est pas la même chose du tout.

                              Une meta data peut être un truc dupliqué, en cas d'erreur on récupère une des copies -> pas de bloc dupliqué.
                              Une meta-data peut être recalculer facilement -> un groupe d'offset faux est recalculer à la voler, genre un mini fsck -> pas de duplication type RAID

                              Un bloc est très important, il est protégé par un code ECC -> comme pour le raid6, la donné est stocké sur un autre disque.

                              Le fichier peut avoir un statut différent :
                              *fichier courant -> traitement type raid,
                              * snapshot -> si on a une sauvegarde, on peut s'en foutre : duplication sur l'autre disque avec compression par exemple ?
                              *fichier "effacé" dont se fout des erreurs -> aucune correction, juste un flag qui dit que le code est faux.

                              "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

                            • [^] # Re: RAID dans BRTFS

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

                              A une époque, il y a eu ENBD, une amélioration de NBD permettant de faire du RAID1 sur le réseau. La problématique de la reconstruction rapide a alors été prise en compte via un driver noyau fr1.

                              http://enbd.sourceforge.net/

                              Tout cela date un peu mais reste intéressant à connaître.

                  • [^] # Re: RAID dans BRTFS

                    Posté par . Évalué à  4 .

                    La correction d'erreur à ce niveau n'a pas d'intérêt, vu que chaque disque en est blindé. De mémoire, pour un secteur de 4k, il y a bien 1k de code correcteur.

                    Tu te trompes, la taille atteinte par les disques actuels est telle que même la correction d'erreur intégrée au disque (qui garanti un taux d'environ 10-15) n'arrive pas à garantir l'absence d'erreur. C'est pour cela, tout à fait indépendamment de l'utilisation de RAID, que ZFS effectue les checksums de tout ce qui est écrit sur disque. Et je connais un utilisateur de ZFS en datacenter qui a vu des erreurs se produire, ce n'est pas du tout théorique.

                    • [^] # Re: RAID dans BRTFS

                      Posté par . Évalué à  2 .

                      Avec un paquet de bit en plus tu peux avoir un taux d'erreurs de 10-15 mais vu la taille des disques, cela devient probable.

                      Un checksum ne te corrige aucune erreur, il les détecte (c'est beaucoup plus léger).

                      "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

            • [^] # Re: RAID dans BRTFS

              Posté par . Évalué à  1 .

              Est-ce que ext4/fat va pouvoir réutiliser les systèmes de raid, snapshots et … ?

              man lvm
              man mdadm

          • [^] # Re: RAID dans BRTFS

            Posté par . Évalué à  3 .

            Ou peut être de busybox ( busybox étant le shell le plus distribué au monde, merci android ) ?

            Non, Android n’utilise pas busybox, c’est GPL, ça pourrait être gênant. Ils utilisent une solution maison:
            http://elinux.org/Android_Tools#busybox
            https://github.com/android/platform_system_core/tree/master/toolbox

            Cf http://www.elinux.org/Busybox_replacement_project pour voir que ça dérange les industriels le copyleft et les procès intentés par des auteurs de busybox.

            • [^] # Re: RAID dans BRTFS

              Posté par . Évalué à  0 .

              "Cf http://www.elinux.org/Busybox_replacement_project pour voir que ça dérange les industriels le copyleft et les procès intentés par des auteurs de busybox."

              On comprends que cela dérange, mais est-ce que le projet a été au bout et est de la même qualité que busybox ?

              "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

              • [^] # Re: RAID dans BRTFS

                Posté par . Évalué à  3 .

                Non, bien évidemment. La première chose à faire pour bidouiller tranquillement un système android étant d’installer son binaire busybox (comme décrit dans le lien plus haut).

    • [^] # Re: RAID dans BRTFS

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

      Le problème, c'est que seul Btrfs est développé avec ces fonctionnalités, ça n'intéresse pas les autres FS. Du coup, avoir un truc générique tout seul, ça ne sert à rien et c'est le meilleur moyen d'avoir un truc générique spécifique à un FS. Quand d'autres FS seront intéressés par ces fonctionnalités, ils se mettront peut-être d'accord sur une interface commune.

      « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

      • [^] # Re: RAID dans BRTFS

        Posté par . Évalué à  1 .

        Dans combien de temps ? Sachant que la plus part des autres FS sont en mode maintenance uniquement (ext3, reserfs, xfs,…)

        "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

        • [^] # Re: RAID dans BRTFS

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

          Dans combien de temps ? Sachant que la plus part des autres FS sont en mode maintenance uniquement (ext3, reserfs, xfs,…)

          Quand le successeur de Btrfs sortira ? (à moins qu'on ait trouvé d'autres fonctionnalités d'ici là) Ou si un concurrent débarque. Ou si ext5 arrive. Ça dépend de l'intérêt des développeurs.

          « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

          • [^] # Re: RAID dans BRTFS

            Posté par . Évalué à  3 .

            Quel intérêt attendre la sortie hypothétique d'un truc compatible avant d'utiliser ce qui existe ?

            "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

      • [^] # Re: RAID dans BRTFS

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

        Le problème, c'est que seul Btrfs est développé avec ces fonctionnalités,

        Parce que c'est le seul monolithique. Les autres ne veulent pas faire le café non plus. Les autres utilisent l'existant : lvm, md, …

        Il y a des possibilités d'amélioration dans ces outils sans faire une grosse soupe à la mode.

        • [^] # Re: RAID dans BRTFS

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

          Il y a des possibilités d'amélioration dans ces outils sans faire une grosse soupe à la mode.

          Mais personne pour les écrire, donc ça ne change rien au final.

          « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

    • [^] # Re: RAID dans BRTFS

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

      Je suis plus que dubitatif de ces monstres monolithiques qui font tout et le café.

      C'est ce que se sont dit les designers de Hurd, par exemple, face à ce gros truc horrible qu'est Linux.
      La différence entre les deux, c'est que l'un est utilisable.

      Tout ce code restera cantonné à BRTFS et ne sera pas réutilisable par les autres fs.

      Oui, mais ça marche mieux, bien mieux… Sinon ZFS a aussi réimplémenté, ce n'est pas cantonné, juste qu'il faut recoder, mais finalement le gain (perf surtout) vaut parfois le coup (et pour une fonctionnalité fichier, ça vaut le coup de mettre ça dans un système de fichier).

      J'ai eu ce genre de discussion il y a peu aussi pour ce que moi je développe, ma proposition d'intégrer dans la partie qui connait mieux comment est structuré un fichier m'avait été refusée (pas réutilisable, développement plus long etc…), et pas longtemps plus tard, voila les décideurs revenir la queue entre les jambes car les perfs de la chose "réutilisable" étaient désastreuses. Bref, la vraie vie, par exemple il vaut mieux faire du RAID dans le système de fichier, car l’optimisation du RAID a besoin de la structure des fichiers. Ce n'est pas pour rien qu'on passe d'un modèle (celui que tu aimes, c'est l'actuel) à un autre, on se rend compte que l'ancien modèle a ses limites.

      • [^] # Re: RAID dans BRTFS

        Posté par (page perso) . Évalué à  2 . Dernière modification : le 30/04/13 à 15:30

        C'est ce que se sont dit les designers de Hurd, par exemple, face à ce gros truc horrible qu'est Linux.

        1) Hurd fonctionne
        2) Je ne suis pas un extrémiste de tout en petites parties mais juste le paradigme adéquat en fonction des circonstances. À la linux justement. Linux n'est plus monolithique depuis longtemps : modules chargeables/déchargeables à la demande, fs en mode user (fuse), … Donc, finalement, ni Tanenbaum ni Torvalds n'ont perdu, ils avaient tort tous les 2 et raison en même temps.

        Ce que je pense c'est que tout mettre dans un FS est une erreur et le typique de l'optimisation prématurée. Faire du modulaire et en dévier uniquemet où c'est nécessaire me semble bien plus adéquat.

        • [^] # Re: RAID dans BRTFS

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

          optimisation prématurée

          Le RAID actuel a plus de 20 ans.
          les systèmes de fichier ont mis des plombes à intégrer la chose, ça commence à arriver.
          C'est combien de temps "non prématuré"?

          Sérieusement, tu crois que si Oracle met du RAID (et de la compression) dans ZFS, c'est pour une instabilité car prématuré? Moi je dirai que c'est parce qu'aujourd'hui le gain qu'on y a vu est plus important que ce que tu expliques, mais explique-moi, je suis intéressé, comment toi tu as raison contre les ingés d'oracle (et de btrfs maintenant).

          1) Hurd fonctionne

          Mais que personne n'utilise, car ne répond pas au besoin.

          Plus sérieusement : si des mecs s'amusent à dépenser du temps (professionnels) à changer le paradigme de 20 ans, et que celui-ci est accepté par plein de monde pour leurs besoins, c'est peut-être pas pour rien (c'est pas facile de se battre contre le conservatisme, on ne le fait pas par plaisir). Mais bon rien de nouveau (cf systemd etc…)

        • [^] # Re: RAID dans BRTFS

          Posté par . Évalué à  10 .

          Ce que tu proposes est aussi une « optimisation » prématurée. Ce n'est juste pas une optimisation de la même chose (optimiser la vitesse, optimiser la réutilisabilité). Rendre le système modulaire demande d'ajouter du code, d'installer des « hooks » pour gérer tout ça… Au final, tu complexifies le système, sous prétexte que « peut-être un jour » on aura besoin d'utiliser ça ailleurs. Un code non-modulaire peut-être plus simple (c'est ce qu'on cherche en n'optimisant pas à tout va, un code simple…).

          C'est d'ailleurs ce qui a fait le succès de Linux sur Hurd. Linus n'a pas écrit un noyau monolithique pour la vitesse. Il l'a écrit parce que c'était plus simple. Créer un micro noyaux (alors qu'il se fichait de la portabilité) aurait été une optimisation prématurée. Le code est devenu modulaire plus tard quand ils en ont eu besoin.

          • [^] # Re: RAID dans BRTFS

            Posté par (page perso) . Évalué à  -2 . Dernière modification : le 01/05/13 à 00:52

            Apparemment d'après les commentaires (Pas les miens), il y a un besoin d'augmenter les perfs. Donc, ton argumentaire ne tient pas la route. Je propose un système qui garde la simplicité au maximum sans dupliquer du code et briser la réutilisabilité (Duplication du code de lvm et du raid dans un fs - à la fois complexe et non réutilisable).

            Écrire un fs avec tout dedans est extrêmement complexe (Brtfs cela remonte à 2007, 6 ans après c'est toujours par prêt pour la prod…) et c'est ce que tu défends au nom de la simplicité ? Tu te fous de ma gueule ?

            • [^] # Re: RAID dans BRTFS

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

              Je propose un système (…)

              Tu ne proposes rien du tout, tu ne fais que papoter.
              En face, eux, ils proposent vraiment une alternative à ce qui se fait depuis 20 ans.

              C'est la différence entre la théorie et le pratique… Si tu te crois tellement supérieur à eux, il ne reste qu'une façon de prouver que tu as raison : passer de la théorie à la pratique (ça tombe bien, rien ne t’empêche de le faire, c'est libre) pour convaincre les utilisateurs que ta solution est meilleure.

              Tu te fous de ma gueule ?

              Tu nous dis la que "c'est simple" pour ta solution, pour prouver que tu ne te fous pas de notre gueule, propose les patchs, sinon j'ai du mal à voir en quoi faire des interfaces et mettre tout le monde d'accord est plus simple que de faire un truc en interne, comme ça j'imaginerai même le contraire.

              Qui se fout de la gueule de qui en balançant que les autres (qui ne sont pas des merdes in développement) sont des idiots à faire ce qu'ils font?
              C'est toujours rigolo ceux qui critiquent les idées qui ont du succès sans proposer réellement une alternative (et que cette alternative codée soit convaincante).

              • [^] # Re: RAID dans BRTFS

                Posté par . Évalué à  1 .

                En face, eux, ils proposent vraiment une alternative à ce qui se fait depuis 20 ans.

                Tu veux dire… un peu comme le Hurd ? ;)

                • [^] # Re: RAID dans BRTFS

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

                  Contrairement à Hurd, cette alternative est demandée par les utilisateurs (c'est pas des chercheurs académiques qui n'ont pas à rendre des comptes qui ont été payés pour le faire), utilisable, et utilisée (je ne connais pas les utilisateurs pour btrfs certes, mais pour le concurrent stable qu'est ZFS, ça y va bien).
                  Dans ma dernière phrase, j'avais mis "et que cette alternative codée soit convaincante", Hurd a fait sa démonstration, et n'a convaincu personne, ce qui est la différence entre la théorie (l'idée est belle) et la pratique (on code, oh et ben… Ca marche pas si bien que ça en fait).

                  Justement, l'avantage du papotage, c'est qu'on n'a pas à se confronter réellement aux utilisateurs qui vont trancher "mieux / pas mieux" donc on peut imaginer tous les avantages qu'on a envie…

                  La, c'est pas très réaliste de comparer RAID dans le FS et Hurd.

                  • [^] # Re: RAID dans BRTFS

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

                    c'est pas des chercheurs académiques qui n'ont pas à rendre des comptes qui ont été payés pour le faire

                    Phrase gratuite absolument fausse sur le domaine des sciences de l'ingénieur, branche dans laquelle je travaille. Les chercheurs passent une grosse partie de leur temps dans les évaluations X ou Y et peu d'industriel en ont conscience !

              • [^] # Re: RAID dans BRTFS

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

                Tu ne proposes rien du tout, tu ne fais que papoter.

                Ni plus ni moins que toi.

                En face, eux, ils proposent vraiment une alternative à ce qui se fait depuis 20 ans.

                A force de répéter 20 ans, tu penses que le monde va te croire ? Le raid software dans linux date de 2001. Les RAID software dans les OSes datent à peu près de la même date. Anciennement, c'était des boites dédiée (La plupart hardware). C'est seulement en 1995 que EMC a amené le premier NAS.

                Ce que je fais c'est émettre des doutes et toi, tu fais juste de l'ad-hominem : « Tu ne proposes rien du tout, tu ne fais que papoter ». Tu ne me connais pas. Et tu accuses. Mais pour ton information, j'ai écris, professionnellement, pas mal de code pour des systèmes similaires à du RAID.

                Tu nous dis la que "c'est simple" pour ta solution,

                Ce n'est pas ce que je dis (Je n'ai employé le mot simple que dans le post et dans un tout autre contexte). Je dis que je suis dubitatif.

                • [^] # Re: RAID dans BRTFS

                  Posté par (page perso) . Évalué à  3 . Dernière modification : le 01/05/13 à 11:33

                  Ni plus ni moins que toi.

                  Je parle de ce qui existe.
                  La différence est que je parle d'une chose pratique, rien de théorique.
                  Je ne fais qu'expliquer un fait, alors que toi tu imagines.

                  Désolé, c'est légèrement différent…

                  A force de répéter 20 ans, tu penses que le monde va te croire ?

                  "The term "RAID" was first defined by David Patterson, Garth A. Gibson, and Randy Katz at the University of California, Berkeley in 1987.[3]"
                  Norman Ken Ouchi at IBM was awarded a 1978 U.S. patent 4,092,732[6] titled "System for recovering data stored in failed memory unit."
                  http://en.wikipedia.org/wiki/RAID

                  Ca fait plus de 20 ans, c'est factuel (à moins que tu me dises que je ne sais pas compter?) et j'ai de la marge. Le fait que ce soit soft ou hard ne change rien au design initial, tu rajoutes une limite arbitraire pourquoi? Je ne me suis jamais limité au soft, donc j'ai du mal à suivre le pourquoi tu essaye de faire croire que je me trompe.

                  Je dis que je suis dubitatif.

                  Tu as plutôt plus que descendu l'idée, comme ça. Sans te poser la question de savoir pourquoi d'autres ne sont pas dubitatifs au point de passer du temps dessus, et avoir des utilisateurs.


                  Bref, j'essaye juste de t'expliquer pourquoi ce que d'autres font dans un monde réel que tu te plais à critiquer sans chercher à comprendre, en les traitant de nul (ou presque), et tu me dis que c'est pareil que toi? Hum…

                • [^] # Re: RAID dans BRTFS

                  Posté par . Évalué à  2 .

                  Le raid software dans linux date de 2001. Les RAID software dans les OSes datent à peu près de la même date.

                  Netware faisait du raid1 soft avant 1990 (netware v2 sft).
                  À l'époque, le backup du serveur consistait à "casser" le raid puis à rajouter un disque, ce qui était très rapide (il fallait, de mémoire, environ 2 heures pour reconstruire 1,2Go en scsi). J'aimais bien Netware pour son filesystem performant (nombreux paramètres, droits fins), fiable (mirroirs internes, tts, …) et pratique (conservation de tout ce qui est supprimé tant qu'il y a de l'espace libre) ( http://en.wikipedia.org/wiki/Novell_Storage_Services )
                  Dommage qu'il n'ai pas été "ouvert" à d'autres kernels…

                  • [^] # Re: RAID dans BRTFS

                    Posté par . Évalué à  2 .

                    À l'époque, le backup du serveur consistait à "casser" le raid puis à rajouter un disque,

                    C'est chouette pour avoir un backup avec des fichiers corrompus.

                    • [^] # Re: RAID dans BRTFS

                      Posté par . Évalué à  1 .

                      Y'avait de quoi faire un espèce "snapshot" des fichiers Btrieve utilisés.
                      Et le disque membre du raid était souvent remonté dans un serveur de test sans souci…
                      Mais je conviens que la méthode était un peu "cavalière" :-)

                • [^] # Re: RAID dans BRTFS

                  Posté par . Évalué à  2 .

                  A force de répéter 20 ans, tu penses que le monde va te croire ? Le raid software dans linux date de 2001. Les RAID software dans les OSes datent à peu près de la même date.

                  Sun Volume Manager/diskSuite existe depuis 1991

                  C'est seulement en 1995 que EMC a amené le premier NAS.

                  Perdu c'est Netapp en 1993 ( FAS400 )

        • [^] # Re: RAID dans BRTFS

          Posté par . Évalué à  1 .

          Linux n'est plus monolithique depuis longtemps : modules chargeables/déchargeables à la demande

          Ca c'est faux. La caractéristique d'un micro noyau n'est pas d'avoir des modules chargeables on demand. FUSE ça y ressemble déjà plus, mais on très très loin d'un micro-noyau. Le kernel NT est un bien meilleur exemple de noyô hybride avec les drivers en userspace.

          • [^] # Re: RAID dans BRTFS

            Posté par (page perso) . Évalué à  1 . Dernière modification : le 02/05/13 à 13:30

            N'est plus monolithique != micro noyau.

            la caractéristique d'un micro noyau n'est pas d'avoir des modules chargeables on demand.

            dilbert

            • [^] # Re: RAID dans BRTFS

              Posté par . Évalué à  2 .

              Non non j'insiste.
              Tu donnes deux raisons : la première est fausse et la deuxième est un hack immonde aux perfs désastreuses. Linux reste un bon vieux kernel monolithique monolithique avec tout le monde en ring0 avec pouvoir de nuisance maximal. Pour les kernels hybrides Torvalds/Tannenbaum compliant, il faut voir le kernel NT.

        • [^] # Re: RAID dans BRTFS

          Posté par . Évalué à  4 .

          Ce que je pense c'est que tout mettre dans un FS est une erreur et le typique de l'optimisation prématurée.

          Les concepteurs de ZFS ont choisi de virer une des couches usuelles pour n'en garder que 2, et on trouve l'explication en ligne (chercher par exemple "zfs layering violation" qui est la critique qui en a été faite). Non seulement ça a été mûrement réfléchi mais en plus les bénéfices sont clairement là, ne serait-ce que dans la simplicité d'utilisation, en plus des performances déjà mentionnées. C'est testé et approuvé en datacenter par une entreprise dans laquelle j'ai travaillé et qui n'utilise plus de contrôleurs RAID matériels, uniquement le RAID de ZFS, et qui en est très contente.

      • [^] # Re: RAID dans BRTFS

        Posté par . Évalué à  3 .

        il vaut mieux faire du RAID dans le système de fichier, car l’optimisation du RAID a besoin de la structure des fichiers. Ce n'est pas pour rien qu'on passe d'un modèle (celui que tu aimes, c'est l'actuel) à un autre, on se rend compte que l'ancien modèle a ses limites.>

        Perdu. ZFS fait du raid, mais c'est sa partie ZPool qui s'en charge.
        Pour la bonne raison que même si c'est monolithique, les couches sont toujours là.
        De plus, le coté "FS" est optionnel sur ZFS, car au contraire de BTRFS, il peut fournir des volumes "block".

    • [^] # Re: RAID dans BRTFS

      Posté par . Évalué à  1 .

      Faire quelque chose de modulaire c'est à mon humble avis très compliqué. Surtout quand il n'y a aucune alternative. C'est ce que l'on voit avec systemd. Ils tentent de créer des API pour réduire le couplage mais au final comme seul systemd est intéressé ces API sont très orientés vers lui. Commencer à proposer de nouvelles interfaces pour se rendre compte qu'elles sont pourries dès qu'on veut les utiliser ailleurs ne me semble pas être un gros gain.

      Pour ce qui est de la réutilisation, il n'est pas nécessaire de travailler avec des couches pour faire ça, la majorité du code de gestion de volume pourrait être gérée via une bibliothèque statique (je ne sais pas si c'est le cas), ça permet au FS qui le souhaite de s'en servir.

      Je crois qu'une partie du RAID de btrfs s'appuie sur les sommes de contrôles qu'il effectue ça exclus de facto tout les autres systèmes de fichiers de linux.

      Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

  • # Prise en charge des Tegra

    Posté par . Évalué à  2 .

    J'ai une question à propos de la prise en charge des Tegra : d'après cette dépêche et celle sur les puces graphiques, celle-ci s'améliore.
    Donc est-ce que cela veut dire qu'à terme, cela remplacera efficacement le driver binaire de Nvidia ?

    Dans mon cas, j'ai un LG Optimus 2X avec un Tegra 2. J'en suis très content, seulement le suivi de LG sur ses téléphones (alors que c'était son fer de lance, premier smartphone dual-core, Guiness Book…) est catastrophique. Il a fallu un an pour avoir Android 4.0 ; CyanogenMod l'avait déjà porté depuis longtemps, mais sans l'accélération matérielle impossible de lire et enregistrer des vidéos.
    Dès que LG a sorti la 4.0.4, Cyanogen a sorti 2 jours plus tard la 4.1.X, et aujourd'hui je profite de la 4.2.2.
    Donc ma principale inquiétude vient que si Google sort Android 5.0 (apparemment ils sont sur la 4.3 actuellement), mon téléphone n'en profitera jamais à cause d'un problème de driver, alors que sur le papier il sera encore dans la course.

Suivre le flux des commentaires

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