Le développement d'ext4 a commencé

Posté par  . Modéré par Jaimé Ragnagna.
Étiquettes :
0
1
juil.
2006
Linux
Suite à la proposition de différents patchs pour ext3 (la dernière mouture du système de fichiers spécifique à Linux) par des développeurs du noyau, une discussion a eu lieu sur la LKML entre ceux en faveur de changement mettant potentiellement à mal la stabilité du noyau et ceux qui préféreraient aller de l'avant, laissant les problèmes de stabilité aux distributeurs (rappelons que ceci est officiellement la nouvelle politique du noyau, bien que les développeurs évitent bien sûr autant que possible de tout casser).
Étant donné la base d'utilisateurs d'ext3, les inquiétudes portant sur la stabilité du code et du format sur disque après intégration de patchs importants ont été nombreuses, et Linus y a été particulièrement sensible (étant donné qu'un système de fichier instable mettrait en péril le travail des développeurs qui l'aident, on peut le comprendre).
Il a donc été décidé d'ajouter un système de fichier ext4 dans le code du noyau, et de faire les changements dangereux sur celui-ci. La stabilisation du code est prévu dans environ 12 à 18 mois, bien que de nombreuses améliorations seront probablement proposées.
L'article qui suit est une traduction complète du mail de Théodore Ts'o (mainteneur, avec d'autres, d'ext2/3) détaillant le mode de développement prévu pour ext4.

NdM Merci a patrick_g de nous avoir proposé une dépèche sur le même sujet. Étant donnée la récente discussion sur la LKML il y a deux semaines, il est clair que de nombreuses personnes s'intéressent aux plans futurs de développement du système de fichiers ext2/ext3, étant donné qu'il est un des systèmes de fichiers plus populaires et les plus couramment utilisés, en particulier parmi la communauté des développeurs du noyau.
Pour cette raison, les intérêts qui lui sont portés sont plus importants qu'ils ne le seraient pour d'autres systèmes de fichiers. Les inquiétudes exprimées peuvent se résumer aux points suivants:

* Stabilité. Une des inquiétudes soulevées est que durant l'ajout de nouvelles fonctionnalités, des erreurs de programmation puisse causer la perte du travail des développeurs. C'est particulièrement problématique étant donné que le noyau 2.6 est un noyau de série "stable", mais traditionnellement les développeurs ext2/3 ont été très attentifs même lorsqu'ils travaillaient sur les séries de développement car les développeurs du noyau ont tendance à ne pas apprécier lorsque leur système de fichiers est corrompu.

* Confusion autour de la compatibilité. Bien que le "superblock" de ext2/3 soit très flexible et puissant au regard de l'indication de compatibilité ascendante et descendante, la possibilité de confusion des utilisateurs a provoqué l'inquiétude de certains, au point qu'il ait été proposé de volontairement casser la compatibilité descendante afin de supprimer tout doute possible quant à la compatibilité ascendante. Cela serait aller trop loin, bien que nous n'ayons pas besoin de mettre en garde contre du code au niveau noyau ou distribution qui mettrait sans avertissement préliminaire à jour le système de fichiers d'un utilisateur, l'empêchant de monter celui-ci sur de plus vieux systèmes. Une confirmation de l'utilisateur doit être obtenue, de préférence par un outil qui permettra une mise-à-jour ou une remise à l'ancienne version avec facilité.

* Complexité du code. Le troisième sujet d'inquiétude est que si le code n'est pas correctement factorisé, il pourrait devenir difficile à lire à cause des nombreuses conditions utilisées pour supporter les formats de système de fichiers plus anciens.

Malheureusement, ces différents sujets étaient parfois mélangés les uns aux autres dans la discussion d'il y a deux mois, et il était par conséquent difficile de progresser.
Les inquiétudes de Linus semblent avoir porté principalement sur le premier point, avec peut-être une faible considération du troisième. D'autres se sont particulièrement préoccupés du second.

Pour répondre à ces préoccupations, après en avoir discuter entre nous, les développeurs ext2/3 voudraient proposer de suivre le chemin suivant.

