Les noyaux Linux nouveaux sont parmi nous

Posté par (page perso) . Édité par Benoît Sibaud. Modéré par oliv.
0
23
nov.
2001
Noyau
J'arrive sur Linuxfr et paf je vois dans la boiboite kernel que non seulement le 2.4.15 est sorti mais que la série des 2.5 vient de faire son entrée. :)

Comme prévu le 2.4.15 contient ext3, mais aussi des mises à jour de drivers, de l'usb, de nfs, de la VM et tout le toutim :)

Voici le README trouvé sur kernel.org à propos du 2.5.0 :
"Linux-2.5.0 is exactly the same as 2.4.15, except for a version number change. Subsequent releases diverge, with Marcelo Tosatti maintaining the stable 2.4.x kernels, while the 2.5.x kernels are for development work."

Comprenez que le 2.5.0 est identique au 2.4.15 au numero de version près. A partir d'aujourd'hui les 2 branches divergent. Marcelo Tosatti se chargera désormais de maintenir les 2.4 et les 2.5 sont des versions de développement.

Aller plus loin

  • # et voila la liste des miroirs

    Posté par . Évalué à 1.

    Vous pouvez trouver les differents miroirs a cette adresse :
    http://www.kernel.org/mirrors/(...)

    D'habitude j'utilise ftp://ftp.fr.kernel.org(...) , mais il a pas l'air d'etre a jour pour le moment
    • [^] # Re: et voila la liste des miroirs

      Posté par . Évalué à 1.

      personnellement, j'utilise le miroir ftp.tengu-easynet-fr.lkams.kernel.org

      Hop, les liens direct vers les noyaux sur ce serveur:
      patch-2.4.15: ftp://ftp.tengu-easynet-fr.lkams.kernel.org/pub/linux/kernel/v2.4/(...)
      linux-2.4.15: ftp://ftp.tengu-easynet-fr.lkams.kernel.org/pub/linux/kernel/v2.4/(...)
      2.5.0: ftp://ftp.tengu-easynet-fr.lkams.kernel.org/pub/linux/kernel/v2.5/(...)

      Si vous avez déjà un 2.4.13 ou .14 , utilisez les patch plutôt que les noyaux, ça épargne les miroirs et ça va plus vite à télécharger!


      Question: Que pensent les personnes qui en ont utilisés, des noyaux de développement? est-ce suffisamment stable et fiable pour une station personnelle?
      Je comptais passer en 2.5 (jamais sur la *toute* dernière version du noyau évidemment, je tiens pas à me faire corrompre mes disques) mais j'avoue que j'hésite un peu...
      • [^] # Re: et voila la liste des miroirs

        Posté par . Évalué à 1.

        si tu as besoin de tester une fonctionnalite qui apparait uniquement dans un noyau de developpement, oui; et encore, je dedierai une petite partoche pour ca, juste au cas ou....

        sinon, si c'est juste pour se dire qu'on a le dernier-noyau-de-la-mort-qui-roulaize-a-donf, alors je ne vois vraiment pas pourquoi ...

        finalement mon conseil : pour une station personnelle, reste en x.y.z avec y pair ... sauf si tu es toi-meme developer/tester du noyau (ou que le support pour ta toute dernier carte graphique 512Mo de DDR/ - 400 Milliard de pixels/sec ne soit present que dans un noyau de dev...)
        • [^] # Re: et voila la liste des miroirs

          Posté par . Évalué à 1.

          Je viens d'installer un 2.5.0.

          Pourquoi ? Ben parce que c'est joli comme numéro de version.

          J'attendais que le 2.4.15 sorte pour l'installer ; il se trouve qu'on le trouve aussi sous la forme d'un 2.5.0, quelle aubaine :)

          Et quand les noyaux 2.4 suivants existeront, je piocherai bien évidemment dedans ;)
      • [^] # Re: et voila la liste des miroirs

        Posté par . Évalué à 1.

        Heu, comment on applique un(des) patch(s), dans le bon ordre bien sur, mais quelle commande utiliser, faut-il d'abord avoir des sources bien propres (make clean ou make mrproper), autre chose?
        • [^] # Re: et voila la liste des miroirs

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

          Pour le make clean ou make mrproper, je ne sais pas s'ils sont indispensables...
          Mais tu peux toujours en faire un, ça ne fait pas de mal...

          Par contre, pour patcher ton noyau, il suffit de taper la commande suivante :
          patch -p1 < /chemin/du/path.x.y

          Le système de patch fonctionne très bien...
          Ainsi j'ai une archive du 2.4.5 que j'ai patché à chaque nouvelle version et aucun problème... (je sais pas s'il y a une limite).
      • [^] # Re: et voila la liste des miroirs

        Posté par . Évalué à 1.

        A l'époque des 2.3 (houla, c vieux ;) je tournais en 2.3.x-pre (x>20) sans *gros* problèmes (chtit plantage de tps en tps), je te conseillerais d'attendre que ca arrive un chtit poil à maturité
    • [^] # Re: et voila la liste des miroirs

      Posté par . Évalué à 1.

      Si j'ai tout compris aux XP (actuellement tu as : -7/#30) :
      30 personnes en voté pour ton poste :
      * 11 (37%) pensent qu'il est pertinent de rappeler l'adresse des mirrors de kernel.org qui est assez chargé.
      * 19 (63%) personnes en ont rein à foutre.

      Conclusions :
      * La news est excellente car elle fait pas chier la majorité avec une url sur les mirrors dont elle n'a rien à foutre.
      * Modérateurs, si on vous propose une news avec une url sur la liste des mirrors, virer cette url.
      * Utilisateurs de linuxfr, évitez de poster une url sur la liste des mirrors, c'est mauvais pour vos XP.
      • [^] # Re: et voila la liste des miroirs

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

        Je suis d'accord. Moi, je pensais qu'il fallait voter [-] pour les commentaires hors sujet, déplacés, non argumentés, FUD...

        Un commentaire ne VOUS intéresse pas ? Passez votre chemin et utilisez vos votes pour scorer [+] les commentaires qui en valent la peine.

        Le commentaire de teuf apporte une info, certes connue et pas révolutionnaire mais elle a le mérite de palier un manquement de la news. Pas de quoi déclancher une telle avalanche de votes.
        En plus, il propose un lien alternatif.

        Beaucoup de bruit pour pas grand chose...

        -1 parce que c'est pas une news sur les XP

        Pensez à l'environnement avant d'imprimer ce commentaire - Please consider the environment before printing this comment

  • # ext3

    Posté par . Évalué à 1.

    Avec l'intégration ext3 je pense qu'il seront nombreux ceux qui ont une RedHat 7.2 à tester ce noyau.

    Depuis les sources Linux il est possible de faire un rpm :
    $ cd /usr/src/linux-2.4*
    $ make rpm
    ou
    $make spec
    puis faire un rpm -bb kernel.spec

    PS : c'est une procédure très grossière...
    • [^] # Enfin journalisé !

      Posté par . Évalué à 1.

      C'est sûr que les possesseurs attendaient avec impatience de pouvoir upgrader leur noyau avec les versions officielles (lu sur la tribune: "si c'est pas supporté vite fait, je vire ma RH")...

      Du coup, ce serait le moment de lancer un bon débat : quel fs ? Les candidats sont nombreux : ext3, reiserfs, xfs et jfs principalement (mais il doit y en avoir d'autres, par exemple AtheOS a le sein). Ext3 a un avantage de transition évident (transformation ext2 <-> ext3), mais est-ce suffisant. Des benchs (par exemple http://www.namesys.com/benchmarks/benchmark-results.html(...)) sont-ils aussi suffisants ?

      Car tout ce que je veux, c'est ne jamais perdre mes données ; ceux qui ont essuyé les plâtres de reiser connaissent la chanson !
      • [^] # Re: Enfin journalisé !

        Posté par . Évalué à 1.

        Avis sur ext2 et ext3.
        En gros c'est la même chose. Les performances sont très proche.

        Pour mon usage perso avoir un système journalisé n'apporte partiquement rien. De plus les systèmes de fichier journalisé sont sure avec SCSI (ordre d'écriture garanti) et ne supporte pas les coupures de courant. Bref, c'est uniquement pour les plantages noyau (le reset hard est supporté). Ces infos sont dans le README de la 7.2.

        Pour une utilisation au boulot:
        station de travail : ext3 n'apporte rien.
        serveur : nos serveur (qui sont de petits serveurs...) ne plante pas. Donc très peut de gain.

        Conclusion ext2/ext3 :
        ext3 aporte la journalisation sans surcoût. Alors pourquoi s'en priver .
        • [^] # Re: Enfin journalisé !

          Posté par . Évalué à 1.

          n'apporte rien sur une station de travail c'est toi qui le dit quand tu as une station avec 40Go de DD tu es bien content que ca ne dure pas 3 plombes les reboots...
        • [^] # Re: Enfin journalisé !

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

          >Nos serveurs ne plantent pas.

          Tu devrais dire n'ont pas encore planté, car ca va bien arriver un jour que ca viennent de l'OS ou de l'exterieur (panne de courant, onduleur...). Dans ce cas tu serais peut-être content d'avoir un système de fichiers journalisé !
          • [^] # Re: Enfin journalisé !

            Posté par . Évalué à 1.

            Ce que je veux dire :
            - Je préfère un système très fiable sans système de fichier journalisé qu'un système moyennement fiable avec système de fichier journalisé. Par exemple, un système de fichier journalisé sous windows pour des postes de travail, c'est super cool. Un système de fichier journalisé sous Linux (Qui pour des raison technique hardware, ne peut supporter les coupures de courant ni les disques IDEs, idem avec Windows) est moins interressant pour un usage classique.

            Après si du fait des tests noyau, que tu as des disque SCSI, un serveur qui doit être disponible 24h/24 7j/7 365j/ans alors dans ce cas un système de fichier journalisé est super cool moins pour un système hyper fiable.

            PS :
            Pour les fautes d'orthographe, je te laisse corriger...
            • [^] # Re: Enfin journalisé !

              Posté par . Évalué à 1.

              Les systèmes de fichiers journalisés ne marchent pas sur IDE ?
              Les systèmes de fichiers journalisés ne marchent pas avec les coupures EDF ? Seulement avec les crash kernels ? Ah ben ca doit etre hyper utile alors vu la fréquence des kernel panic !!!

              En plus tu dis que c'est dans la README de la 7.2, j'ai vérifié y'a rien !!!

              Arrete de fumer !!! -> -1 (t'as de la chance qu'on ne puisse pas voter en dessous)
              • [^] # Re: Enfin journalisé !

                Posté par . Évalué à 1.

                > En plus tu dis que c'est dans la README de la 7.2, j'ai vérifié y'a rien !!!

                Tu as raison, c'est dans le "RELEASE-NOTES".

                REALSE-NOTES :
                ftp://ftp.free.fr/pub/Distributions_Linux/RedHat/redhat/redhat-7.2(...)

                Plus une copie partielle du fichier :
                > Veuillez prendre note que les fichiers journaux aussi peuvent être
                > endommagés en cas de panne d'électricité. Lorsqu'un système est privé
                > de courant, le comportement de ce système est indéterminé. Exemple : le
                > contenu de la mémoire peut se dégrader (devenir corrompu de façon
                > aléatoire) car il est copié sur le disque dur exécutant les derniers
                > souffles d'énergie. Cette situation est complètement différente de la
                > séquence d'événements définie qu'est l'arrêt du système en appuyant sur
                > le bouton « réinitialiser » lorsque le système est en cours d'exécution.
                > En outre, les disques durs IDE n'offrent pas toutes les garanties d'ordre
                > d'écriture que les disques SCSI offrent.

                Maintenant t'es libre de faire comme les autres et de dire que les systèmes de fichier journalisé c'est top génial pour ton PC personnel sans onduleur avec disque ide qui passe par un controleur avec 16 Mo de cache et un noyau 2.5.x (x > 0).

                J'ai une RedHat 7.2 ou boulot avec ext3 depuis 1 moi. Mon pc avait des problèmes avec les nappes IDE (c'est un pc de dev, donc du IDE c'est nettement suffisant). A cause de ce problème, le noyau a fait plusieurs panic/freeze (les données qui venait du swap je pense). A chaque reboot le fsck n'était pas complet mais rapide (c'est le "plus" d'ext3). J'ai fait des fsck forcés (-f) et il restait des erreurs ! C'est normal. Le noyau (et ext3) croit avoir écrit correctement sur le disque, hors ce n'est pas le cas. Une foi le problème des nappes fixé, pas de plantage et donc peu d'interrêt d'ext3.
                Je me répète, mais un système de fichier journalisé c'est pas très intéressant pour un usage courant (sauf peut-être sous Windows :-) ).
                • [^] # Re: Enfin journalisé !

                  Posté par . Évalué à 5.

                  Ils ont fumé chez RedHat ?
                  Tout le principe des fichiers journalisés repose sur le fait que sur un disque dur, l'écriture d'un secteur est atomique. Tous les disques dur qui ont moins de 5 ans font ça, en cas de coupure de courant, ils écrivent le secteur qu'ils étaient en train de faire (ils gardent toujours un poil d'énergie) et s'arrêtent (ça peut être plus d'un secteur).
                  Donc quand tu demande l'écriture d'un secteur, soit elle est effectuée complètement, soit elle ne l'est pas. Ensuite, le principe général, c'est d'avoir un journal d'opérations à effectuer, et une table de validité de ces opérations. Quand tu veux effectuer une série d'opérations, elles sont toutes entrées dans la table, puis elles sont toutes marquées valides (à effectuer), de manière atomique. Puis elles sont appliquées, puis tout marquées invalides, de manière atomique encore. Du coup, en fonction du point ou tu t'arrêtes/plante,
                  - soit les opérations ne sont pas toutes écrites dans le journal, alors elles ne sont pas marquées valides. au redémarrage, tu as perdu les opérations, mais ton système est toujours cohérent
                  - soit les opérations sont toutes écrites, et toutes marquées valides. Au redémarrage, tu les effectue. Si elles avaient déjà été effectuées toutes ou en partie, c'est pas grave... Elles sont juste faites 2 fois. Au final, ton système est toujours cohérent
                  - soit les opérations avaient été effectuées, et marquées invalides, dans ce cas, elles sont ignorées au redémarage. Ton système était cohérent au crash, et il le reste.

                  Je ne sais pas si je suis clair, mais il y avait eu un article sur les fichiers journalisés dans un LHFM il y a environ un an, qui expliquait bien cela.

                  Au final, je dirais que si ext3 ne fait pas ça, eh bien en tout cas ReiserFS le fait, lui.
                  • [^] # Re: Enfin journalisé !

                    Posté par . Évalué à 1.

                    > Ils ont fumé chez RedHat ?

                    Tu crois que RedHat va dire du "mal" ext3 pour se faire plaisir?
                    C'est comme si Microsoft annoncais des bugs dans Windows qui n'existent pas.

                    > Tout le principe des fichiers journalisés repose ...
                    > ...

                    Globalement, tout ce que tu dis est juste ! C'est le même principe de transaction que les bases de données qui est atonique :-> .

                    Tu parles de coupure de courant sur les disques dures. Hors RedHat parle de coupure de courant sur la carte mère. Dans ce cas, la mémoire vive peut être corrompue alors que l'os envois la demande d'écrire (les données peuvent également être corrompu au niveau du controleur IDE). Les disques font correctement leur travail mais écrivent des données corrompues. Bien sure, si les disques dures tombent avant la carte-mère il n'y a pas de problème.

                    Il faut bien noté que c'est un problème de hardware auquel Linux (ou windows ou Solaris ou ...) ne peut rien !

                    Imaginons une solution (je ne connais rien à l'électronique).
                    Sur coupure de courant une capa permet à ma CM de tourner encore 1 seconde.
                    Un système en amont de la carte mère controle l'arrivé du courant.
                    S'il détecte un problème sur l'arrivé du courant :
                    - 0,5 secondes après, fait un reset hard (d'après RedHat ext3 le supporte) si alimentation non stable.
                    - 0,9 secondes après, arrêt de la carte mère jusqu'au retour d'une alimentation stable.

                    Enfin, l'autre problème soulevé par RedHat est que les disques IDE peuvent réorganiser l'ordre d'écriture. Ceci afin de limiter les déplacements du bras du disque dure. l'OS dans ce cas ne peut rien. L'os ne connait pas la géométrie du disque : en effet sur les disques moderne, les informations de géométrie retournées ne correspondent pas toujours à l'organisation réelle. Donc l'os ne peut limiter les déplacements de bras aussi finement que peut le faire le controleur du disque qui lui connait la géométrie réelle du disque. Ne parlons même pas des cartes raid qui font croire à l'os qu'il n'y a qu'un disque dur alors qu'il y en a plusieurs...
                    Par contre SCSI garanti l'ordre d'écriture et fait l'impasse sur l'optimisation des déplacements des bras.
                    Avec SCSI :
                    - l'OS demande :
                    ---- écriture donnée
                    ---- validation donnée
                    - le disque SCSI fait :
                    ---- écriture donnée
                    ---- validation donnée (atonique)

                    Avec IDE :
                    - l'OS demande :
                    ---- écriture donnée
                    ---- validation donnée
                    - le disque IDE PEUT FAIRE :
                    ---- validation donnée (atonque)
                    ---- écriture donnée. S'il y a coupure de courant avant écriture des données tu as un journal qui indique des données validées alors qu'elles n'ont pas été écrites !
                    • [^] # Re: Enfin journalisé !

                      Posté par . Évalué à 1.

                      Ce que tu appelles un Capa ca serait pas plutot un onduleur ? ;) qui lui detecte une panne de courant averti l'os de s'arreter et coupe le tout ....
                      • [^] # Re: Enfin journalisé !

                        Posté par . Évalué à 1.

                        Capa : une capacité électrique (cf cours de physique :-) ).

                        C'est l'idéal. mais un onduleur c'est cher.
                        Je parle d'un truc à 5 francs et non 1000.
                        Et linux ne s'arrête pas en 0,5 seconde...
                        • [^] # Re: Enfin journalisé !

                          Posté par . Évalué à 1.

                          Ce qui rend ce que tu dis impossible c'est que linux est incapable de s'arreter en 0.5s (pas un reproche c'est plutot logique ...) et donc actuellement la seule chose capable de faire ce que tu veux est un onduleur. Je pense d'ailleurs que quand tu te mets a te poser ce genre de question, c'est que tu dois en avoir vraiment besoin et que 1000F sont un detail ... D'ailleurs certains controlleur disque conserve dans leur PRAM l'etat de leur cache interne et le traite au demarage, c'est par contre pas des controleur a 5F ... :)
                • [^] # Re: Enfin journalisé !

                  Posté par . Évalué à 1.

                  En quoi le fait que 2 ou 3 octets peuvent ne pas etre corrects sur de l'IDE ou avec une coupure électrique diminuent l'intéret des systèmes non journalisés ReiserFS ?????? C'est pas mieux avec les autres non ?

                  Si t'as 100Go de données à checker avant de redémarrer, quoiqu'il arrive il vaut mieux du journalisé, et perdre 2 ou 3 octets est mineur dans ce cas, de toute facon ca arrive tous les jours sur tous les disques avec ou sans crash.
                  • [^] # Re: Enfin journalisé !

                    Posté par . Évalué à 1.

                    J'ai pas dit le contraire.
                    Dans un post plus haut je donnais mon avis sur ext2/ext3 de mon point de vu utilisateur :

                    > Conclusion ext2/ext3 :
                    > ext3 aporte la journalisation sans surcoût. Alors pourquoi s'en priver.
      • [^] # Re: Enfin journalisé !

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

        Tous les outils Linux/Unix qui marchent encore sur ext2 ne sont pas tous portés sur etx3... ni sur Reiser/X/Jfs non plus d'ailleurs...
        Il est toujours urgent d'attendre... à défaut de tester/débugger...
        • [^] # Re: Enfin journalisé !

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

          Tu peux donner un exemple?
          D'après ce que j'avais compris ext3 est compatible ext2. C'est ce qui m'avait décidé à changer et depuis je n'ai pas eu le moindre problème.
        • [^] # Re: Enfin journalisé !

          Posté par . Évalué à 1.

          > tous les outils Linux/Unix qui marchent encore sur ext2 ne sont pas tous portés sur ext3
          C'est un peut "naze" comme remarque.
          Par exemple, tu peux utiliser fsck fournie avec, par exemple, une redhat 6.2 sur un ext3. Dans ce cas, le journal peut être supprimé et tu ne peux plus monté la partition en ext3.Il faut recréer le journal avec tune2fs. Et si tu n'as pas une version de tune2fs qui permet l'ajout du journal, tu supprimes la journalisation avec l'option "-O". Tu reboot sous ta RH7.2 (par exemple) et tu réactives la journalisation avec tune2fs.

          Bref, je comprend pas ta remarque...
  • # XFS roulaize à bloc

    Posté par . Évalué à 1.

    j'éspère qu'ils vont intégrer XFS assez rapidement, j'en ai marre de patcher mes kernels moi !!
  • # Ext3 !!!

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

    Y'a quand même un truc important dans les amliorations apportées par le noyau 2.4.15 :

    Ext3 est maintenant intégré en standard !

    Rappel pour les ceusses qui n'auraient pas suivi : ext3 est un système de fichiers journalisé, c'est à dire bien plus résistant aux coupures de courant intempestives. Dans ce cas, non seulement ext3 assure une meilleure intégrité des données sur le disque mais il supprime le besoin de faire un fsck au redémarrage suivant. Au remontage du FS, le noyau a juste besoin de "rejouer" le journal sur le disque pour le restaurer en bon état.

    A noter aussi que, contrairement aux autres FS journalisés (ReiserFS, JFS, XFS), ext3 peut journaliser non seulement les modifications sur les métadonnées mais aussi sur les données elles mêmes.

    Autre avantage non négligeable : la migration.

    Avec une version récente de e2fsprogs (1.20 au moins et non 1.19 comme c'est marqué dans Documentation/Changes), il suffit de taper tune2fs -j /dev/partition (hda1, sda1...) pour créer un journal sur le filesystem ext2. Pas besoin de le démonter pour ça.

    Au remontage suivant du disque, il sera monté en ext3 (penser à modifier /etc/fstab en conséquence).
    • [^] # Re: Ext3 !!!

      Posté par . Évalué à 1.

      ext3 peut journaliser non seulement les modifications sur les métadonnées mais aussi sur les données elles mêmes.

      Une donnée, je vois a peu près ce que c'est, mais qu'es-ce qu'une meta-donnée ?
      • [^] # Re: Ext3 !!!

        Posté par . Évalué à 1.

        Ce sont les données qui décrivent par exemple: emplacement, taille, uid et gid propriétaires, dates de création, de dernier accès et de dernière écriture... C'est hyper important, car si CES données-là sont foutues alors tu as de grandes chances de ne plus retrouver ton fichier...
        • [^] # reiser et meta

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

          Et meme ca, reiser n'est pas foutu de le faire comme il faut. J'ai un un probleme avec ma partition, j'ai du faire un reiserfsck manuel, tous les fichiers y etaient mais avec les droits d'acces 0000 et meme root ne pouvait plus rien lire...
          Heureusement que j'avais un backup, mais a reiser, je n'y touche plus avant un bon moment
          • [^] # Re: reiser et meta

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

            Heureusement que j'avais un backup, mais a reiser, je n'y touche plus avant un bon moment

            L'avantage principal de reiser n'est pas la sécurité des données, mais les performances (inégalables pour la gestion des petits fichiers). Associé à des backups réguliers, c'est une bonne solution.
            • [^] # Re: reiser et meta

              Posté par . Évalué à 1.

              Ouh là, vous me faites peur...

              Chez moi j'ai mis toutes mes partoches (sauf / et /boot, je suis pas malade) en reiserfs par-dessus du raid software ide, pour avoir des bonnes perf et des données sûres...
              Je sais qu' il y avait eu pas mal de pb de corruption liés à reiserfs au début, mais maintenant ça marche, ou pas?
              • [^] # Re: reiser et meta

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

                Expérience perso : j'avais eu il y a quelques temps des plantages du kernel à cause de l'USB ainsi qu'à de la RAM foireuse. Au reboot j'ai constaté que le contenu de certains fichiers était remplacé par d'autres.
                Par exemple dans le fichier chap-secret il n'y avait plus mon identifiant et mot de passe pour la connexion Internet mais un fichier de conf quelconque de KDE. Pire, j'ai retrouvé par hasard la totalité de /etc/passwd dans un log de XFree...

                Ce qui est bizarre, c'est que j'ai ces erreurs malgré la synchronisation d'urgence que je fais grâce aux Magic SysRQ (alt+impr. ecran+S). Ce n'est pas pris en charge par reiserfsd ?

                ReiserFS semble donc avoir du mal avec les metadata.

                <pub>
                Depuis, j'ai adopté ext3, et ma vie a changé. Je n'ai plus constaté de corruptions de ce genre (c'est vrai que j'ai résolu mes problèmes de plantage aussi)</pub>

                Pensez à l'environnement avant d'imprimer ce commentaire - Please consider the environment before printing this comment

                • [^] # Re: reiser et meta

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

                  Par exemple dans le fichier chap-secret il n'y avait plus mon identifiant et mot de passe pour la connexion Internet mais un fichier de conf quelconque de KDE. Pire, j'ai retrouvé par hasard la totalité de /etc/passwd dans un log de XFree...

                  J'ai eu la même chose avec ext2, et pas dans sa période de développement... Je pense que la plupart des problèmes de reiserfs ont été résolus, ce qui nous amène à un niveau de sûreté égal ou supérieur à celui d'ext2.

                  Le seul truc vraiment emmerdant que j'ai eu avec reiserfs était du à un bug qui fut corrigé depuis, et qui empêchait l'effacement de certains répertoires.

                  Maintenant, par rapport à XFS, JFS ou ext3, je pense que la sécurité est moindre.
                  • [^] # Re: reiser et meta

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

                    Mmmm... avant que je passe en ext3, je suis resté quelques jours avec le reiserfs du 2.4.13 et j'ai quand même constaté ces problèmes.
                    Je ne pense pas que la version de reiserfs de ce noyau soit si veille que ça !

                    Pensez à l'environnement avant d'imprimer ce commentaire - Please consider the environment before printing this comment

                • [^] # Re: reiser et meta

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

                  Mince, après un plantage j'ai du rebooter et reiserfs a fait son boulot.

                  Mais pas longtemps après, je me suis retrouvé avec /etc/X11/prefdm dans /usr/share/apps/kdm/kdmrc :(

                  Moi qui voulait accuser Mdk, ça viendrait donc de ReiserFS. Aîe, je suis en ReiserFS partout :(

                  Ce WE => migration vers Ext3

                  L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

              • [^] # Re: reiser et meta

                Posté par . Évalué à 1.

                Pour les donnees sures, mon experience recente indique que reiserFS n'est pas la panacee.
                J'avais fait l'operation de passer d'ext2 en reiserFS, je vais la reiterer pour aller de reiserFS en ext3.
                • [^] # Re: reiser et meta

                  Posté par . Évalué à 1.

                  Quand je pense aux reproches fait à RedHat de ne pas intégrer ReiserFS (ou avec toutes les options de debug activé) alors que Suse et Mandrake l'ont fait très tôt et que je vois des posts sur des problèmes de fiabilité avec ReiserFS (sans parler des problèmes NFS et quota) , je me marre...

                  Heureusement qu'il y a RedHat, Debian (liste non complète !) pour ne pas sauter sur tout ce qui bouge et faire la course à la dernière version de noyau (surtout pour les systèmes de fichier).
                  J'ai parfois l'impression que les "Linuxiens" sont aussi c.. que les windowsiens (pas peur de suicider mes XP !).
                  • [^] # Re: reiser et meta

                    Posté par . Évalué à 1.

                    Ben moi, ça fait assez longtemps que j'utilise Reiserfs sur toutes mes partitions (même / et /boot), et que je n'ai aucun problème.

                    Ca tourne très bien ; je n'ai eu aucun des problèmes dont vous parlez tous, ni d'autres.

                    Bref, pour moi, Reiserfs, ça le fait...

                    Après, je pense que c'est une question de choix et d'expérience personnelle. J'avoue que le concept de reiserfs me séduisait, alors je l'ai essayé ; comme il marchait bien, je l'ai gardé.
                    • [^] # Re: reiser et meta

                      Posté par . Évalué à 1.

                      Les problemes que je rencontre avec ReiserFS ne lui sont pas vraiment imputables. J'attendais de ReiserFS qu'il ne corrompe pas mes donnees lors d'un crash, alors qu'il n'a jamais pretendu le faire.
                      A partir du moment ou ta machine ne se plante pas, reiserFS a sans doute ses avantages (rapidite ?).
                      Mais a ceux qui comme moi veulent eviter de perdre leurs fichiers a cause de coupures/plantages, reiserFS n'est apparemment pas l'ideal.
                  • [^] # Re: reiser et meta

                    Posté par . Évalué à 1.

                    > Heureusement qu'il y a RedHat, [...] pour ne pas sauter sur tout ce qui bouge [...]

                    Bon, il faut relativiser car le coup de construire sa distrib avec une version CVS de gcc, c'est mille fois pire.
                    • [^] # Re: reiser et meta

                      Posté par . Évalué à 1.

                      C'est pas terrible effectivement. Mais le compilateur qu'il ont fournis était bon.
                      Seulement un errata sur le préprocesseur (cpp).

                      Enfin, RedHat est beaucoup impliqué dans gcc principalement après le rachat de cygnus et peuvent se permettre ce chois "étrange".

                      Dailleur Mandrake a suivi RedHat :-) .

                      Et si Linux ne se compilait pas avec gcc 2.96-RH c'est car cette version de gcc est plus stricte que les anciennes et révélait des bugs dans Linux.
                      Et non l'inverse. Ainsi, gcc V3 qui est supérieur à gcc 2.96 rencontre les même problèmes de compatibilité avec Linux :-) .

                      Mais le pire est d'avoir sorti un gcc 2.96 alors que la vers 2.96 n'était pas sortie par www.gcc.org.
            • [^] # Comme quoi...

              Posté par . Évalué à 1.

              ...Linus avait pas forcément tort de ne pas vouloir de ReiserFS pour le 2.4...
    • [^] # Re: Ext3 !!!

      Posté par . Évalué à 1.

      il est conseillé de mettre les partitions ext3 en type "auto" dans le /etc/fstab. Specifier ext3 comme type est source de bug, il me semble.
      Le gros avantage du ext3, comparé aux autres FS journalisés, est que l'on peut monter une partition ext3 en ext2, on perd l avantage du systeme journalise, mais pour reparer un linux en vrille c'est pratique.
      • [^] # Re: Ext3 !!!

        Posté par . Évalué à 1.

        Je ne suis pas un spécialiste, mais je ne crois pas que ce soit un bug.
        on spécifie simplement auto de manière à pouvoir redémaré en cas de besoins sur un vieux kernel ne suportant pas le ext3.
        Si on à ext3 en dur dans le fstab. il n'y comprend rien. avec seuelement auto, il se débrouille pour remonter le tout en ext2.

        En espérant ne pas m'être trompé...
      • [^] # Re: Ext3 !!!

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

        il est conseillé de mettre les partitions ext3 en type "auto" dans le /etc/fstab.
        Et moi je le déconseille.
        En effet mkinitrd (au moins la version 3.1.6-mdk de Mandrake) ne mettra pas le module ext3 dans initrd si il ne trouve pas ext3 explicitement comme filesystem de /.
        Ca provoque un beau "no init found. Kernel Panic" au reboot après la mise à jour du noyau :(
    • [^] # Re: Ext3 !!!

      Posté par . Évalué à 1.

      A noter aussi que, contrairement aux autres FS journalisés (ReiserFS, JFS, XFS), ext3 peut journaliser non seulement les modifications sur les métadonnées mais aussi sur les données elles mêmes.

      Au détriment évident de l'espace disque et des performances...

      Par contre, ça n'empêche pas de perdre du travail, mais ça évite de se retrouver avec des fichiers qui contiennent des informations éronnées.
      • [^] # Re: Ext3 !!!

        Posté par . Évalué à 1.

        >mais ça évite de se retrouver avec des fichiers qui contiennent des informations éronnées.

        Faux, si au cours d'une transaction ton application fait deux écritures et que le pc plante avant que la seconde est été validée. Le système de fichier retournera au dernier état cohérent du fichier, cad avec une transaction à moitié effectué.

        Par contre, le fichier sera toujours lisible et les données pourront être éventuellement reparés.

        Voilà voilà.
        • [^] # Re: Ext3 !!!

          Posté par . Évalué à 1.

          Ben... j'ai pas dit le contraire que je sache !
          • [^] # Re: Ext3 !!!

            Posté par . Évalué à 1.

            Ah, si par "informations éronnées" tu endendais fichiers corrompus (illisible voir inexistant au redémarrage) alors on est d'accord, tu n'a pas dis le contraire.

            Moi j'avais compris cette phrase dans le sens informations de l'utilisateur.
            un texte ou une image qui après redémarrage ne seront pas forcément valident par l'application cliente mais qui est poutant dans un état correct vis à vis du système de fichier.

            Disons que mon commentaire était un petit complément d'information.
    • [^] # Re: Ext3 !!!

      Posté par . Évalué à 1.

      Tous les détails pour la migration et la gestion dans
      l'excellent doc de Qing Liu:

      http://www.linux-france.org/article/sys/ext3fs/(...)
    • [^] # Re: Ext3 !!!

      Posté par . Évalué à 1.

      Petit mot sur les performances/sécurité.

      Les lecteurs de linuxfr aime les systèmes de fichier performant. La popularité de ReiserFS sur linuxfr est significative (çà change avec ext3).

      Hors la sécurité c'est plus important.
      Avec ext3 et avec les paramètrages par défaut, les données sont journalisé contrairement à ReiserFS. Avec ReiserFS lors d'un reboot violent, il indique aucun problème au niveau système de fichier mais les données peuvent être corrompues.
      Pour les aspects performance, si quelqu'un fait un bench entre ext3 et ReiserFS il faut qu'il désactive la journalisation des données d'ext3 (mode writeback) pour faire une comparaison juste.

      Enfin, avec ext3, le journal peut être mis sur un autre disque physique ce qui peut encore améliorer les performances.
      • [^] # Re: Ext3 !!!

        Posté par . Évalué à 1.

        si quelqu'un fait un bench entre ext3 et ReiserFS il faut qu'il désactive la journalisation des données d'ext3 (mode writeback) pour faire une comparaison juste.

        Je ne suis pas d'accord. Tester pour le plaisir de tester, je trouve pas ça interressant.

        Il faut comparer des solutions complètes. Personne n'utiliserai un ext3 en journalisation meta seule. C'est un tout.

        Un bench, c'est UNE partie de ce qui rentre en compte dans un choix, mais c'est très loin d'être le seul. Vire les systèmes de protection dans tous les softs, il vont largement plus vite, mais qui voudrais d'un système qui tient pas 10 minutes ?
        • [^] # Re: Ext3 !!!

          Posté par . Évalué à 1.

          Je veux simplement que la comparaison soit faite à niveau de sécurité équivalent. Ou alors indiquer clairement que le niveau de sécurité n'ai pas le même.

          Je dis çà que il y a 3 ou 4 ans, MySQL était souvent livré avec fsync() désactivé (ce qui est abominable pour la sécurité des données). Et lorsqu'il y avait une comparaison être PostgreSQL et MySQL, MySQL était évidament plus rapide. Alors que sous PostgreSQL on peut aussi désactivé l'appel à fsync() (à évité bien évidament...).

          Il faut comparer ce qui est comparable ou être très claire dans ce qui est comparé. exemple :
          ext2 : pas de journalisation
          ext3 conf 1 : journalisation data/metadata
          ext3 conf 2 : journalisation metadata
          ReiserFS : journalisation metadata
      • [^] # Re: Ext3 !!!

        Posté par . Évalué à 1.

        Non, les données ne sont pas journalisées par défaut sous ext3fs.
        Ext3 possède trois modes de fonctionnement:
        data=writeback => journalisation des méta-données
        data=journal => journalisation des données et des méta-données
        data=ordered => mode par défaut: seules les méta-données sont journalisées, mais le système n'écrit les méta-données que lorsque les données correspondantes ont déjà été écrites; le filesystem reste donc toujours dans un état cohérent.

        Les différents modes d'ext3 sont expliqués en détail sur http://www-106.ibm.com/developerworks/linux/library/l-fs7/(...) ainsi que sur http://www.redhat.com/support/wpapers/redhat/ext3/index.html(...)
  • # Waouh !! Je tourne en 2.5 !!

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

    Frime non ? ;)

    bon ok -1

    sans rancune

    thibs
  • # Champagne !!!

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

    juste pour dire qu'il me manquais le noyeau de developpement :)
  • # Openwall

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

    Enfin le fameux 2.4.15 !
    Maintenant j'attends le patch kernel Openwall, quelqu'un saurait où il en est ?
    http://www.openwall.com(...) (aucunes infos sur le site à part qu'ils attendaient le 2.4.15 donc ??? )

    Et si y en a qui l'ont utilisé avec les anciennes versions du kernel, pourraient ils nous faire profiter de leur expérience sur ce patch ?
  • # Petite erreur dans la boiboite !

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

    Ceux qui auront parcouru la boiboite l'auront remarqué :
    Le kernel Alan Cox n'est pas nommé "pre", c'est du Linus, ça...
    Il faudra donc corriger la boiboite, n'est-ce pas mêssieux daCode ?
    Il y aura les patches 2.4.XX(mt), le 2.5.YY(lt) et le 2.5.ZZac, non ?
    (mt = Marcelo Tosatti - lt = Linus Torvalds - ac = Alan Cox)
    • [^] # Re: Petite erreur dans la boiboite !

      Posté par . Évalué à 1.

      A vue de nez, y'aura surtout le stable (2.4.15) en ce moment, le kernel en test (placé dans "testing" donc), actuellement 2.5.0, et les 2.4.x-preX (fais par Marcelo Tosatti).

      Alan Cox avait annoncé récemment (le post doit encore être sur la home d'Advogato) qu'il lachait un peu les kernels pendant un moment, si je me souviens bien.
  • # 2.4.15 inutilisables...

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

    sur architectures autres que i386

    "I'm seeing this on sparc as well. This is because show_trace_task() is
    called from kernel/sched.c, and is only implemented in i386/kernel/. This
    means that other architectures that don't implement it will break. The
    sparc tree is equally broken too."
  • # 2.4.15-greased-turkey

    Posté par . Évalué à 1.

    Quand on compile le 2.4.15, les modules sont mis dans "2.4.15-greased-turkey". Quelqu'un a une info la dessus ? (ça le faisait pas en 2.14.14 !). Maintenant, les kernels auront un petit nom ?
    • [^] # Re: 2.4.15-greased-turkey

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

      Version spéciale en référence à la dinde de Thanksgiving, peut-être ?
      • [^] # Re: 2.4.15-greased-turkey

        Posté par . Évalué à 1.

        Ca a l'air (turkey, c'est dinde non ?)

        Pour info, c'est défini là :


        linux/include/linux/version.h in 2.4.15:
        #define UTS_RELEASE "2.4.15-greased-turkey"
        #define LINUX_VERSION_CODE 132111
        #define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))
        • [^] # Re: 2.4.15-greased-turkey

          Posté par . Évalué à 1.

          Je raconte n'importe quoi, je viens d'aller lire le patch (c'est long et ça manque d'action) c'est défini dans le makefile, comme le dit celui en dessous.
        • [^] # Re: 2.4.15-greased-turkey

          Posté par . Évalué à 1.

          Petite erreur.
          version.h est un fichier généré par un Makefile (avec "make dep" par exemple).

          D'ailleur, il sera supprimé par un "make mrproper" !
      • [^] # Re: 2.4.15-greased-turkey

        Posté par . Évalué à 1.

        De nombreuses dindes ont été sacrifiées en l'honneur de la sortie de ce noyau :)

        http://www.uwsg.indiana.edu/hypermail/linux/kernel/0111.2/1610.html(...)
    • [^] # Re: 2.4.15-greased-turkey

      Posté par . Évalué à 1.

      Je n'ai pas les sources 2.4.15.
      Mais fait un :
      $ vi /usr/src/linux/Makefile
      au début il y a un truc du style :

      VERSION = 2
      PATCHLEVEL = 4
      SUBLEVEL = 9
      EXTRAVERSION = -13custom
      KERNELRELEASE=$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)

      mais à "" EXTRAVERSION et regarde si çà corrige le problème.
  • # Le noyau aujourd'hui et demain...

    Posté par . Évalué à 1.

    Je pense que le noyau 2.4 a maintenant atteind sa maturité : apres des deboires facheux, l'implementation d'un VM foireuse, le noyau 2.4 est devenu, depuis le 2.4.10, franchement interessant (je conseil d'ailleurs les personnes de ne pas utiliser un noyau >=2.4.0 et < 2.4.10)

    J'ai fait un essai avec le noyau 2.4.13 (il se fait deja vieux) et y a plus de plantage quand on lit du Divx, y a plus de swapping monstrueux, par contre y a encore du boulot niveau performance (c'est bizard, de temps en temps y a des ralentissements genant, style je joue a Quake 3 et pendant une demi seconde ça se fixe, cela pendant 1 minute, et apres tout retourne dans l'ordre...)

    Je vais essayer le noyau 2.4.15.

    Ce qui me plait, c'est la possibilité de supporter le hot plug PCI (ça devenait franchement necessaire, surtout avec certains portables...)

    Bien sur, c'est pas parce qu'on a le noyau 2.4.15 que tout va s'integrer facilement comme sous Windows 98 : pour integrer un periph usb, il faudra encore ouvrir une console pour integrer les modules, en esperant les avoir integres lors de la compilation du noyau).

    Je fait confiance à SuSE/Redhat/Mandrake pour creer un utilitaire sympa pour integrer facilement les periph USB tel le scanner, Webcam, Imprimante (en partie fait), Joystick (souris c'est deja fait), ainsi que les nouveaux accessoires comme les HD, Zip, Graveur (meme si je trouve ça debile d'utiliser l'USB pour tel genre de periph).

    Je me pose quand meme une question :
    Linux 2.4.6 va t-il integrer l'USB 2 , Firewire et les nouvelles normes, pour ne pas etre a la traine face aux Windows XP # et Mac os # ?
    (PS : j'aimerai bien jouer les Kernel Hacker et apporter ma modeste contribution pour l'integration de ces normes, mais franchement, comment voulez vous qu'un arriviste qi n'a pas suivi le debut du developpement du kernel puisse comprendre tout le code !)
    • [^] # Re: Le noyau aujourd'hui et demain...

      Posté par . Évalué à 1.

      Je ne suis pas certain de ce que j'avance car je n'est pas l'arborescence du kernel sous les yeux mais le firewire (ieee1394) il est déjà (peu être pas très mature?) dans les noyau 2.4.xx.

      J'en profite pour demander si il y a un programme pour controler mes enceintes Altec Lansing sur port USB car j'ai vu qu'il existe un module dans le noyau pour controler des périphérique sonores de ce type mais il n'y a aucune autre explication.
  • # A propos...

    Posté par . Évalué à 1.

    Quant est-il du site et du projet http://www.kerneli.org(...) le site ne répond plus, le domaine a expiré le 8 Aout et je me rappelle qu'il y avait peu de mise à jour ces derniers mois....

    Quelqu'un a des infos ?

Suivre le flux des commentaires

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