Le détail des évolutions, nouveautés et prévisions est dans la seconde partie de la dépêche. Le sommaire...
La phase de test... (↑)
- La version RC-1 a été annoncée le 7 avril dernier :
"Bon la période de deux semaines est terminée et ce n'est pas plus mal parce qu'il y a beaucoup de changements. Je n'étais pas pressé de la laisser ouverte un peu plus pour recevoir les quelques méga-octets de patchs restants.
Les changements suivent à peu près le même schéma que pour les fois précédentes : un tiers de saleté (c'est à dire les pilotes de la branche "staging" qui ne sont pas vraiment prêts pour inclusion mais qui sont ajoutés dans les sources avec l'espoir qu'un jour il vont s'améliorer), un tiers de vrais pilotes et un tiers pour tout le reste.
Pour ne pas changer avec notre nouvelle tradition il y a quelques systèmes de fichiers en plus dans cette version (..) Nilfs et Exofs (...) Personnellement j'espère que nous allons finir par manquer de système de fichiers plutôt que de continuer d'en inclure à l'infini, mais nous verrons."
- Une semaine plus tard c'est la RC-2 qui est apparue :
"Une nouvelle architecture "Microblaze", un nouveau pilote Intel de réseau virtuel, des mises à jour de pilotes (ide, infiniband, sgi-xp, intel dri, watchdog). Des mises à jour également sur les systèmes de fichiers nilfs2 et xfs.
Et des corrections un peu partout. Pas aussi petites que ce que j'espérais mais on en est juste à la version RC-2 et au moins cela semble moins chaotique que certaines autres versions RC-2. Mais peut-être est-ce encore ma nature optimiste qui parle."
- Avec une précision d'horloge la RC-3 a été annoncée par Linus le 21 avril :
"Une autre semaine, une autre RC.
Le patch est encore plus gros que le précédent car nous avons renommé les fichiers headers de l'architecture m32r (la dernière architecture à utiliser le vieux format include/asm-xyz).
A part ça il n'y pas vraiment de trucs excitants. Les choses semblent se calmer. Beaucoup de petits patchs d'une ou deux lignes et j'espère que toutes les régressions embarrassantes et triviales sont maintenant corrigées.
Ce qui laisse les autres qui sont bien plus intéressantes et qui, bien entendu, nous font demander aux gens de tester encore plus."
- Outre un grand nombre de corrections diverses la vraie nouveauté de la version candidate RC-4 a été le retour de la mascotte Tux au détriment de son cousin Tuz qui l'avait remplacé temporairement afin de soutenir la campagne pour sauver le diable de Tasmanie de l'extinction. Linus a posté le patch en soulignant qu'il avait toujours été prévu que ce remplacement ne serait valable que pour une version :
"Hé ce n'était censé durer que le temps d'une release. Maintenant, pour autant que je sois concerné, ils peuvent tous crever !
Je plaisante. Ils sont mignons et câlins... sauf quand ils ont cette horrible maladie faciale. Oh et puis finalement ils ne doivent pas être si câlins que ça, même quand ils n'ont pas la maladie."
Toujours dans la veine animalière le nom de version du noyau 2.6.30 a également été fixé à "Vindictive Armadillo" (Tatou vindicatif) au lieu de "Temporary Tasmanian Devil" pour la version précédente.
- Les versions RC-5 (8 mai) et RC-6 (15 mai) se sont succédés sans histoire avec à chaque fois moins de changements mais la RC-7 du 23 mai a vu l'intégration tardive d'un pilote Cisco de Fibre Channel over Ethernet ce qui a incité Linus a renouveler ses demandes de tests :
"Je suspecte que je vais faire une RC-8 mais nous nous rapprochons indubitablement de la sortie. Ce serait bien d'avoir autant de tests que possible. De toute façon cela devrait être sans risque d'essayer tout ça."
- Après avoir un peu hésité Linus a finalement choisi de s'en tenir à ses prévisions et de faire une dernière version candidate. La RC-8 a été annoncée le 03 juin et, comme prévu à ce stade, elle ne contient que des mises à jour mineures et des corrections de régressions.
Linus a prévu de poster la version finale "probablement ce weekend".
Les nouveautés... (↑)
- La "grosse affaire" du noyau 2.6.30 a été incorporation de diverses améliorations dans les systèmes de fichiers Ext3 et Ext4 et le changement l'option de montage par défaut d'Ext3.
Tout a commencé après la sortie du noyau 2.6.29 quand les utilisateurs se sont mis a signaler d'étranges problèmes avec le tout nouveau système de fichiers Ext4. Après un crash inopiné du système (par exemple du fait d'un vilain pilote binaire instable) il n'était pas rare de se retrouver avec des fichiers de configuration vides… ce qui est évidemment gênant ! En temps normal on s'attend à avoir soit l'ancienne version du fichier, soit la nouvelle version mais pas à ce qu'un crash entraîne la disparition totale du contenu. Le problème a été rapidement identifié et il s'est avéré que le système de fichiers Ext4 n'était pas vraiment responsable de la situation.
Si on veut résumer simplement les choses on peut dire qu'un des moyens habituels utilisé par les applications pour modifier le contenu d'un fichier existant (nommé MonFichier) consiste à faire la suite d'opérations suivante :
open("MonFichier.temp")
write("MonFichier.temp")
close("MonFichier.temp")
rename("MonFichier.temp", "MonFichier").
On ouvre un fichier temporaire, on écrit dedans, on le referme et ensuite on écrase l'ancienne version avec la nouvelle.
Avec le système de fichiers Ext3 cette méthode marchait parfaitement alors qu'en fait il s'agit d'une méthode dangereuse et que la norme POSIX ne garantit pas du tout la cohérence des données si on utilise cette méthode. En effet entre l'étape du Write et celle du Close on n'a aucune certitude que les données sont vraiment écrites sur le disque dur.
La vraie solution si une application doit changer le contenu d'un fichier est d'effectuer les opérations suivantes :
open("MonFichier.temp")
write("MonFichier.temp")
fsync("MonFichier.temp")
close("MonFichier.temp")
rename("MonFichier.temp", "MonFichier").
On ouvre un fichier temporaire, on écrit dedans, on force l'écriture sur le disque avec la commande fsync, on le referme et ensuite on écrase l'ancienne version avec la nouvelle.
En dépit de l'utilisation de la méthode dangereuse (sans fsync) par les applications il était rare d'avoir des problèmes avec Ext3. Quand on utilise ce système de fichiers la fenêtre de temps ou s'accumulent les écritures est seulement de 5 secondes et la méthode de journalisation par défaut est data=ordered (ce qui signifie que les méta-données sont toujours cohérentes). Il est donc garanti que les données seront vraiment écrites sur le disque en 5 secondes (même sans fsync) et que le risque de se retrouver avec un fichier vide est infime.
Avec Ext4 la situation change puisque la fenêtre temporelle à risque est plus grande.
Tous les systèmes de fichiers modernes (ZFS, Btrfs, Ext4) implémentent une fonction nommée "Delayed allocation" qui revient en gros à accumuler les écritures dans un tampon mémoire pendant un certain temps avant de vraiment écrire physiquement sur le disque en une seule fois et de façon parfaitement optimisée. Cette méthode augmente énormément les performances et elle est donc très utile. Bien entendu les applications qui utilisaient la méthode dangereuse de modification de contenu sans fsync sont maintenant à la merci d'une perte de données.
Pour corriger le problème proprement il faudrait que toutes ces applications fautives soient modifiées afin d'être certain qu'elles utilisent le fsync salvateur. Évidemment cette solution rencontre beaucoup de résistance : les développeurs, notoirement paresseux, ne veulent pas modifier leurs applications et soulignent que fsync introduit un temps de latence inacceptable. Les utilisateurs, notoirement exigeants, soulignent qu'avec Ext3 tout allait bien et qu'ils veulent la même chose avec Ext4, etc.
Pour tenter de satisfaire tout le monde il a donc été décidé d'employer plusieurs stratégies simultanément.
La première consiste a réduire le risque de problème avec Ext4. Ted Ts'o a posté différents patchs afin de forcer automatiquement la synchronisation des données sur le disque quand un fichier est renommé ou modifié. Cela couvre donc les risques d'effacement de fichiers de configuration tout en préservant les performances pour toutes les autres opérations. Les utilisateurs n'auront donc plus de raison de ne pas utiliser Ext4 (et ceux qui n'aiment pas ces patchs peuvent les désactiver avec l'option de mount auto_da_alloc).
La seconde stratégie qui a été utilisée est de réduire le temps de latence de l'opération fsync afin d'inciter les développeurs à utiliser plus volontiers cette fonction. Ted Ts'o a écrit plusieurs patchs qui permettent d'améliorer drastiquement les performances. Désormais, dans le noyau 2.6.30, les données devant être écrites sur le disque suite à un fsync ne sont plus mises à la fin de la file d'attente de l'ordonnanceur des entrées/sorties (CFQ). Elles ont maintenant la priorité (en ayant le flag WRITE_SYNC) ce qui résout le problème de temps de latence. Jens Axboe, le mainteneur de l'ordonnanceur CFQ, a protesté devant ce changement en arguant que cela allait ralentir le débit des autres entrées/sorties. Linus est rapidement intervenu dans ce débat en soulignant que le temps de latence était plus important que le débit théorique. Il a même menacé de changer d'ordonnanceur par défaut CFQ pour choisir son concurrent AS (Anticipatory Scheduler) à la place :
"Jens tu a un cas de test maintenant. Considère le comme une priorité ou bien considère que CFQ ne sera bientôt plus que pour les-serveurs-débiles-qui-ne-pensent-qu'au-débit".
Avec une telle épée de Damoclès au dessus de sa tête Jens Axboe s'est lancé à corps perdu dans l'optimisation de CFQ et il est parvenu a déterminer ce qui causait la baisse du débit (en temps normal CFQ tente de fusionner les requêtes afin d'améliorer le débit mais dans le cas de requêtes ayant le flag WRITE_SYNC il s'avère que cela réduit les performances). En définitive Jens a posté plusieurs patchs de correction de CFQ et il a réussi retrouver les anciennes performances de débit...et même a les améliorer !
La troisième stratégie, visant elle aussi à améliorer la latence du fsync sous Ext3, consiste a monter le système de fichiers avec l'option data=writeback au lieu de l'option data=ordered qui était utilisée auparavant. Avec cette option data=writeback seules les méta-données sont écrites dans le journal et pas les données. Cela élimine le temps de latence quand on fait un fsync mais au prix d'un risque accru sur les données. Ted Ts'o a donc mis en place les mêmes sauvegardes que pour Ext4 (synchronisation forcée des données sur le disque quand un fichier est renommé ou modifié).
Certains développeurs sont tout de même réticents devant ce changement et il faudra voir si les distributions adoptent ce nouveau mode par défaut ou si elles restent en data=ordered. Peut-être que la solution viendra du travail de Chris Mason qui développe un tout nouveau mode data=guarded afin d'avoir les avantages des deux autres modes sans leurs inconvénients.
Le cycle de développement du noyau 2.6.30 aura donc vu une importante polémique au sujet des systèmes de fichiers Ext3 et Ext4. Des centaines de mails ont été échangés sur la liste de diffusion et les noms d'oiseaux ont volés (crap, moron, stupid, etc) mais en définitive, comme souvent dans le monde du logiciel libre, ces tumultueuses convulsions ont permis d'améliorer le code pour le bénéfice de tous.
- Le système de fichiers NILFS (un acronyme qui signifie New Implementation of a Log-structured File System) est entré dans le noyau 2.6.30.
Le code de la version 2 avait été soumis sur la liste de diffusion du noyau en août 2008 par les développeurs de la firme japonaise NTT et il a suffisamment mûri pour entrer maintenant dans la branche principale.
NILFS2 est un système de fichiers qui utilise la technique d'écriture des données par flux (Log-structured file systems). Comme pour les fichiers de log on écrit simplement les données de façon séquentielle les unes à la suite des autres, à flux continu, et on ne se préoccupe pas d'optimiser l'écriture en cherchant à placer les blocs au bon endroit.
L'avantage de ce système est que l'écriture se fait à la vitesse maximum prévue par le disque mais la contrepartie est que la lecture de ces données peut être plus lente puisque les fichiers sont fragmentés. L'idée derrière tout cela est que les lectures de données se font très souvent à partir de la mémoire cache et qu'il est donc plus payant d'optimiser l'écriture des données par la technique du flux continu plutôt que de chercher à optimiser leur lecture.
Un autre avantage des systèmes de fichiers par flux et qu'il est plus facile de faire des instantanés (snapshots) du système puisque, comme pour les logs, les ancienne données ne sont pas effacées par l'écriture des nouvelles.
Toutes les quelques secondes, et quand un changement se produit, NILFS insère une "balise" (checkpoint) et un utilisateur peut ultérieurement se servir de ces balises pour retrouver les états antérieurs du système de fichiers. Contrairement à d'autres systèmes NILFS n'a pas besoin de suspendre les opérations pour insérer ces checkpoints et tout se passe de façon transparente.
On obtient la liste de ces checkpoints avec la commande lscp (pour "list checkpoint") et ils ont tous le flag cp (pour "checkpoint"). C'est ensuite un jeu d'enfant de convertir ces checkpoints automatiques en vrais snapshots du système de fichiers avec la commande chcp (pour "change checkpoint"). Par exemple la commande sudo chcp ss 3 modifie le troisième checkpoint de la liste et le change en snapshot (on lui met le flag ss au lieu du flag cp). On peut ensuite monter ces snapshots (en lecture seule) en même temps que le "vrai" système de fichier qui reste en lecture/écriture.
NILFS n'est pas le premier système de fichiers en flux a entrer dans le noyau et il prend donc place aux cotés de ses cousins plus anciens LogFS, YAFFS et autres JFFS2. La différence est que NILFS semble bien pensé et très abouti et que ses performances sont particulièrement bonnes sur les disques de type SSD qui, au contraire des disques durs classiques, sont peu sensibles à la fragmentation des données. Les pages 8 et 9 de ce benchmark représentatif d'un serveur de mail sont particulièrement impressionnantes et on voit que NILFS domine de la tête et des épaules ses rivaux.
- Le second système de fichiers à intégrer la branche principale est Exofs (Extended Object File System).
Anciennement connu sous le nom d'OSDFS (Object Storage Devices File System), ce nouveau système permet, pour la première fois sous Linux, de profiter du nouveau mode de stockage réseau OSD (Object Storage Device). Cette norme récente, applicable aux disques à la norme SCSI, se base sur l'idée que les disques actuels ont une interface trop complexe et de niveau trop bas puisqu'elle se base sur des blocs et des secteurs. Au lieu d'utiliser cette notion de blocs et de secteurs un périphérique OSD se base sur des "objets" plus abstraits. Chacun de ces objets possède un identifiant sur 64 bits et des attributs et méta-données qui lui sont attachés.
Si un système d'exploitation utilise un stockage OSD alors il peut se contenter de gérer les objets et leurs identifiants sans avoir à se préoccuper de sordides détails de bas niveau comme les secteurs ou les blocs du disque. Lors de la lecture d'un objet il suffit au système d'exploitation de savoir son identifiant.
Pour développer ce système les auteurs d'Exofs sont partis du code mûr de Ext2 et ils ont enlevé tout ce qui ne sert plus (la gestion de bas-niveau) et ont ajouté de quoi communiquer avec la bibliothèque OSD-initiator qui s'occupe de gérer les "objets" qui vivent au sein du périphérique de stockage.
L'évolution en marche ici consiste à pousser plus "d'intelligence" directement dans le périphérique de stockage réseau (la gestion physique des blocs/secteurs) afin de ne proposer qu'une interface à base d'objets au système d'exploitation. On fait le pari que c'est le périphérique lui-même qui est le mieux placé pour prendre les décisions d'allocation ou d'optimisation des performances et qu'il vaut mieux lui déléguer cette responsabilité. Cette évolution, bien décrite dans ce document de Sun qui utilise déjà OSD dans Solaris, est vue par certains comme la voie du futur et Linux ne pouvait pas faire l'impasse.
La contrepartie de cette solution c'est qu'un morceau de code libre de Linux (la gestion des blocs/secteurs) va migrer (voir ce diagramme) dans le micrologiciel des disques OSD.
La conclusion de l'article de Jon Corbet consacré à ce sujet résume parfaitement les risques :
"Un périphérique OSD s'empare d'une tâche qui est effectuée au sein du noyau et la pousse dans un micrologiciel où ce code ne pourra plus être inspecté ou corrigé. Si l'implémentation dans le micrologiciel est de mauvaise qualité alors au mieux la performance ne sera pas bonne, au pire les chances de perdre des données augmenteront considérablement. Il sera peut-être préférable d'insister pour que les périphériques de stockage se concentrent juste sur le placement des bits là ou le noyau leur dit de les placer et laissent les décisions de haut niveau au code de haut niveau. Ou alors peut-être que les OSD sont vraiment la prochaine étape vers des périphériques plus intelligents et plus efficaces que les anciens. Que ce soit l'un ou l'autre c'est une expérience intéressante".
- Décidément le noyau 2.6.30 est prolixe en nouveaux systèmes de fichiers puisqu'il incorpore également POHMELFS (Parallel Optimized Host Message Exchange Layered File System). En dépit de son nom barbare POHMELFS a beaucoup d'arguments techniques de son coté et son développeur principal, Evgeniy Polyakov, poste régulièrement des descriptions sur son blog. Il s'agit d'un système de fichiers réseau comme peut l'être NFS ou CIFS/Samba. POHMELFS permet de distribuer les opérations de lecture ou d'écriture sur plusieurs nœuds réseau en parallèle. Il utilise aussi intensivement un cache local avec la politique de writeback (on n'écrit que dans le cache) au lieu de writethrough (on écrit dans le cache et aussi à distance). Le protocole de cohérence est de type MOESI et, d'après les benchmarks, les performances sont très intéressantes.
Evgeniy Polyakov semble pour l'instant la seule personne à être réellement impliquée dans le développement de POHMELFS. Il faudra voir dans les mois suivants si ce nouveau système de fichiers arrive à vraiment fédérer un groupe de développeurs ou bien si le futur pNFS (Parallel NFS) emporte tout sur son passage.
- Le mécanisme FS-Cache a été finalement inclus dans le noyau 2.6.30 après une saga de plusieurs années.
Comme l'indique la date de l'article Linux Weekly News donné en lien initial (septembre 2004) FS-Cache aura mis du temps a intégrer la branche principale du noyau Linux. C'est pourtant un patch qui est déjà utilisé par Red Hat dans Fedora et dans RHEL 5.x mais il a fallu vaincre beaucoup de résistances avant d'aboutir à cette inclusion.
Conceptuellement le mécanisme est très logique : afin d'augmenter les performances des systèmes de fichiers réseaux on interpose une couche qui va servir à mettre en cache les données (avec un système de "cookies" pour prendre en compte les données obsolètes). Ainsi un accès ultérieur à un fichier sera bien plus rapide puisque les données seront sur un disque dur local et non plus à l'autre bout d'un réseau lent. On sacrifie un peu d'espace disque au bénéfice de la latence et du temps de chargement des données.
Ce mécanisme générique de mise en cache des données réseau existe déjà dans d'autres systèmes sous le nom de CacheFS (sous Solaris ou IRIX notamment) mais les développeurs du noyau ont longtemps hésité a accepter un changement aussi intrusif. Quand un patch modifie 303 fichiers source et insère plus de 21 000 lignes dans le noyau il faut mettre en balance le gain en performances et le coût en maintenance.
David Howells, le développeur principal de FS-cache, a donc dû se battre pour convaincre ses pairs de l'intérêt de son bébé. Il a souligné le fait que ce patch était déjà utilisé par Red Hat et a listé des exemples d'utilisation par des clients de Red Hat. On apprend ainsi qu'un client de "l'industrie du divertissement" utilise FS-cache pour diminuer le trafic réseau quand sa ferme de serveurs doit servir des gigaoctets de textures au processeurs s'occupant du rendu final.
Des benchmarks ont également été effectués afin de quantifier le gain qui semble être non négligeable. Une documentation détaillée de FS-cache a également été écrite.
Ce travail d'explication et de justification a fini par porter ses fruits et FS-cache a été accepté dans le noyau principal après plus de quatre ans d'efforts de la part de David Howells.
Actuellement le mécanisme FS-cache permet d'accélérer les accès des systèmes de fichiers NFS (Network file system) et AFS (Andrew File System) mais comme FS-cache a été conçu pour être aussi générique que possible il sera facile d'ajouter le support d'autres systèmes de fichiers réseau.
- Le module de sécurité TOMOYO vient rejoindre SELinux et SMACK au sein du noyau afin d'offrir une nouvelle alternative aux utilisateurs.
TOMOYO se base sur le chemin d'accès (pathname) pour définir les restrictions d'accès du système alors que les modules de sécurité SELinux et SMACK se basent sur des labels qui sont attachés à chacun des objets du système.
L'avantage le plus évident de l'approche basée sur les chemins est sa simplicité à l'utilisation. Avec les labels il faut recompiler les règles lors de chaque changement et la lisibilité des ces règles par l'utilisateur est difficile. On comprend vite que le simple utilisateur ou même l'administrateur n'est pas vraiment censé modifier quoi que ce soit. C'est le spécialiste SELinux de votre distribution qui est chargé de tout paramétrer et vous êtes un simple "consommateur".
Le domaine de la sécurité étant extrêmement sensible et difficile, peut-être est-ce la meilleure solution que de laisser le travail à ceux qui s'y connaissent vraiment ? Il est toutefois évident que cela ne convient pas à tous le monde et certaines personnes veulent modifier eux-mêmes leur politique de sécurité et ils ne veulent pas se plonger dans le monde complexe de SELinux. C'est pour ces gens là que TOMOYO va représenter une alternative.
Pour l'utiliser on définit une politique de sécurité (à base de allow_execute ou allow_read) et ensuite on liste les chemins d'accès qui sont contrôlés par cette politique particulière. Bien entendu le système prévoit les cas ou un petit malin essaierait de créer des liens entre fichiers (ln /etc/shadow /tmp/shadow) afin de contourner le système basé sur le chemin d'accès. Tant qu'il n'y a pas eu un allow_link cela ne marchera pas.
Toutes ces objections et bien d'autres sont couvertes par une FAQ sur le site de TOMOYO ainsi que dans divers documents expliquant le fonctionnement de l'outil.
Un mode d'apprentissage automatique est présent et une interface graphique de configuration écrite en Java est disponible (voir les copies d'écran).
Au final il ne faut pas s'illusionner et croire que n'importe qui va pouvoir définir et régler finement la politique de sécurité de sa machine. Le problème est difficile et TOMOYO ne fait que faciliter un peu plus une tâche qui reste intrinsèquement complexe.
- Toujours du coté de la sécurité, on peut aussi noter l'inclusion de l'architecture de contrôle d'intégrité dans ce noyau 2.6.30.
Le contrôle d'intégrité (IMA pour Integrity Management Architecture) a été développé par IBM et il signifie que le noyau est maintenant capable de vérifier si une modification a eu lieu sur certains fichiers ou exécutables du système. C'est donc une mesure de sécurité complémentaire aux modules tels que SELinux, SMACK ou TOMOYO. Ces derniers protègent efficacement contre les attaques en ligne mais ne peuvent rien si un live-CD est utilisé pour démarrer le système et pour changer les fichiers ou les programmes. Afin de contrer cette attaque, il suffit de faire une empreinte (un hash SHA1) de ces fichiers ou programmes et d'envoyer le résultat dans une puce de stockage spéciale (TPM pour Trusted Platform Module) où il sera stocké une bonne fois pour toutes. Ainsi il est possible, lors des utilisations ultérieures de la machine, de vérifier que l'intégrité des fichiers et des programmes n'a pas été compromise.
Integrity Management fonctionne en deux parties : d'abord le code EVM (Extended Verification Module) prend l'empreinte des fichiers puis le code IBAC (Integrity Based Access Control) interdit l'accès aux fichiers ou le lancement des programmes compromis.
Un document sur le site d'IBM présente parfaitement les détails de cette architecture et il existe même un exemple de fichier d'empreinte généré par le boot d'un ordinateur portable sous Red Hat.
Cette fonction de gestion d'intégrité est donc fort utile (elle est même obligatoire si Linux veut pouvoir postuler à certains appels d'offres gouvernementaux) et c'est ce ce qui légitime son entrée dans le noyau… mais elle fait également entrevoir aux adeptes du logiciel libre un risque grave de "tivoisation". Une firme pourrait ainsi créer un matériel electronique quelconque en se basant sur des logiciels libres et utiliser le contrôle d'intégrité et la puce TPM pour vérifier que le code n'a pas été modifié. L'utilisateur perdrait ainsi son droit à modifier et améliorer le logiciel libre de sa machine (c'est la liberté 3 de la Free Software Foundation). C'est l'un des points de divergence entre Richard Stallman et Linus Torvalds puisque ce dernier n'a jamais caché (cf ce message détaillé de 2003) qu'il n'avait pas de but politique et qu'il ne visait qu'à produire le meilleur système d'exploitation possible :
"Je refuse de participer aux jeux politiques avec Linux et je pense que vous pouvez utiliser Linux pour faire ce que vous voulez… ce qui inclut plein de choses que je n'approuve pas nécessairement."
- Le code des mutex du noyau a été modifié afin d'introduire un mécanisme d'attente adaptable pour les mutex.
L'idée est relativement simple à comprendre : quand une ressource est utilisée par un processus, celui-ci pose un "verrou" sur cette ressource afin d'être le seul à pouvoir l'utiliser. Ce verrou (nommé mutex pour mutual exclusion) interdit aux autres processus d'accéder à la ressource et ces pauvres malheureux doivent "s'endormir" en attendant que la ressource soit libérée. Néanmoins il a souvent été noté que les performances du système s'amélioraient si le processus attendait un petit moment avant de s'endormir. Après tout il est assez probable que la ressource soit libérée rapidement ; pour le processus il vaut donc mieux attendre un peu plutôt que de s'endormir et se réveiller (ce qui prend beaucoup de temps et provoque également souvent le vidage et le rechargement du cache du processeur).
Ce code permettant au processus d'attendre un peu avant de s'endormir a été développé dans la branche temps-réel du noyau mais il n'avait jamais été intégré dans la branche principale.
Son inclusion a été déclenchée car le système de fichiers btrfs, ayant besoin de ce mécanisme d'attente pour les mutex, avait développé sa propre solution. Cette solution n'était clairement pas optimale puisqu'elle n'était utilisée que par Btrfs et il valait bien mieux que le noyau propose un système générique qui serait utilisé partout. C'est ce nouveau mécanisme générique d'attente adaptable pour les mutex qui est présent dans le noyau 2.6.30.
Maintenant les mutex ressemblent un peu plus aux spinlocks (qui sont des verrous qui ne s'endorment jamais et qui continuent à tourner en permanence en attendant la libération de la ressource) et le code de btrfs a été nettoyé afin de supprimer son code mutex spécifique et d'ajouter le code utilisant les mutex adaptables génériques.
Concrètement les processus qui utilisent ces nouveaux mutex adaptables vont attendre un certain temps à la porte d'une ressource si et seulement si le poseur du verrou s'exécute sur un autre processeur de la machine. L'idée est que le poseur du verrou a une bonne chance de libérer rapidement la ressource puisqu'il profite à fond d'un processeur.
Coté performances ce nouveau mécanisme d'attente adaptable a été testé par son auteur, Peter Zijlstra, à l'aide du code de test spécifique des mutex écrit par Ingo Molnar.
Selon ce test très spécifique aux mutex et non généralisable on passe de 85 870 opérations par seconde à 296 604 opérations par seconde, ce qui représente un gain impressionnant de 345%.
En bref... (↑)
- Comme prévu l'infrastructure d'appels asynchrones qui est entrée dans le noyau 2.6.29 a été activée par Arjan Van de Ven pour cette version 2.6.30.
Ce code permet d'interroger les périphériques de stockage de façon asynchrone lors de l'amorçage du noyau. On parle de "device probing" et habituellement, avec le fonctionnement synchrone classique, le lancement de la machine est fortement ralenti car l'interrogation se fait un périphérique après l'autre et bloque le reste du noyau. Pour éviter cette fâcheuse situation, l'infrastructure créée par Arjan permet de découvrir tous les périphériques en parallèle (256 au maximum) et ne bloque plus le reste du noyau qui peut continuer à démarrer des choses en tâche de fond pour le plus grand bénéfice du temps de démarrage de la machine.
Pour éviter de complexifier inutilement le code, Arjan a choisi de ne travailler que sur les périphériques de stockage sur bus SCSI ou SATA.
- Le support du protocole Reliable Datagram Sockets (RDS) a été intégré dans le noyau 2.6.30 afin d'améliorer les performances des grappes de serveurs (clusters). Ce protocole de type IPC (inter-process communication) permet à un processus de se contenter d'un seul socket pour parler à tous les autres processus de la grappe. Cela semble insignifiant mais quand on a 25 processus qui tournent on n'a besoin que de 25 sockets pour communiquer avec les autres au lieu de 25x25 avec des protocoles comme TCP.
- L'architecture de processeur MicroBlaze de la société Xilinx est dorénavant prise en charge par le nouveau noyau Linux 2.6.30. Le MicroBlaze est un microprocesseur Risc implémenté sur une puce reprogrammable (on parle donc d'un softcore sur un FPGA) et il est optimisé pour l'embarqué.
Il est donc possible de paramétrer finement son MicroBlaze afin de coller au mieux aux besoins (taille du cache, profondeur de pipeline, etc). Plus de 70 options différentes sont disponibles lors de la définition du processeur.
- L'infrastructure de contrôle d'intégrité des périphériques en mode bloc (qui a fait son apparition dans le noyau 2.6.27 pour les disques SATA et SCSI) a été étendue et supporte maintenant la couche MD (Multiple Device) du noyau.
Il est donc possible de profiter de tous les avantages de ce contrôle d'intégrité dans ses montages RAID. Bien entendu, pour que la matrice RAID soit prise en compte par l'infrastructure de contrôle d'intégrité, il faut que tous les disques de la matrice prennent en charge le même format de protection.
- Le noyau qui est lancé lors de l'étape initiale du boot peut maintenant être compressé avec des algorithmes plus efficaces que le vieillissant gzip. A partir du noyau 2.6.30 il est possible d'utiliser bzip2 (10% de gain sur la taille par rapport à gzip) ou lzma (33% de gain).
- Le code de chiffrement des données qui est présent dans le noyau Linux 2.6.30 a été revu afin d'améliorer les performances sur les machines multiprocesseurs. L'approche choisie est celle d'une queue de traitement (cryptd_cpu_queue) pour chaque processeur du système. Un test utilisant l'infrastructure de chiffrement dm-crypt avec un processeur Code 2 Duo a démontré un gain en performances de 19,2% par rapport au code précédent.
- L'accélération matérielle du chiffrage AES sera possible avec les futurs processeurs Intel Westmere grâce a des instructions supplémentaires qui font appel à des routines "en dur" dans la puce. Le support des ces instructions a été ajouté au noyau Linux 2.6.30, permettant des performances de chiffrement sans commune mesure avec ce qui est possible aujourd'hui sur un processeur classique.
- Le nouveau noyau propose le support de la fonction de protection de pile (Stack protector) pour l'architecture x86 32 bits. Afin de détecter les écrasements de la pile de données le patch implémente la technique classique du "canari". Au lancement du programme un entier aléatoire de 24 bits est écrit dans la pile. En cas d'écrasement par un dépassement de la pile (stack overflow), le canari est également écrasé, ce qui signale le problème et permet au programme de se faire vaillamment seppuku au lieu de passer sous le contrôle de l'agresseur.
Bien entendu cette implémentation est imparfaite du fait des limitations intrinsèques de l'architecture x86 32 bits, et il vaut bien mieux utiliser une architecture x86-64 pour dormir tranquille.
- La prise en charge des cartes AMD/ATI de type R6xx et R7xx (c'est à dire les cartes les plus modernes) est maintenant présent dans le noyau. Ce support se limite pour l'instant à la 2D mais la publication par AMD des manuels et guides de ces cartes va certainement aider à l'écriture du code supportant la 3D.
- Le modèle de sécurité du protocole Bluetooth 2.1 est maintenant pris en charge par le noyau 2.6.30.
Avec la nouvelle norme SSP (Secure Simple Pairing) le chiffrage des connexions est désormais obligatoire (il n'était qu'optionnel auparavant) et les niveaux de sécurité SDP, LOW, MEDIUM et SECURE sont disponibles. Le niveau SECURE permet de résister aux attaques du type de l'homme du milieu (man in the middle).
- La commande TRIM, qui permet d'augmenter les performances des disques SSD en supprimant effectivement les données sur le disque (voir ces trois excellentes pages explicatives sur le site AnandTech: 1 - 2 - 3), a été intégrée au noyau 2.6.30.
Les futurs disques SSD utiliseront tous la commande TRIM et il est même possible que les disques actuels soient mis à jour par changement de leur micrologiciel car les bénéfices sont importants. Ce support de TRIM dans Linux est générique puisqu'il est implémenté au niveau de la couche ATA.
- Suivant l'exemple des processeurs 32 bits x86, l'architecture ARM profite maintenant d'une fonction HIGHMEM. Cela permet d'adresser une quantité de mémoire supérieure à la limite naturelle des 4 Go des architectures 32 bits. Avec l'inclusion dans le noyau 2.6.30 de ces patchs écrits par Nicolas Pitre il va maintenant être possible de faire joujou avec des téléphones portables très bien dotés en mémoire !
- L'infrastructure ftrace permettant de suivre les appels système d'une commande donnée en paramètre (et qui est entrée dans le noyau 2.6.27) a été largement améliorée. Il est possible de lister tous les marqueurs statiques enregistrés dans le noyau en lisant dans le répertoire /debug/tracing/events/ et il est très facile d'activer le tracé d'un nouveau marqueur en utilisant /debug/tracing/set_event (la syntaxe est echo nom_du_marqueur > /debug/tracing/set_event).
En outre l'infrastructure ftrace est maintenant compatible avec l'architecture Itanium (IA64) et avec l'architecture PowerPC (PPC32/PPC64).
- Le code permettant de gérer la fréquence du ou des processeurs (cpufreq) a été amélioré et il incorpore maintenant la notion de temps de latence entre les fréquences. Bien entendu les noyaux Linux précédents géraient déjà les changements de fréquence des processeurs, mais ils n'avaient des informations que sur la fréquence maximale (cpuinfo_max_freq) et sur la fréquence minimale (cpuinfo_min_freq) du processeur. Avec le noyau 2.6.30 l'information sur le temps de latence en nanosecondes pour passer d'une fréquence à l'autre est disponible (cpuinfo_transition_latency). Cela va servir à affiner la politique de changement de fréquence exercée par le noyau afin d'optimiser les performances et la consommation.
- Comme avec chaque nouvelle version du noyau un grand nombre de pilotes divers et variés entrent dans la branche principale ou sont améliorés. Du coté de l'audio c'est la version ALSA 1.0.20 qui rentre dans le noyau avec toutes ses nouveautés. Les pilotes V4L (Video for Linux) sont également mis à jour et le mainteneur principal, Mauro Carvalho Chehab, ne se risque même pas à lister les changements dans son message tant ils sont nombreux. Le site Heise Online propose un article récapitulatif qui liste les pilotes mis à jour dans le noyau 2.6.30.
- Enfin, pour prouver que le développement du noyau Linux n'est pas encore devenu une affaire réservée aux grosses entreprises et que les passionnés ont encore leur place, on peut citer le travail d'Adrian McMenamin qui continue à poster des patchs sur le support de la console Sega Dreamcast. Cette fois c'est le support des cartes externes de type Visual Memory Unit (carte flash avec un contrôleur 8 bits) qui entre dans la branche principale.
La console n'est plus produite depuis début 2001 mais le support dans le noyau Linux de ses accessoires s'améliore encore… pour la beauté du geste !
Le bilan en chiffres... (↑)
Coté statistiques, l'habituel article récapitulatif du site LWN est disponible et on pourra également se reporter au site dédié aux statistiques du noyau Linux.
Pour le noyau 2.6.30 le nombre de patchs était de 11912 au 03 juin (11627 pour le 2.6.29) ce qui en fait un gros cycle de développement en terme de patchs.
Le nombre de développeurs impliqués dans le nouveau noyau s'établit à 1141 (une petite chute par rapport aux 1166 du noyau 2.6.29) et le nombre de lignes de codes modifiées est supérieur à un million et demi (avec un ajout net de 624000).
Ces deux graphiques permettent de comparer visuellement l'évolution du nombre de commits (en terme de patchs et de lignes) ainsi que l'évolution du nombre de contributeurs (en terme de développeurs et d'employeurs) pour chaque version entre le noyau 2.6.12, le premier à utiliser Git, et le noyau 2.6.30.
Sur les quatre années qui séparent ces deux noyaux on voit facilement que la tendance est à la croissance et que l'écosystème Linux est florissant.
Pour la suite… (↑)
En ce qui concerne les futures nouveautés des prochaines versions du noyau, on peut se tourner vers la page spécifique de la Fondation Linux.
- Une polémique ancienne et vénérable entre Pavel Machek (mainteneur du code de mise en veille/hibernation swsusp) et Nigel Cunningham (mainteneur du patch externe concurrent TuxOnIce) s'achemine peut-être vers une conclusion heureuse.
Ceux qui suivent la lkml depuis plusieurs années savent que les relations entre ces deux développeurs sont souvent acrimonieuses. Nigel est pesuadé que TuxOnIce est une solution techniquement supérieure à swsusp et il est frustré de ne pouvoir faire entrer son code dans la branche principale. Le 7 mai dernier il a posté une nouvelle demande d'inclusion qui récapitule les avantages de TuxOnIce a demandé son entrée dans le noyau 2.6.31 ou 2.6.32. Les amateurs de flame wars ont alors retenu leur souffle et se sont calés dans leur fauteuil avec une réserve de popcorn… mais, étrangement Pavel n'a pas fermé complètement la porte au nez de Nigel. Bien entendu il n'est pas question d'inclure TuxOnIce tout de go comme le souhaitait Nigel mais plutôt de décomposer ses fonctions en patchs distincts afin de les faire entrer progressivement dans la branche principale en améliorant swsusp. Comme l'écrit Pavel : "Pas d'ajout global d'un nouveau code et bazardage de l'ancien mais plutôt (..) prendre les meilleures idées de toutes les implémentations que nous avons sous la main".
Si Nigel peut oublier sa frustration et respecter le mode de développement du noyau Linux (qui lui a été à nouveau excellement expliqué) alors nous pourrions voir encore s'améliorer les fonctions de mise en veille/hibernation des futurs noyaux.
- Des parties du projet PaX, qui vise a renforcer la sécurité du noyau, pourraient finir par rentrer dans la branche principale de Linux. Larry Highsmith, se basant sur le code de PaX, a proposé un patch qui "nettoie" la mémoire vive au moment de la libération des pages mémoires (désallocation).
Actuellement cette mémoire est juste libérée et il suffit d'un bug dans le noyau pour permettre à un processus de lire des informations potentiellement sensibles (mot de passe, clé GPG, etc) mais, même sans bug, les attaques de type "cold boot" sont également envisageables.
Avec le patch de nettoyage la mémoire est vraiment effacée au moment de la libération et Larry Highsmith a listé toutes les vulnérabilités historiques du noyau qui auraient été évités si son patch avait été utilisé. Initialement le patch voulait marquer d'un drapeau (flag) les pages sensibles à nettoyer mais la solution consistant à tout nettoyer a finalement été choisie car il est très délicat de savoir ce qui est sensible et ce qui ne l'est pas. Une option lors du boot (sanitize_mem) permettra d'activer cette fonction qui pourrait apparaître dès le noyau 2.6.31.
Aller plus loin
- Les nouveautés du noyau 2.6.30 (44 clics)
- Le bilan des ajouts partie 1 (8 clics)
- Le bilan des ajouts partie 2 (4 clics)
- Les prévisions pour l'avenir de Linux (3 clics)
# Merci pour la dépêche et nouvelle amélioration : sommaire
Posté par Omnisilver . Évalué à 10.
C'est une nouveauté sur linuxfr ou c'est une fonctionnalité qui n'était pas utilisée jusqu'à présent ?
[^] # Re: Merci pour la dépêche et nouvelle amélioration : sommaire
Posté par patrick_g (site web personnel) . Évalué à 9.
C'est une amélioration qui m'avait été suggéré lors de la news du noyau précédent. J'avais posé une question sur ce qu'il était possible d'ajouter et l'idée du sommaire était revenue à plusieurs reprises.
Quand au bravo que tu décerne il doit aller à Floxy et Haypo qui ont corrigé le code html pourri et complètement cassé que j'avais posté initialement ;-)
[^] # Re: Merci pour la dépêche et nouvelle amélioration : sommaire
Posté par ZeroHeure . Évalué à 2.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Merci pour la dépêche et nouvelle amélioration : sommaire
Posté par Victor STINNER (site web personnel) . Évalué à 9.
[^] # Re: Merci pour la dépêche et nouvelle amélioration : sommaire
Posté par Florent Zara (site web personnel, Mastodon) . Évalué à 8.
Etant donné que LinuxFr supporte depuis quasiment le début un ensemble restreint de balises HTML (précisées en dessous du formulaire), je dirais que c'est une fonctionnalité, disponible depuis le millénaire précédent, et qui n'était pas utilisée jusqu'à présent. cf. http://tools.ietf.org/html/rfc1866#section-7.4
:)
# très intéressant
Posté par Dabowl_92 . Évalué à 10.
Vu son gabarit, je vais devoir demander un budget de deux heures pour "veille techno", je reviens après /o\
# Merci, merci et merci !!!
Posté par goom . Évalué à 10.
Outre la qualité rédactionnelle indéniable qui rend la lecture d'une limpidité, outre les nombreux liens qui viennent étayer les propos (et je n'ai pas cliqué sur tous !!), cette dépêche est un vrai régal.
N'étant pas du tout développeur, je ne saisis pas toutes les subtilités sous-jacentes, par contre j'éprouve un réel plaisir à avoir lu cette dépêche qui me fait pointer du doigt toute la complexité, aussi bien technique qu'humaine, du développement du noyau Linux que j'utilise au quotidien.
Il y a un côté magique à faire collaborer d'aussi nombreuses personnes d'horizons différents autour d'un tel projet et que cela me réjouit que de voir ça dans ce bas monde. (ça c'est pour le côté philosophique)
Bref, merci et plutôt trois fois qu'une
goomadmiratif
[^] # Re: Merci, merci et merci !!!
Posté par FantastIX . Évalué à 1.
[Ovation debout pour Patrick_G! \o/]
[^] # Re: Merci, merci et merci !!!
Posté par Mathias Bavay (site web personnel) . Évalué à 1.
Mathias
[^] # Re: Merci, merci et merci !!!
Posté par JP Martin . Évalué à 1.
Mais là, ça tape assez fort :)
Encore merci de nous tenir au courant sur l'évolution du noyau.
Vraiment super.
# En résumé
Posté par Philippe F (site web personnel) . Évalué à 2.
Il accélère aussi l'internet ?
[^] # Re: En résumé
Posté par claudex . Évalué à 5.
« 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: En résumé
Posté par scullder . Évalué à 2.
# Old school
Posté par Prae . Évalué à 3.
Ca me rappelle un vieux bug dans des systèmes/kernels Linux vers 98/99 où on devait faire fréquemment des ''sync'' (shell) pour éviter des pertes de données quand une coupure apparaissait ...
[^] # Re: Old school
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Old school
Posté par Prae . Évalué à 2.
[^] # Re: Old school
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: Old school
Posté par Mathieu Segaud . Évalué à 1.
jusqu'à cette date (milieu des années 90 je pense), de toute façon, TOUS (*) les systèmes *nix intégraient 3 appels à sync dans leurs scripts d'arrêt ou de redémarrage pour éviter que l'OS n'éteigne/redémarre avant que le disque n'ait fini d'écrire les données.
(*) les BSD notamment.
[^] # Re: Old school
Posté par tito (site web personnel) . Évalué à 1.
* * * * * sudo sync
? :D
# je vais me faire charrier mais...
Posté par NeoX . Évalué à 3.
à 10h22 GMT+1 il n'est toujours pas present là :
ftp://ftp.kernel.org/pub/linux/kernel/v2.6/
et il n'est pas sur la premiere page de http://kernel.org/
les admins de linuxfr.org seraient donc plus rapide que les admins de kernel.org à lire leurs emails :p
[^] # Re: je vais me faire charrier mais...
Posté par patrick_g (site web personnel) . Évalué à 8.
En ce qui concerne le téléchargement du noyau il faut un peu de temps pour la synchronisation du ftp.
[^] # Re: je vais me faire charrier mais...
Posté par Victor STINNER (site web personnel) . Évalué à 10.
[^] # Re: je vais me faire charrier mais...
Posté par pamputt . Évalué à 1.
# Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: A propos du changement ext3 / ext4
Posté par NeoX . Évalué à 8.
chez moi il prend de plus en plus de memoire et la vitesse de copie de fichier devient lamentable
je suis obligé de parfois demonter/remonter le peripherique pour reprendre ensuite la copie
ext2/ext3 je n'ai pas eu de probleme
ext4 est recemment installé sur un petit serveur et sur mon laptop,
et ca marche, mais il est vrai que je ne m'amuse pas à couper le courant pour voir si le FS tient ou si c'est le hardware qui va cramer en premier
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 6.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: A propos du changement ext3 / ext4
Posté par Olivier (site web personnel) . Évalué à 1.
Par contre, toujours dans cette même configuration, l'effacement d'un GROS fichier (plusieurs Go) est plus rapide pour du NTFS que pour de l'ext2/3. La raison est que l'ext2/3 doit rafraîchir une table qui indique quels sont les emplacements libres, alors que ce n'est pas la peine pour NTFS.
Enfin, concernant l'utilisation du NTFS sous Linux, je n'en vois pas l'intérêt (si ce n'est pour lire/écrire sur une clé/disque USB partagé avec un Windows, ou accéder à des données d'un Windows en dual boot).
Linux gérant mal les droits d'accès en NTFS, on y perd la protection apportée par le système de fichiers : Avec ext2/3, un utilisateur peut protéger ses données vis à vis des autres utilisateurs via les droits d'accès "chmod". Avec du NTFS, les droits sont définis pour tout le volume, lors du montage de la partition ("mount -t ntfs-3g -o uid=xxxx,gid=xxxx,umask=xxxx ...")
[^] # Re: A propos du changement ext3 / ext4
Posté par claudex . Évalué à 5.
« 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: A propos du changement ext3 / ext4
Posté par gpe . Évalué à 2.
Pas sur de bien comprendre ce que tu veux dire?
Pour moi le gros soucis du NTFS sur les disques externes ce sont justement les problèmes de droits...
[^] # Re: A propos du changement ext3 / ext4
Posté par claudex . Évalué à -1.
« 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: A propos du changement ext3 / ext4
Posté par Pascal Terjan (site web personnel) . Évalué à 10.
[^] # Re: A propos du changement ext3 / ext4
Posté par Olivier (site web personnel) . Évalué à 4.
Si, il y a des droits d'accès sur les partitions NTFS. Mais Linux a le bon goût (?) de mettre par défaut un accès en lecture/écriture pour tout le monde, donc personne n'est gêné avec cela.
Je suis d'accord que, mis à part le FAT, NTFS est un bon moyen d'échange de données entre OS différents (Linux / Windows de famille NT et supérieur). Mais pour ce qui est d'être le FS principal d'une distribution Linux, c'est à dire là où elle est installée sur le disque dur / SSD, ce n'est à mon avis pas un bon choix.
[^] # Re: A propos du changement ext3 / ext4
Posté par claudex . Évalué à 3.
même entre Linux, cfr. -> https://linuxfr.org/forums/10/27321.html
Mais pour ce qui est d'être le FS principal d'une distribution Linux
Là, ça n'a évidemment aucun sens.
« 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: A propos du changement ext3 / ext4
Posté par Olivier (site web personnel) . Évalué à 4.
Et pour les utilisateurs de Mac ou de *BSD, je ne suis pas sûr qu'ils puissent accéder à du NTFS.
Enfin, il reste le problèmes des brevets et de NTFS : http://fr.wikipedia.org/wiki/NTFS-3G . Pour l'instant, Microsoft n'attaque pas, mais qui sait ce qu'il se fera dans l'avenir (Microsoft a par exemple récemment attaqué TomTom avec un brevet sur la FAT, donc le risque existe).
[^] # Re: A propos du changement ext3 / ext4
Posté par claudex . Évalué à 2.
Cite n'y a pas besoin de ntfs-3g si on ne veut que de la lecture. Et le driver de lecture est beaucoup plus répendu. (même les mac l'ont).
« 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: A propos du changement ext3 / ext4
Posté par Grunt . Évalué à 9.
Depuis mon passage à GNU/Linux, je me suis juré de ne formater un disque externe en NTFS afin qu'il soit lisible sous Windows, que le jour où je verrai un windowsien formater son disque en ext2/3/4 afin que je puisse le lire. Quelque chose me dit que ce n'est pas demain la veille. :P
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
# Forme canonique d'écriture de fichier
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
open("MonFichier.temp")
write("MonFichier.temp")
fsync("MonFichier.temp")
close("MonFichier.temp")
rename("MonFichier.temp", "MonFichier").
devait être utilisé. Et si c'est lent il faut le mettre dans un thread.
Par contre, que faut-il faire pour une modification de fichier ? Comment avoir l'atomicité ? C'est fournis de base par le FS ou pas ?
En gros, si j'écris sur une partie d'un fichier, est-ce que j'aurais juste une partie modifiée en cas de crash ? Est-ce que mon fichier sera corrompu ?
Qu'est-ce que la bonne méthode ?
"La première sécurité est la liberté"
[^] # Re: Forme canonique d'écriture de fichier
Posté par Naha (site web personnel) . Évalué à 3.
open("MonFichier.temp")write("MonFichier")
fsync("MonFichier")
close("MonFichier")
Quel est l'intérêt de passer par un fichier temporaire ? Pour le cas où il y aurait une coupure de courant avant la fin de l'écriture ? Si l'on travaille sur un gros fichier (ou une partition trop pleine), on risque de ne pas pouvoir écrire le fichier temporaire pour cause de partition pleine, problème qui n'apparaîtrait pas si l'on écrasait le fichier directement.
Bon, ceci dit si la taille à ajouter au fichier est importante, on risque d'écraser le fichier sans pouvoir écrire la totalité de la nouvelle taille.
Question subsidiaire (naïve aussi) : où faut-il créer ce fichier temporaire ? Dans /tmp (perte de temps si /tmp n'est pas sur la même partition que le fichier de destination) ? Dans le même répertoire que le fichier de destination (plus logique mais problème de la partition pleine) ?
[^] # Re: Forme canonique d'écriture de fichier
Posté par Nicolas Boulay (site web personnel) . Évalué à 7.
L'important est la taille de la fenêtre de temps où tu n'as ni l'ancien fichier, ni le nouveau. Le rename est considéré comme très court, donc en cas de crash, tu as sois l'ancien, sois le nouveau fichier.
Dans ton cas, ta fenêtre inclus tous le "write", et c'est exactement ce que l'on veut éviter.
"La première sécurité est la liberté"
[^] # Re: Forme canonique d'écriture de fichier
Posté par Éric (site web personnel) . Évalué à 3.
Par contre dès le départ on m'a dit que potentiellement le fichier risquait d'être vide sur certains FS s'il y avait un crash au milieu : vide mais pas inexistant (l'écriture peut être en buffer dans l'os mais le rename ne serait jamais dans un état intermédiaire)
[^] # Re: Forme canonique d'écriture de fichier
Posté par claudex . Évalué à 2.
C'est exactement de quoi se plaignent les utilisateurs.
« 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: Forme canonique d'écriture de fichier
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Forme canonique d'écriture de fichier
Posté par Éric (site web personnel) . Évalué à 4.
man 2 rename : http://swoolley.org/man.cgi/2/rename
"" If newpath already exists it will be atomically replaced (subject to a
few conditions - see ERRORS below), so that there is no point at which
another process attempting to access newpath will find it missing. """
Ce n'est pas que la fenêtre est petite, c'est qu'elle n'existe pas (par contre le fait que le contenu du nouveau fichier soit sur disque ou en tampon, ce qui est la problématique de la news, ça ce n'est pas déterminé)
[^] # Re: Forme canonique d'écriture de fichier
Posté par reno . Évalué à 2.
D'accord.
>L'important est la taille de la fenêtre de temps où tu n'as ni l'ancien fichier, ni le nouveau. Le rename est considéré comme très court,
Plus exactement le rename est considéré comme 'atomique' donc normalement l'ordinateur t'assure que tu as soit l'ancien soit le nouveau (ne fonctionne qu'en local pas par NFS).
[^] # Re: Forme canonique d'écriture de fichier
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Oui, mais c'est faux. Ton disque dure et ses caches ne garantissent rien du tout en cas de perte d'alimentation (d'où l'utilisation du flag "barrier=1" de ext3 pour diminuer le risque mais aussi les perfs ).
"La première sécurité est la liberté"
[^] # Re: Forme canonique d'écriture de fichier
Posté par zerkman (site web personnel) . Évalué à 5.
Au moment du rename pour passer de l'ancienne version à la nouvelle, les deux fichiers (ancien et nouveau) existent et sont cohérents sur le disque. Et pour répondre à la question subsidiaire, il faut bien sur que les deux fichiers se trouvent sur le même système de fichiers, par exemple dans le même répertoire, car le rename ne fait que changer le nom, pas effectuer une copie de données.
[^] # Re: Forme canonique d'écriture de fichier
Posté par Anonyme . Évalué à 2.
Il faut qu'il soit sur le meme systeme de fichier pour que le rename puisse marcher. Et le plus simple pour etre sur de ca, c'est de le mettre dans le meme repertoire.
[^] # Re: Forme canonique d'écriture de fichier
Posté par Thomas Preud'homme . Évalué à 3.
[^] # Re: Forme canonique d'écriture de fichier
Posté par geb . Évalué à 1.
copy("MonFichier","MonFichier.temp") ?
[^] # Re: Forme canonique d'écriture de fichier
Posté par Anonyme . Évalué à 1.
[^] # Re: Forme canonique d'écriture de fichier
Posté par Sylvain Sauvage . Évalué à 5.
Ben non. Justement.
Extrait de man 2 close, section NOTES :
Une fermeture sans erreur ne garantit pas que les données ont été vrai‐
ment écrites sur le disque, car le noyau repousse les écritures le plus
tard possible. Il n’est pas fréquent qu’un système de fichiers vide les
tampons dès la fermeture d’un flux. Si vous désirez vous assurer que
les informations sont en sûreté sur le disque, utilisez fsync(2) (mais
des considérations matérielles entrent en jeu à ce moment).
[^] # Re: Forme canonique d'écriture de fichier
Posté par Anonyme . Évalué à 2.
[^] # Re: Forme canonique d'écriture de fichier
Posté par Naha (site web personnel) . Évalué à 4.
Notez que fclose() ne vide que les tampons fournis par la bibliothèque C dans l’espace utilisateur. Pour s’assurer que les données sont écrites physiquement sur le disque, il faut aussi vider les tampons du noyau à l’aide, par exemple, de sync(2) ou fsync(2).
[^] # Re: Forme canonique d'écriture de fichier
Posté par Anonyme . Évalué à 1.
En fait la dépêche dit "aucune garantie ENTRE write et close", ce qui m'avait conforté dans mon erreur. Je pense qu'il suffit de dire aucunte garantie après le close() sans fsync().
Ce qui n'enlève en aucun cas son excellence, à cette dépêche. ^^
[^] # Re: Forme canonique d'écriture de fichier
Posté par beagf (site web personnel) . Évalué à 2.
man 3 fclose
Notez que fclose() ne vide que les tampons fournis par la bibliothèque C dans l’espace utilisateur. Pour s’assurer que les données sont écrites physiquement sur le disque, il faut aussi vider les tampons du noyau à l’aide, par exemple, de sync(2) ou fsync(2).
Il faut vraiment un sync pour être sûr que les données soient bien écrites.
[^] # Re: Forme canonique d'écriture de fichier
Posté par Adrien . Évalué à 3.
une autre question de débutant :
Si j'écris sur le disque, à priori j'ai envie que ça soit écrit physiquement sur le disque. donc je vais toujours utiliser le sync ou fsync…
Quel est l'intérêt pour close et fclose de ne pas assurer ceci directement ?
[^] # Re: Forme canonique d'écriture de fichier
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
La seul que j'ai trouvé est qu'il doit y avoir des cas ou tu t'en fout et que tu veux juste de la performance.
Mais globalement, ces gesticulations pour écrire des données pour avoir l'atomicité est un peu bizarre.
En fait, il faudrait une fonction "soft" de sync, une fonction qui dit que l'écriture à effectivement eu lieu sans changer de priorité comme le fait sync() (done() ?). Le but serait de se foutre de la basse latence, mais de garder les performances et l'atomicité.
"La première sécurité est la liberté"
[^] # Re: Forme canonique d'écriture de fichier
Posté par Éric (site web personnel) . Évalué à 8.
L'intérêt c'est justement, comme dans la news, de mutualiser les appels disque pour les optimiser ou les regrouper. L'écriture disque coute cher, on évite de bloquer des processus pour ça inutilement en faisant des appels synchrones.
En très grande majorité des cas tu peux tout à fait vivre avec un décalage avant l'écriture des données. Tout n'est pas critique sur un système, et tous les systèmes n'ont pas une probabilités forte de crasher toutes les deux minutes. Ca me rappelle une mauvaise expérience de Firefox qui avait des mauvaises perf ou des freeze fut un temps à cause d'un trop grand nombre d'appels à fsync dans le sqlite qu'ils embarquent.
C'est, comme toujours, un compromis entre performance, confort et sécurité.
[^] # Re: Forme canonique d'écriture de fichier
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Forme canonique d'écriture de fichier
Posté par Mathieu Segaud . Évalué à 3.
tu veux dire quoi au juste ? :)
[^] # Re: Forme canonique d'écriture de fichier
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: Forme canonique d'écriture de fichier
Posté par Alexandre COLLIGNON (site web personnel) . Évalué à 5.
Alexandre COLLIGNON
[^] # Re: Forme canonique d'écriture de fichier
Posté par Sylvain Sauvage . Évalué à 6.
fsync(2) n’a de sens que pour les fichiers (dont les données sont) sur support physique.
Donc pas de fsync automatique pour chaque close.
(+ les questions de performances, p.ex. on peut vouloir grouper les fsync.)
[^] # Re: Forme canonique d'écriture de fichier
Posté par neologix . Évalué à 1.
En fait non.
Quand tu écris sur le disque, la seule chose qui t'importe, c'est de pouvoir lire ce que tu as écrit par la suite. Alors au lieu de forcer l'écriture sur disque, puis la lecture depuis le disque, autant garder le fichier en cache (en mémoire), comme ça tu te passes complètement d'accès disques.
[^] # Re: Forme canonique d'écriture de fichier
Posté par Laurent Morel . Évalué à 2.
Et si c'est lent il faut le mettre dans un thread.
OK dans un thread tu auras la main pour faire autre chose (cas d'un éditeur : sauvegarde temporaire par exemple). Mais dans le cas général où tu souhaite enregistrer un fichier et sortir du processus, le thread ne changera pas le problème de fond qui est que l'opération fsync() prend du temps : il ne paraît pas sain de terminer le processus avant que le fsync() n'ait rendu la main, donc avant que le thread n'ait terminé son travail ; donc on ne gagne pas temps dans ce cas là.
À noter que le rename() final effectue deux opérations d'un coup :
1 - effacer le fichier MonFichier
2 - renommer
Même si 1 et 2 sont atomiques (comme dit plus haut, vu du système, si rien ne crashe), l'opération 1 peut prendre un certain temps selon la taille du fichier et le système de fichiers.
[^] # Re: Forme canonique d'écriture de fichier
Posté par Troy McClure (site web personnel) . Évalué à 2.
tu forkes un nouveau process qui se charge de faire le fsync \o/
[^] # Re: Forme canonique d'écriture de fichier
Posté par Sylvain Sauvage . Évalué à 2.
[^] # Re: Forme canonique d'écriture de fichier
Posté par wismerhill . Évalué à 1.
[^] # Re: Forme canonique d'écriture de fichier
Posté par Thomas Preud'homme . Évalué à 3.
De plus il me semble plus approprié de faire une écriture asynchrone (il existe même une API posix pour cela) que de lancer un thread juste pour une écriture.
[^] # Re: Forme canonique d'écriture de fichier
Posté par wismerhill . Évalué à 5.
1 - effacer le fichier MonFichier
2 - renommer
Même si 1 et 2 sont atomiques (comme dit plus haut, vu du système, si rien ne crashe), l'opération 1 peut prendre un certain temps selon la taille du fichier et le système de fichiers.
Non, il n'y a pas deux étapes, c'est bien un rename (man 2 rename) qui est effectué et le système te garanti (à quelques cas particuliers près semble-t-il) l'atomicité de l'opération. Ce n'est qu'après le rename que le système de fichier peut éventuellement constater que les données pointées précédemment par le nom de destination n'ont plus aucun lien physique et les libérer.
# La vache...
Posté par blubliblo . Évalué à 0.
[^] # Re: La vache...
Posté par Dr BG . Évalué à 10.
[^] # Re: La vache...
Posté par blubliblo . Évalué à 10.
# NILFS
Posté par Patrick Nicolas . Évalué à 3.
Je dis ça parce que j'utilise un eeePC (un vrai avec de la mémoire flash bien lente en écriture) et j'aime bien faire des tests dessus, après btrfs qui met 50 ans à faire un umount et ext4 qui marche simplement bien j'ai bien envie de tester ce petit NILFS.
# Nettoyage de mémoire
Posté par Olivier (site web personnel) . Évalué à 3.
La partie sur le nettoyage de la mémoire après dé-allocation est très intéressante. Le lien que tu donnes sur http://citp.princeton.edu/memory/ montre bien le problème de la persistance des données en mémoire, et ce, même partiellement après l'arrêt de la machine.
Je pensais que la mémoire vive ne pouvait pas se conserver plus de quelque dixièmes de seconde après un arrêt électrique. Apparemment, c'est faux.
Il faudrait que les constructeurs de mémoire, ou ceux de cartes-mères, mettent en place un mécanisme de purge de la mémoire lors de l'arrêt de la machine. Par exemple, en drainant tout le courant résiduel de la RAM.
[^] # Re: Nettoyage de mémoire
Posté par Victor STINNER (site web personnel) . Évalué à 9.
Je pense que tu peux faire une attaque coldboot avec la machine en fonctionnement (extraire la barrette de mémoire alors que l'ordinateur tourne toujours). Si ton objectif est de lire le disque dur, tu peux débrancher le disque dur, arracher la mémoire (bon, pas sûr qu'elle soit contente), récupérer la clé (en mémoire) du disque dur, puis brancher le disque dur sur un autre ordinateur sain.
Il existe un projet visant à ne pas stocker les clés privées en mémoire : les clés ne seraient que présentes dans le cache du processeur (cache L1 je pense). Bon, après il doit être possible de lire la mémoire du CPU. Tout dépend des moyens qu'on se donne. Des ingénieurs d'IBM ont bien réussi à écrire dans le cache L1 d'un CPU avec un laser, et des hackers ont réussi à lire des clés de chiffrement Xbox en lisant ce qui passe sur le port PCI (je me souviens plus des détails) :-)
http://frozencache.blogspot.com/
[^] # Re: Nettoyage de mémoire
Posté par patrick_g (site web personnel) . Évalué à 6.
Finalement il semble que le patch de Larry Highsmith ne sera pas accepté dans le noyau Linux, du moins pas à court terme.
Les devs noyau ont posé pas mal de questions techniques à Larry et visiblement ils n'ont pas apprécié ses réponses ni son ton agressif et condescendant.
Pour plus d'infos lire cet article du site LWN qui sera en libre accès dès demain : http://lwn.net/Articles/335698/
[^] # Re: Nettoyage de mémoire
Posté par Kévin Belliz . Évalué à 2.
écrire dans la mémoire ça prend du temps, ça PERD même du temps !
Alors certe, le risque de coldboot où autre existe, mais frenchement à qui ça peut servir ? Y'a beaucoup de monde qui laisse son ordi avec des données extrement sensibles à la merci de type qui ont des moyens aussi énorme ?
M'enfin si c'est pas activé par défaut c'est pas un soucis de toute façon.
[^] # Re: Nettoyage de mémoire
Posté par claudex . Évalué à 10.
Bas, il y a mon mot de passe DLFP.
« 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: Nettoyage de mémoire
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
Ce que je veux dire par là, c'est qu'une technique complexe peut facilement s'industrialiser. Imagines un kit de récupération de PC portable en veille qui récupère les numeros de CB dans la mémoire des navigateur ouvert.
"La première sécurité est la liberté"
[^] # Re: Nettoyage de mémoire
Posté par Olivier (site web personnel) . Évalué à 2.
- On peut imaginer que cet effacement avant dé-allocation peut se faire pour un programme particulier, et dans ce cas, cela pourrait se réduire à un flag passé au processeur lors du lancement du processus ?
- Ou alors, on peut imaginer que l'on ait une fonction "securefree()", qui remplace par exemple la fonction free() du C. Cette fonction appelant alors un instruction kernel particulière, qui serait chargée de nettoyer la mémoire avant de la libérer.
Enfin, pour certains langages (comme le C/C++), ce mécanisme d'effacement peut être mise en oeuvre par le développeur lui-même. Une fois qu'il a finit de manipuler des variables sensibles, il peut les effacer lui-même avant de faire la libération de mémoire (le "free", ou la sortie de la fonction). Mais c'est un gros boulot.
[^] # Re: Nettoyage de mémoire
Posté par Maxime (site web personnel) . Évalué à 2.
Je ne sais pas à quel point la mémoire vive de la machine est comparable à celle de la carte graphique mais voila.
[^] # Re: Nettoyage de mémoire
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Le pire cas est à "chaud". Si on regarde une courbe du temps de perte de la charge par rapport à la température, c'est une belle exponentiel.
A 20°C, de mémoire, cela tourne autour de la seconde, largement de quoi survivre à un reset.
Il y a des techniques ou l'on verse de l'azote liquide sur les mémoires pour conserver l'état plusieurs minutes.
(pour mémoire la DRAM, ce sont des condos avec des fuites, à froid, il y a moins de fuites)
"La première sécurité est la liberté"
[^] # Re: Nettoyage de mémoire
Posté par Olivier (site web personnel) . Évalué à 4.
Mais ce phénomène n'apparaît que si je reboote ma machine. Pas si j'ai fait un démarrage depuis un power-off.
Je suppute que cela vient du faite que durant un reboot, la mémoire vive de ma carte graphique n'est pas réinitialisée.
# Superbe dépêche
Posté par Sphax . Évalué à 3.
J'attendais cette nouvelle version principalement car j'ai lu que KMS serait disponible par défaut pour les cartes ATI.
Je lis que le support des cartes R6xx et R7xx est intégré, mais qu'en est-il pour KMS donc ?
[^] # Re: Superbe dépêche
Posté par Victor STINNER (site web personnel) . Évalué à 7.
Details: The infrastructure is all in place. The driver details are as follows: For AMD/ATI hardware, R300 and newer has KMS enabled by default; R100-R200 does not yet have 3D support with KMS, so is default to disabled (this has been targeted for Fedora 11). For Intel hardware, we default to disabled (targeted for Fedora 11).
http://fedoraproject.org/wiki/Features/KernelModesetting
Le détail :
http://fedoraproject.org/wiki/Features/IntelKMS
http://fedoraproject.org/wiki/Features/NouveauModesetting
http://fedoraproject.org/wiki/Features/Radeon3DUpdate
Par contre, vu que Fedora 11 est sorti avant le noyau 2.6.30, il utilise forcément le noyau 2.6.29.
[^] # Re: Superbe dépêche
Posté par Mjules (site web personnel) . Évalué à 5.
Sinon, Fedora utilise déjà un noyau modifié pour gérer KMS avec les ATI/AMD.
[^] # Re: Superbe dépêche
Posté par Ririsoft . Évalué à 4.
Sous Fedora 11 (kernel 2.6.29 avec patch KMS) avec KMS activé j'ai des freezes réguliés que ce soit avec le driver radeon ou radeonhd. J'ai du désactiver KMS.
J'attend avec impatience l'inclusion du noyau 2.6.30 dans F11 pour savoir si 1- Le KMS marchera mieux, 2- Ce que donne l'accélération 2D EXA et 3- Ce que donne DRI2 pour la 3D (experimental) avec les cartes ATI R6xx.
Pour en savoir plus :
http://www.x.org/wiki/radeon
http://www.x.org/wiki/radeon%3Ar6xx_r7xx_branch
http://www.x.org/wiki/radeonhd
[^] # Re: Superbe dépêche
Posté par Ririsoft . Évalué à 2.
Je pensais juste qu'ils avaient backporté les patch KMS dans le 2.6.29. Apparemment ils ont fait plus !
Mais j'arrive pas à savoir si EXA est activé par défaut ou pas. Pour le radeonhd je ne crois pas (cf http://www.x.org/wiki/radeonhd%3Ar6xx_r7xx_branch)
Je vais essayé tout ça dès mon retour à la maison !
Ah j'oubliais un lien sympa aussi :
http://fedoraproject.org/wiki/Common_F11_bugs#Miscellaneous_(...)
Si vous avez des problèmes avec ATI ou Intel et les nouveaux patchs KMS ça vous sera utile.
# Nombre de lignes de code du noyau
Posté par Sébastien Wilmet . Évalué à 4.
Who last touched kernel code lines
Lines Pct Who
4063723 35.17% Linus Torvalds
Ça veut donc dire que le noyau fait presque 12 millions de lignes de code ! Et moi qui avait en tête que c'était de l'ordre de 6 millions...
Et effectivement j'ai téléchargé les sources et compté le nombre de lignes (en gardant les commentaires), et rien que pour les fichiers *.c il y un a pour 8196233, et pour les fichiers *.h c'est 1917320...
[^] # Re: Nombre de lignes de code du noyau
Posté par patrick_g (site web personnel) . Évalué à 6.
[^] # Re: Nombre de lignes de code du noyau
Posté par steckdenis (site web personnel) . Évalué à 5.
Ohloh nous propose un joli petit graphique ici : http://www.ohloh.net/p/linux/analyses/latest .
C'est impressionnant un tel nombre de lignes ! (et ce qui m'étonne aussi est la régularité de l'augmentation du nombre de lignes).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.