1) La création d'un nouveau système de fichiers dans l'arbre des sources du noyau 2.6 dans /usr/src/linux/fs/ext4 qui se présentera d'abord comme le système de fichiers "ext3dev". Il sera marqué explicitement comme CONFIG_EXPERIMENTAL [NdT: tag des fonctionnalités expérimentales lors de la configuration d'un noyau Linux avant sa compilation], et sera en réalité un fork de développement d'ext3. Une séparation similaire aura lieu pour fs/jbd [NdT: le code du journal utilisé par ext3] afin de supporter un jbd 64-bits, qui sera utilisé par fs/ext4 et les versions futures d'ocfs2 [NdT: le système de fichier pour clusters d'Oracle].
2) Les corrections d'erreurs de programmation du point de vue de la propreté du code 32-bits et des problèmes de sécurité/de oops iront dans fs/ext3, mais tous les nouveaux développements iront dans fs/ext4.
Il y a un quelques incertitudes encore quant au fait que les fonctionnalités peu risquées telles que la réduction de l'emprunte mémoire de la structure de extX, et des allocations retardées pour ext3, qui n'ont pas d'impact sur le format, devraient aller dans fs/ext3, ou si de telles améliorations devraient être réservées aux utilisateurs de fs/ext4. Ceci est un compromis coût/bénéfice pour lequel la communauté de la LKML devra décider si les pertes en stabilité du code valent les améliorations pour les utilisateurs actuels de ext3, étant donné l'existence de la branche de développement.
De plus, nous supposons que différents changements impliquant des modifications du format, telles que le support d'horloges plus précises, ne vont _pas_ être intégrées dans le code de fs/ext3, et que les gens qui veulent ces fonctionnalités devront utiliser le code stable/de développement de fs/ext4.

3) Le code de ext4 continuera de monter les systèmes de fichiers plus anciens en ext3, puisqu'il est nécessaire de s'assurer une mise-à-niveau sans accroc pour les utilisateurs depuis ext3 vers ext4. De plus, une fois une fonctionnalité ajoutée au système de fichier ext3dev, un gros effort sera fourni afin de continuer de supporter les améliorations du format du système de fichier vers l'avant, exactement comme nous le faisons avec l'ABI syscall. (Des urgences peuvent avoir lieu si nous faisons une grave erreur et que nous nous mettons le dos au mur; mais exactement comme nous le faisons pour les changements dans l'ABI noyau/espace utilisateur, s'il est question de savoir si oui ou non un format de système de fichiers particulier peut être supporté tout en continuant sans cesse d'aller de l'avant, nous ne validerons les changements dans le code principal du noyau qu'une fois en confiance sur ce point.)

4) À un moment donné, probablement dans 6-9 mois quand nous serons satisfaits de l'ensemble des fonctionnalités qui auront été ajoutées à fs/ext4, et que nous aurons confiance dans la stabilité du format du système de fichiers, nous soumettrons un patch qui fera que fs/ext4 se présentera comme le système de fichiers ext4. L'implémentation nécessitera peut-être encore quelques vérifications avant que nous soyons aussi confiants dans sa stabilité que dans celle d'ext3 actuellement. À ce moment, peut-être dans 12-18 mois, nous demanderons éventuellement que le code dans fs/ext3/* soit supprimé et que fs/ext4 se présente comme supportant le système de fichiers ext3 également.
Nous croyons que ceci devrait répondre à la majorité des inquiétudes qui ont été soulevées, en particulier celles de Linus et Jeff. Les commentaires sont évidemment les bienvenus.

- Ted

