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
- Le détail des nouveautés
- Statistiques
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
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 !
Aller plus loin
- KernelNewbies 3.9 (667 clics)
# Perforation
Posté par windu.2b . É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.
[^] # Re: Perforation
Posté par xunfr . Évalué à 5.
juste pour info, la dépêche sur la version 3.7 en parlait rapidement:
https://linuxfr.org/news/sortie-du-noyau-linux-3-7#toc_24
Sinon merci pour l'explication.
[^] # Re: Perforation
Posté par patrick_g (site web personnel) . Évalué à 7.
C'était également expliqué sur la news du 2.6.38.
# nouveauté pour l'utilisateur desktop ?
Posté par Nicolas Boulay (site web personnel) . É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 première sécurité est la liberté"
[^] # Re: nouveauté pour l'utilisateur desktop ?
Posté par JoeltheLion (site web personnel) . É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 ckyl . Évalué à 2.
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 gpe . Évalué à -10.
Donc on réinstalle Windows sur nos machines ? ;-)
[^] # Re: nouveauté pour l'utilisateur desktop ?
Posté par Nicolas Boulay (site web personnel) . É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 première sécurité est la liberté"
[^] # Re: nouveauté pour l'utilisateur desktop ?
Posté par ckyl . É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
btrfsou 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 Gof (site web personnel) . Évalué à 3.
Peux-tu élaborer ?
[^] # Re: nouveauté pour l'utilisateur desktop ?
Posté par Nicolas Boulay (site web personnel) . É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 première sécurité est la liberté"
[^] # Re: nouveauté pour l'utilisateur desktop ?
Posté par barmic . Évalué à 4.
C'est ce que fait stali.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: nouveauté pour l'utilisateur desktop ?
Posté par daeldir . Évalué à 5.
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 :
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 Gof (site web personnel) . É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 Nicolas Boulay (site web personnel) . É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 première sécurité est la liberté"
[^] # Re: nouveauté pour l'utilisateur desktop ?
Posté par Gof (site web personnel) . É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 Nicolas Boulay (site web personnel) . É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 première sécurité est la liberté"
[^] # Re: nouveauté pour l'utilisateur desktop ?
Posté par ymorin . Évalué à 6.
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.
Normal qu´ils ne fassent rien (de plus) : un
.ace n´est qu´une collection de.o. Une archive de.ocomme untarball, mais sous un format différent.Hop,
Moi.
[^] # Re: nouveauté pour l'utilisateur desktop ?
Posté par Nicolas Boulay (site web personnel) . É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 première sécurité est la liberté"
[^] # Re: nouveauté pour l'utilisateur desktop ?
Posté par Crao . É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 Gof (site web personnel) . É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 ymorin . Évalué à 7.
Oh que non. À l´édition de lien, tous les symboles nécessaires, et seulement les symboles nécessaires, qui viennent de
.oou de.asont /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.
goldest un éditeur de liens ;gccest (un peu plus qu´)un compilateur.gold, c´estbinutils, pasgcc.Hop,
Moi.
[^] # Re: nouveauté pour l'utilisateur desktop ?
Posté par Zenitram (site web personnel) . É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 Meku (site web personnel) . É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 Nicolas Boulay (site web personnel) . Évalué à 3.
je ne crois pas qu'il trie les symboles, il doit simplement trié les fichiers objets, ".o".
"La première sécurité est la liberté"
[^] # Re: nouveauté pour l'utilisateur desktop ?
Posté par Meku (site web personnel) . Évalué à 1.
Oui effectivement, c'est plutôt ça (j'ai fait un test rapide avec 4.7.2).
[^] # Re: nouveauté pour l'utilisateur desktop ?
Posté par freem . Évalué à 6.
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 Jean Parpaillon (site web personnel) . Évalué à 10.
Ç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)
"Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier
[^] # Re: nouveauté pour l'utilisateur desktop ?
Posté par xcomcmdr . Évalué à 7.
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 freem . Évalué à 1.
Il y a juste un point qui m'intrigue dans le document que tu cites (le 2nd):
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 xcomcmdr . É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 freem . Évalué à 1.
D'ac, j'ai donc du confondre avec ceux des entrées/sorties. Merci de l'info.
[^] # Re: nouveauté pour l'utilisateur desktop ?
Posté par Misc (site web personnel) . Évalué à 3.
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 Nicolas Boulay (site web personnel) . É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 première sécurité est la liberté"
[^] # Re: nouveauté pour l'utilisateur desktop ?
Posté par claudex . Évalué à 5.
Ce n'est pas ce que permet systemd ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: nouveauté pour l'utilisateur desktop ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Pas avec la même finesse, il me semble.
"La première sécurité est la liberté"
[^] # Re: nouveauté pour l'utilisateur desktop ?
Posté par ariasuni . É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 voondo . É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 MarbolanGos (site web personnel) . É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 JB. Giraudeau . Évalué à 5.
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 ElectronLibre63 . Évalué à 1.
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 briaeros007 . É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 Sylvain Colinet (site web personnel) . É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 ʭ ☯ . Évalué à 10.
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://afdgauch.online.fr
[^] # Re: Liste des matériels supportés
Posté par redscape (site web personnel) . Évalué à 2.
Et en parlant de Fedora, il y a akmod qui existe non ?
[^] # Re: Liste des matériels supportés
Posté par WhiteCat . Évalué à 4.
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 Sylvain Colinet (site web personnel) . É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 Guy . Évalué à 1.
ça ne concerne que le pci :
http://kmuto.jp/debian/hcl/
[^] # Re: Liste des matériels supportés
Posté par MTux . É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.
[^] # Re: Liste des matériels supportés
Posté par Misc (site web personnel) . Évalué à 5.
Il parle peut être de carte wifi ( ce qui est une carte réseau aussi ), car en effet, une carte réseau ethernet pour pc non supporté sur linux, j'ai pas vu ça depuis 2004 :/
( mais bon, j'achète sans doute pas assez de matos ).
[^] # Re: Liste des matériels supportés
Posté par matteli . Évalué à 2.
Ma carte Qualcomm Atheros AR8161 Gigabit Ethernet n'est pas supporté par le kernel 3.8.
[^] # Re: Liste des matériels supportés
Posté par Aissen . Évalué à 3.
En effet, depuis que Qualcomm a racheté Atheros, tout fout le camp; ils avaient commencé à proposer ça upstream, mais c’était trop dégueu:
http://lkml.indiana.edu/hypermail/linux/kernel/1208.3/02602.html
J’ai l’impression qu’ils ont abandonné depuis… Il y a un workgroup à la Linux Foundation:
http://www.linuxfoundation.org/collaborate/workgroups/networking/alx
Mais ça reste un driver out-of-tree…
# LZO
Posté par patrick_g (site web personnel) . É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 barmic . Évalué à 2.
Je me demande si xz en profite ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: LZO
Posté par patrick_g (site web personnel) . É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 ʭ ☯ . Évalué à 6.
Voilà, parce que LZMA ≠ LZO ;-)
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: LZO
Posté par windu.2b . Évalué à 3.
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 Nicolas Boulay (site web personnel) . Évalué à 1.
En entré en compression et en sortie en décompression, j'imagine.
"La première sécurité est la liberté"
[^] # Re: LZO
Posté par Olivier Jeannet . É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 _jordan_ . Évalué à -6.
Merci patrick_g pour ses statistiques mises avec amour
# Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: RAID dans BRTFS
Posté par Nicolas Boulay (site web personnel) . É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 première sécurité est la liberté"
[^] # Re: RAID dans BRTFS
Posté par Gof (site web personnel) . É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 Nicolas Boulay (site web personnel) . É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 première sécurité est la liberté"
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: RAID dans BRTFS
Posté par Nicolas Boulay (site web personnel) . É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 première sécurité est la liberté"
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: RAID dans BRTFS
Posté par Nicolas Boulay (site web personnel) . Évalué à 3. Dernière modification le 30 avril 2013 à 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 première sécurité est la liberté"
[^] # Re: RAID dans BRTFS
Posté par Misc (site web personnel) . Évalué à 4.
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 ) ?
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 Nicolas Boulay (site web personnel) . Évalué à 2. Dernière modification le 30 avril 2013 à 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 première sécurité est la liberté"
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: RAID dans BRTFS
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
C'est pareil. Sauf que dans ton cas, tu pense à des outils en ligne de commande.
"La première sécurité est la liberté"
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: RAID dans BRTFS
Posté par Nicolas Boulay (site web personnel) . Évalué à 5. Dernière modification le 30 avril 2013 à 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 première sécurité est la liberté"
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4. Dernière modification le 30 avril 2013 à 22:09.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: RAID dans BRTFS
Posté par Nicolas Boulay (site web personnel) . É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 première sécurité est la liberté"
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: RAID dans BRTFS
Posté par Nicolas Boulay (site web personnel) . É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 première sécurité est la liberté"
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: RAID dans BRTFS
Posté par Nicolas Boulay (site web personnel) . É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 première sécurité est la liberté"
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2. Dernière modification le 02 mai 2013 à 15:14.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: RAID dans BRTFS
Posté par Nicolas Boulay (site web personnel) . É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 première sécurité est la liberté"
[^] # Re: RAID dans BRTFS
Posté par Sytoka Modon (site web personnel) . É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 Olivier Jeannet . É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 Nicolas Boulay (site web personnel) . É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 première sécurité est la liberté"
[^] # Re: RAID dans BRTFS
Posté par Olivier Jeannet . Évalué à 2.
Un checksum ne te corrige aucune erreur, il les détecte
Oui, on est au courant, tout de même :) .
Pour l'utilisation qu'en fait ZFS, cf par exemple : http://en.wikipedia.org/wiki/ZFS#ZFS_data_integrity . Sans redondance, c'est déjà pas mal d'être informé de corruption, et avec redondance, on peut effectuer la correction d'erreur.
[^] # Re: RAID dans BRTFS
Posté par wismerhill . Évalué à 1.
man lvm
man mdadm
[^] # Re: RAID dans BRTFS
Posté par Aissen . Évalué à 3.
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 Nicolas Boulay (site web personnel) . É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 première sécurité est la liberté"
[^] # Re: RAID dans BRTFS
Posté par Aissen . É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 claudex . É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.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: RAID dans BRTFS
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Dans combien de temps ? Sachant que la plus part des autres FS sont en mode maintenance uniquement (ext3, reserfs, xfs,…)
"La première sécurité est la liberté"
[^] # Re: RAID dans BRTFS
Posté par claudex . Évalué à 3.
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.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: RAID dans BRTFS
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Quel intérêt attendre la sortie hypothétique d'un truc compatible avant d'utiliser ce qui existe ?
"La première sécurité est la liberté"
[^] # Re: RAID dans BRTFS
Posté par claudex . Évalué à 6.
C'est exactement mon propos.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: RAID dans BRTFS
Posté par claudex . Évalué à 6.
Mais personne pour les écrire, donc ça ne change rien au final.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: RAID dans BRTFS
Posté par Zenitram (site web personnel) . Évalué à 6.
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.
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.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2. Dernière modification le 30 avril 2013 à 15:30.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: RAID dans BRTFS
Posté par Zenitram (site web personnel) . Évalué à 5.
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).
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 daeldir . É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.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -2. Dernière modification le 01 mai 2013 à 00:52.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: RAID dans BRTFS
Posté par Zenitram (site web personnel) . Évalué à 7.
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 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 Moonz . Évalué à 1.
Tu veux dire… un peu comme le Hurd ? ;)
[^] # Re: RAID dans BRTFS
Posté par Zenitram (site web personnel) . É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 Sytoka Modon (site web personnel) . Évalué à 2.
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 !
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: RAID dans BRTFS
Posté par Zenitram (site web personnel) . Évalué à 3. Dernière modification le 01 mai 2013 à 11:33.
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…
"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.
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 zx81 . Évalué à 2.
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 wismerhill . Évalué à 2.
C'est chouette pour avoir un backup avec des fichiers corrompus.
[^] # Re: RAID dans BRTFS
Posté par zx81 . É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 Prosper . Évalué à 2.
Sun Volume Manager/diskSuite existe depuis 1991
Perdu c'est Netapp en 1993 ( FAS400 )
[^] # Re: RAID dans BRTFS
Posté par oinkoink_daotter . Évalué à 1.
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.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1. Dernière modification le 02 mai 2013 à 13:30.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: RAID dans BRTFS
Posté par oinkoink_daotter . É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 Olivier Jeannet . É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 fcartegnie . Évalué à 3.
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 barmic . É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.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Prise en charge des Tegra
Posté par Dreamkey . É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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.