Aller plus loin

  • # compatibilité ?

    Posté par  . Évalué à 3.

    Ne serait t'il pas plus simple d'essayer de faire un systeme comme partition magic qui permet de convertir des partitions d'un type en un autre type, tout en conservant les données et de considérer la compatibilité descendante/ascendante comme réglé par ce problème ?
    Cela permettrait d'avoir a éviter de réinventer la roue a chaque fois quand on vois qu'il peut y avoir des initiatives interessantes comme reiser4 (qui pompe malheureseusement actuellement énormément de cpu sur un dd fragmenté pour l'écriture de gros fichiers :( (en tout cas chez moi) ) ou zfs.

    • [^] # Re: compatibilité ?

      Posté par  . Évalué à 2.

      C'est vrai que avoir un outil de conversion entre les différents systèmes de fichier apporterait un bénéfice certain à mon sens.

      J'aimerai bien essayer Reiser4, mais je suis quasiment obligé de formater mes partitions pour pouvoir faire ça.

      Si j'essaye de me mettre à la place de l'utilisateur "basique", ce qu'il est à mon sens bon de faire pour pouvoir espèrer propager Linux autant que possible, et bien ce n'est pas trivial.

      Je n'ai pas des connaissances techniques suffisantes c'est pourquoi je pose la question: est-il possible et envisageable d'avoir un outil de conversion entre les différents systèmes de fichier un jour?

      • [^] # Re: compatibilité ?

        Posté par  . Évalué à 4.

        Et il serait aussi intéressant de pouvoir modifier une partition montée avec (g|qt)parted, parce que quand on veut bosser sur la partition racine, il reste plus qu'à utiliser un CD amorçable.

        Windows peut « verrouiller » ses partitions pour les modifier, ça doit donc être envisageable sous Linux...

    • [^] # Re: compatibilité ?

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

      Le problème de ZFS c'est qu'il est sous la licence libre de Sun qui a été spécifiquement conçue pour empécher la reprise du code dans un projet GPL comme Linux. Dommage car d'après ce qu'on lit à droite et à gauche c'est vraiment un FS qui roxe monstrueusement.
      Pour Reiser4 ce sont, je crois, les devs du noyau qui rechignent à l'intégrer du fait de son interfaçage peu orthodoxe avec le virtual file system de Linux.

      • [^] # Re: compatibilité ?

        Posté par  . Évalué à 2.

        mais les specs sont libres quand meme , pas comme ntfs qui est pourtant dans le noyau (avec l'écriture toujours en expérimental) ;)
        D'ailleurs on peut pas faire un module a compilé a coté ? Un peu comme les drivers nvidia sauf que la c'est quand meme libre (meme si pas compatible gpl v2 (mais gpl v3 non ?)
        puis il reste fuse sinon non?
        Reste a voir les perfs de fuse.

        • [^] # Re: compatibilité ?

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

          Ben oui on pourrait étudier le source de ZFS et le réécrire pour Linux. Cela sera d'aillers sans doute fais un jour ou l'autre mais ça risque d'être long et difficile car les ingés de Sun ont mis des années de tuning avant d'avoir un système optimal.
          Si le boss de Sun était pas trop con il switcherai la licence de ZFS et de Solaris vers la GPL. Après l'incorporation de pleins de bouts de code des deux cotés par cross-pollinisation Sun serait en position de force pour vendre son expertise et ses services.

          • [^] # Re: compatibilité ?

            Posté par  . Évalué à 4.

            Si le boss de Sun était pas trop con il switcherai la licence de ZFS et de Solaris vers la GPL.
            si les dvp linux étaient pas trop con ils switcherait en gplv3 :-d

            La gpl n'est pas la seule et unique licence libre au monde.
            Sun offre du libre avec toutes les libertés que ca implique. Je ne vois aucune raison pour imposer une licence qui ne leurs convient peut etre pas.

            /me propose l'arret du troll cddl/gpl car de toute facon ca n'apportera pas grand chose ;)

            • [^] # Re: compatibilité ?

              Posté par  . Évalué à 3.

              si les dvp linux étaient pas trop con ils switcherait en gplv3 :-d
              La gplv3 change quoi à ce sujet ?

              Sinon, si le noyau était en LGPL, on pourrait avoir des modules noyau sous d'autres licences et ça résoudrait aussi le pb non ?

              • [^] # Re: compatibilité ?

                Posté par  . Évalué à 3.

                ben je croyais que la gplv3 était compatible cddl , mais peut etre que je me trompe.

                toujours est il que le ceo de sun est pas aussi con que certains veulent le faire croire ;)
                http://blogs.sun.com/roller/page/jonathan?entry=hp_and_sun_p(...)
                ensuite j'espère
                1°) Que ce n'est pas juste une annonce sans rien derrière
                2°) Que la gplv3 est compatible gplv2 (ce qui n'est pas sur pour moi vu que cette dernière n'as pas de protection contre les drm !)

      • [^] # Re: compatibilité ?

        Posté par  . Évalué à 2.

        A propos de Reiser4, je me souviens avoir lu dans un Login: il y a quelques années qu'il devait être intégré au noyau et qu'en théorie, c'était le système de fichiers ultime. Je me suis toujours demandé pourquoi ça ne s'est pas fait finalement ?

        • [^] # Re: compatibilité ?

          Posté par  . Évalué à 3.

          atome crochu entre celui qui décide des fs qui rentre dans le noyau et le responsable de reiser4.
          (désolé je connais pas les noms)
          En gros celui qui décide des fs qui rentre aimaient pas certains truc sur le code, dont certains était justifié , d'autre non.
          Et le responsable de reiser 4 a fait valoir que xfs qui est pourtant dans le noyau était beaucoup plus sale.
          Ca c'est terminé (d'après ce que j'ai pu en lire il y a longtemps) par un truc genre 'tant que je serais la ton fs sera pas dans le noyau' ou autre connerie du meme genre.

          • [^] # Re: compatibilité ?

            Posté par  . Évalué à 8.

            Atomes crochus, ca veut dire l'inverse de ca que tu veux dire, je crois ;)

            • [^] # Re: compatibilité ?

              Posté par  . Évalué à 5.

              En effet. Pour rester dans les trucs plus ou moins crochus, on pourrait parler de prises de bec plutôt.

          • [^] # Re: compatibilité ?

            Posté par  . Évalué à 3.

            Je ne me souviens plus du nom du dev Linux, mais pour le responsable de reiser4, c'est Hans Reiser, très réputé pour sa diplomatie ;-)

            Il avait déja eu du mal a mettre le premier reiserfs dans le kernel bien ce soit le premier fs journalisé pour Linux, en grande partie a cause de sa grande gu.... .

            Maintenant la concurrence est plus rude, mais Hans n'a pas changé donc reiser fs 4 dans Linux AMHA ce n'est pas pour demain.

            Bon juste pour l'anecdote, reiserfs est un des seuls système de fichier a m'avoir perdu une partition (les outils de récupération n'ont pas fonctionné), et je reste un peu sceptique de l'interet de journaliser uniquement les métadonnées: quand on se retrouve avec le /etc/passwd qui contient du binaire, ça fait mal (aussi avec reiserfs) --> je pense qu'ext3 en journalisation donnée+métadonnée, c'est *bien*(TM).

            • [^] # Re: compatibilité ?

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

              un article long et détaillé qui explique le problème de l'inclusion ou pas de reiser4 dans le noyau : http://lwn.net/Articles/152548/

              Résumé en très gros : pour l'instant il n'est pas en mainline pour des raisons techniques et des raisons de prise de bec avec Hans Reiser qui ne veut pas se soumettre aux demandes des hackers Linux.

            • [^] # Re: compatibilité ?

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

              Bof, anecdote pour anecdote, le très réputé xfs (de chez SGI, super éprouvé, industriel et tout) m'en a perdu 2, définitivement. Il ne faut pas lui demander de trop gros transferts simultanés (cd vers disque dur et disque dur vers lui même sur de gros fichiers sur un portable avec un disque lent par exemple).

              Reiser4, que j'ai un peu essayé, s'est lui emmelé les pinceaux deux fois, mais à pu se récupérer à chaque fois. Par contre il donne une impression de rapidité extrème...

              Ceci dit, tant qu'il ne sera pas dans le noyau, il ne sera pas débuggé, ni utilisable facilement, et il risque donc de stagner...

              • [^] # Re: compatibilité ?

                Posté par  . Évalué à 1.

                " Reiser4 (...) donne une impression de rapidité extrème... "

                Eh bien, en une phrase, tu me fais presque saliver ! Est-ce que tu pourrais préciser qu'est-ce qui te fait dire ça ? Qu'est-ce qui est plus rapide ? Le démarrage de la machine ? Les applications ? La réactivité générale ?

                • [^] # Re: compatibilité ?

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

                  Attention de bien me lire : "une impression". Du coup, tout ça est très subjectif, mais c'est en particulier la vitesse de démarrage de la machine, la vitesse d'affichage sous Nautilus, les mises à jour d'une grosse arborescence sous Subversion !

                  Bref, très bonne impression d'ensemble pour les accès disques. Je ne crois pas que les applications elle-mêmes soient très impactées bien sûr.

                  Ce qui me retient d'utiliser Reiser4 par défaut, c'est :

                  - pas intégré au noyau de ma distribution (Ubuntu), et ce noyau est bien pratique car il permet d'installer des modules non libres (dans un paquet dédié) dont ma carte wifi et ma carte video ! Si je veux installer Reiser4, il faut aussi que j'installe à la main les modules propriétaires, et ce à chaque mise à jour de version :-(

                  - pas de support des xattrs, donc de Beagle (quoique j'en suis revenu de Beagle, ça n'a jamais bien marché chez moi...)

                  Néanmoins, si tu le peux, je te conseille d'essayer Reiser4, avec une petite sauvegarde de temps en temps au cas où :-)

    • [^] # Re: compatibilité ?

      Posté par  . Évalué à 10.

      Voyons, un programme pour convertir un système de fichiers en un autre système de fichiers... on pourrait même l'appeler convertfs, ce serait clair comme nom.

      Ah, mes doigts deviennent indépendants, que tapent-ils ?
      $ apt-cache show convertfs
      [...]
      Description: in-place filesystem conversion
      This simple toolset allows you to change type of file system in the lack of
      backup space. You can convert from virtually any filesystem type to virtually
      any one as long as they are both block-oriented and supported by Linux for
      read/write, and as long as primary filesystem supports sparse files.
      [...]
      Traduction rapide :
      Description : conversion « sur place » de système de fichier
      Cette boîte à outils simple vous permet de changer le type d'un système de fichier en cas de manque d'espace de sauvegarde. Vous pouvez convertir de virtuellement tout type de système de fichiers vers virtuellement n'importe quel autre, du moment que les deux sont orientés bloc et supportés en lecture/écriture par Linux, et que le système de fichiers d'origine supporte les fichiers éclatés.

      • [^] # Re: compatibilité ?

        Posté par  . Évalué à 2.

        je connaissais pas, au temps pour moi alors ;)
        (et merci de m'avoir fait découvrir ca ;))

        • [^] # Re: compatibilité ?

          Posté par  . Évalué à 3.

          je me répond à moi même , mais convertfs marche pas (en tout cas chez moi) pour une conversion reiser4 -> ext3

  • # lwn

    Posté par  . Évalué à 5.

    lwn proposait un article assez complet sur ext3 et le pourquoi de partir sur ext4 : http://lwn.net/Articles/186754/

  • # GFS, drbd, cluster

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

    Ce qu'il manque le plus à Linux concernant les systèmes de fichiers, c'est l'intégration de système de fichiers clustérisé tel que GFS, Lustre, GPFS, PVFS.

    Il y a bien OCFS qui a récemment intégré le kernel, mais comme son nom l'indique il est plus destiné aux bases de données. Il n'y a rien à l'heure actuel pour les cluster de calculs hautes performances.

    L'autre importance d'avoir un système de fichiers clustérisé et de pouvoir faire du raid réseau avec drbd en configuration actif-actif. Là encore rien n'est intégré en standard dans le tronc commun.

    Résultat, lorsque l'on cherche de la haute performance et de la haute disponibilité on est obligé de jongler avec les compromis ou avec du matériel hors de prix :(

    ext4 ne me parait pas être la priorité du moment, ext3 étant quand même le plus performant des systèmes de fichiers existant (ce n'est pas un troll, j'ai des benchs mais les résultats ne sont pas un modèle de clarté :o) http://redfox.redfoxcenter.org/benchs/ ).

    • [^] # Re: GFS, drbd, cluster

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

      boarf Lustre et autre c'est tellement spécialisé que ce n'est pas crucial d'intégrer le noyau mainline du moment que des patchs propres existent. Les utilisateurs de ces FS spéciaux sont de toutes façon des spécialistes (Lustre c'est pour les superordinateurs) et cela ne les embète pas de tuner/modifier/patcher leur kernel puisqu'ils le font en permanence pour gratter un peu de perf.

      Sinon, autre sujet, je trouve que le mail de Ts'o manque singulièrement de détails sur les modifs qui entreront dans ext4. Il évoque juste la procédure de transition mais on ne sait rien sur les nouveautés. On sait juste que la capacité du FS ne devra plus se limiter à 32 bits (8 teraoctets) mais passer à au minimum 48 bits (voir les patchs de Mingming Cao qui permettent, en passant à des blocs 48 bits, d'avoir une capacité de stockage de 1024 petaoctets).

      • [^] # Re: GFS, drbd, cluster

        Posté par  . Évalué à 1.

        A noter que certains patchs pour le client Lustre ont ete integres dans le noyau et que les dev de Lustre prevoient de pouvoir faire un client sans avoir a patcher le noyau dans un futur proche.

      • [^] # Re: GFS, drbd, cluster

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

        Quel est l'intéret d'un codage des adresses de bloc en 48 bits ? Pourquoi ne pas faire du 64 bits directement?

    • [^] # Re: GFS, drbd, cluster

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

      GFS étant maintenant GPL, et appartenant à une boîte qui a plutôt tendance à tout reverser upstream (Red Hat), est-ce que tu sais pourquoi c'est pas encore intégré ?

  • # content-type dans le filesystem

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

    Une question, pourquoi est-ce que le type des fichiers n'est pas stoké dans le filesystem à coté des permissions ou de ces choses là. Cela simplifirait quand même.
    Fini les extensions, fini la détection de type parfois foireuse ...

    • [^] # Re: content-type dans le filesystem

      Posté par  . Évalué à 4.

      >fini la détection de type parfois foireuse

      Bôf, uniquement si
      1) la base de données contient le type de donnée recherché
      2) le remplissage de cette information est faite: donc si *tous* les programmes étaient modifiés pour rajouter cette information..

      Et il faut faire attention au coté sécurité de la chose: que se passe t'il si un attaquant déclare un exécutable comme une image?

      • [^] # Re: content-type dans le filesystem

        Posté par  . Évalué à 2.

        Le lecteur d'image ne saura pas la lire.

        (Mode=radotage) BeOS le faisait il y a presque dix ans et ça marchait très bien (il faut dire que le système et son API favorisaient la chose).

        BeOS le faisait il y a 20 ans !

        • [^] # Re: content-type dans le filesystem

          Posté par  . Évalué à 3.

          Bin oui, mais pour BeOS toutes les applications ont du être codés pour fonctionner sur BeOS..

          Je ne dits pas qu'il y a un probleme fondamental, jusqu'il faut modifier *toutes* les applications autrement tu te retrouves avec un système ou l'attribut type est rempli 10% du temps, ce qui augmente la complexité sans vrai gain..

          Personellement si je pouvais avoir une feature de BeOS sur Linux, ce serait la réactivité: en utilisant une thread dédié a la gestion de la fenetres, les interfaces étaient bien plus réactives, ce qui était très agréable a utiliser.

          Mais comme, la encore, cela nécéssite de modifier *toutes* les applications pour que ce soit un réel progrès, ce qui n'est pas près d'arriver..

    • [^] # Re: content-type dans le filesystem

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

      C'est pas tellement necessaire, vu que le tout le monde utilise la libmagic... à la rigueur on peut même se dire que ça dupliquerais des informations disponibles dans l'entête.
      Enfin, je suppose qu'on pourrait effectivement dire à cette lib de mémoriser le résultat de ses investigations dans un xattr, mais je m'attends pas à ce que les performances s'envolent (sans parler des problèmes sur les fichiers en lecture seul).

      Sinon, même sans hacker la libmagic on pourrais probablement ajouter la mémorisation aux composants des bureaux qui identifient les types de fichiers. Ça serait un peu moins gore, mais pas tellement plus utile.

  • # Politique de développement du noyau.

    Posté par  . Évalué à 4.

    Salut.

    laissant les problèmes de stabilité aux distributeurs (rappelons que ceci est officiellement la nouvelle politique du noyau, bien que les développeurs évitent bien sûr autant que possible de tout casser).


    Il n'y a que moi que ça choque?

    En passant, certains d'entre vous compte-t-ils utiliser la branche 2.6.16.y (http://kerneltrap.org/node/6386) ? Parce que si cette politique est effectivement la politique officielle, pour une machine en production, on n'aura plus le choix

    • [^] # Re: Politique de développement du noyau.

      Posté par  . Évalué à 7.

      Je te renvois ici: http://kerneltrap.org/node/3513 (lien que je voulais mettre dans la news, étant donné que je m'attendais à ce que la partie que tu cites soulève des questions, mais j'ai oublié).
      Traduction de la partie qui nous concerne dans le lien ci-dessus:
      La façon dont Andrew voit les choses, comme il l'a dit durant le "sommet" [NdT: le Kernel Developer Summit, ou conférence des développeurs du noyau], est que le noyau mainline [NdT: le noyau d'origine de kernel.org] sera le plus rapide et le plus complet d'un point de vue fonctionnalités, mais pas, nécessairement, le plus stable. La stabilisation finale devra être effectuée par les distributeurs (c'est déjà le cas, en réalité), mais nous espérons des distributeurs qu'ils intégrent leurs changements rapidement.

      Autrement dit, c'est ce que j'ai écrit dans l'article: les développeurs noyau, bien que ce ne soit plus leur principale considération, font tout de même autant que possible attention à la stabilité. Cependant, et ça a toujours été un peu le cas, les distributions sont invitées à tester la stabilité du noyau avant de le distribuer, et à envoyer leur modifications en amont le cas échéant.

      • [^] # Re: Politique de développement du noyau.

        Posté par  . Évalué à 4.

        Je suis d'accord, c'est effectivement la nouvelle politique officielle.
        Ce qui me choque, c'est la politique en elle même. En gros, "on implémente de nouvelles fonctionnalités, mais la stabilité, ce n'est pas notre problème". C'est d'ailleurs pour cela qu'Adrian Bunk a décidé de maintenir une branche -stable. Je suis étonné que la stabilité/sécurité ne soient pas les objectifs premiers visés par les responsables/développeurs...

  • # Pourquoi pas Reiser4 ?

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

    Pourquoi ne pas utiliser Reiser4 http://www.namesys.com/ qui est un FS vraiment nouveau, innovant et extrèmement performant ?
    J'ai vraiment l'impression qu'il s'agit du syndrome NIH (not invented here) qui vient encore de frapper.

  • # Nouveautés

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

    Qu'en est t'il exactement des nouveautés qui seront apportées par cette version ?

    • [^] # Re: Nouveautés

      Posté par  . Évalué à 2.

      Principalement le support de systèmes de fichier de très grande capacité. La limite actuelle est de 8 TB, ce qui commence à être un peu juste (pas encore pour l'utilisateur lambda bien sûr...).

      La nouvelle version permettrait d'aller jusqu'à 1024 PB (c'est quelle unité ça?).

      cf. http://lwn.net/Articles/187321/

      • [^] # Re: Nouveautés

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

        Le PB veut dire PétaByte.
        1 PétaByte = 1024 TeraByte
        1024 PétaByte = 1 ExaByte.

        Pour le support de systeme de fichier de très grand capacité, la demande est-elle vraiment importante ? Qu'est-ce que ext4 apportera à l'utilisateur moyen ? Vont-t'il optimiser le code pour gagner en perf ?

        • [^] # Re: Nouveautés

          Posté par  . Évalué à 5.

          Le principe d'ext4 est de permettre l'intégration de nouvelles fonctionnalités dans le code d'ext3 par rapport à des contraintes de compatibilité et stabilité.

          Les fonctionnalités actuellement en attente, qui ont été plus ou moins les éléments qui ont provoqué cet événement (mais ce problème était déjà latent, elles n'ont fait de relancer le débat), sont d'une utilité infime pour l'utilisateur lambda. Elles ne concernent que des utilisations à très grandes capacités.
          Je cotois quotidiennement des filesystems de plusieurs Peta. Ces filesystems utilisent ext3 comme sous système de fichiers et, avec ce niveau de stockage, des partitions de 2 To deviennent étroites.

          Bref, pour résumé, les prochaines nouveautés d'ext4 ne concernent que des nouvelles fonctionnalités inutiles pour l'utilisateur lambda. Je lui conseille d'ailleurs fortement de continuer à utiliser ext3 qui lui a maintenant une vocation première, de stabilité. Ext3 a atteint un stade ou pour avoir des améliorations notables de performances pour l'utilisateur lambda, il faudrait des modifations importantes ... qui donc prendraient place dans ext4. Mais ce n'est pas au goût du jour :).

          Donc ext3 restera le filesystem par défaut des distros pour encore un bon moment et ext4 ne sera utilisé que dans des conditions spécifiques.

Suivre le flux des commentaires

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