Journal OpenSuse et ReiserFS

Posté par  (site web personnel) .
Étiquettes :
0
2
oct.
2006
OpenSuse est (avec Slackware) l'une des seules distributions à utiliser le système de fichier ReiserFS par défaut.
La situation va changer car c'est maintenant ext3 qui sera utilisé.

L'explication : http://linux.wordpress.com/2006/09/27/suse-102-ditching-reis(...)

Résumé des arguments :
Il y a une foultitude de problèmes techniques dans le système de fichier ReiserFS (problème de montée en charge; problème de Big Kernel Lock; problème de gestion des droits étendus de type ACL).
De plus le nombre de devs est très réduit (3 ou 4) et le support pour la v3 est quasi-mort.
Le passage vers la v4 sera difficile du fait qu'aucune transition n'est prévue. Il faudra reformater ce qui est inacceptable pour certains.
De plus la v4 n'est pas encore intégrée dans le noyau Linux standard et sa stabilité est aléatoire.

De l'autre coté Ext3 est supporté par beaucoup de devs car il est standard dans presque toutes les distributions. Sa stabilité est très bonne et les perspectives techniques sont claires avec un plan de transition vers Ext4.

A plus long terme il est envisagé (uniquement pour les serveurs) de basculer sur le système OCFS2 afin de faciliter la clusterisation et la virtualisation. Dans l'intervalle Ext3 est une bonne solution.

  • # au fait

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

    A-t-on des nouvelles de la femme de Hans Reiser ?

    • [^] # Re: au fait

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

      Elle va mieux, elle est allé au cimetière à pied.

    • [^] # Re: au fait

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

      Non. Aux dernières nouvelles de vendredi/samedi derniers, la police a fouillé la maison de Hans Reiser, manifestement sans y trouver grand chose, et a prélevé son ADN pour « mieux analyser les trucs trouvés dans sa maison ». Elle refuse de confier ses enfants à Hans Reiser et les a placés sous sa protection.

      De son côté, Hans Reiser a refusé de dire quoi que ce soit à la police, ainsi qu'aux médias, et cherche à récupérer la garde de ses enfants. Il n'a aucune confiance dans la police et est très remonté contre elle depuis la fouille de sa maison, d'après son avocat.

      La police promet une récompense de 15 000 dollars à toute personne qui apporterait des éléments qui lui permettraient de retrouver Nina Reiser.

      Source :
      http://www.mercurynews.com/mld/mercurynews/news/breaking_new(...)

  • # Et Slack ?

    Posté par  . Évalué à 2.

    Il restait Slackware sur ReiserFS d'après mes souvenirs. Je ne sais pas si c'est toujours le cas sur la version qui se fait attendre (la 11), mais c'était toujours le cas sur la 10.1).

    • [^] # Re: Et Slack ?

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

      étant donné le conservatisme de Volkerding je pense que ReiserFS va rester dans Slackware. après tout le kernel en est encore au 2.4 par défaut !!!!!
      Le 2.6 est sorti depuis quoi ? Trois ans ?

      • [^] # Re: Et Slack ?

        Posté par  . Évalué à -4.

        après tout le kernel en est encore au 2.4 par défaut !!!!!

        Et alors? Quand la dernière version top-moumoute du noyal est sorti on doit l'adopter sinon on est has been?
        Moi je serais toi, je ferais une pétition pour supprimer toutes les versions antérieures au 2.6 des mirroirs de kernel.org !

        • [^] # Re: Et Slack ?

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

          Il n'est pas question d'être has been ou autre c'est juste que pour faire fonctionner Linux sur du matos récent il faut un noyau 2.6.

          Pas besoin de caricaturer mon post.

          • [^] # Re: Et Slack ?

            Posté par  . Évalué à 0.

            Sans compter que technologiquement parlant un 2.6 récent est à des années lumières d'un 2.4. (j'exagère un peu :p )

          • [^] # Re: Et Slack ?

            Posté par  . Évalué à 2.

            C'est l'hopital qui se fout de la charité.
            Tu traites Slackware de "conservateur" parce qu'il utilise toujours un noyau 2.4 (par défaut, bien qu'un 2.6 soit présent depuis ces mêmes 3 ans), alors qu'il intégre des logiciels plus qu'à jour, tu mets un tas de "!!!!!" en faisant de l'ironie et tu trouves que je caricature?

            Maintenant, pour ton matos récent qui ne fonctionne pas avec le 2.4, ce qui ne doit pas représenter la plus grande part des utilisateurs de Slackware, le 2.6 est fourni dans les extra/ ou dans testing/.

            Patrick a cru bon d'attendre la stabilisation du noyau 2.6 pour l'intégrer par défaut dans Slackware, au vu des déboires qu'on a connu jusqu'à de très récentes versions, je doute que qui que ce soit puisse lui en vouloir.

            • [^] # Re: Et Slack ?

              Posté par  . Évalué à 3.

              A la lecture des packages de la version 11, tu vois clairement une philosophie conservatrice sur les logiciels composant le système et relativement bleeding-edge du point de vue des applications utilisateurs (j'ai schématisé).

              Par exemple, tu retrouves :
              - glibc 2.3.6
              - X11R6.9.0
              - gcc-3.4.6
              - Apache 1.3.37

              Et de l'autre côté, KDE 3.5.4, Koffice 1.5.2 ou Amarok 1.4.3.

              • [^] # Re: Et Slack ?

                Posté par  . Évalué à 2.

                Ca s'explique assez simplement:
                - La glibc 2.4 n'est pas utilisable avec un noyau 2.4 standart (voir le changelog de slackware-current).
                - X11R7.1 est sorti fin mai. Slackware devait sortir aux alentours de juin, c'était une modification trop importante d'autant plus que le support des cartes NVidia n'était pas encore officiel.
                - gcc ne permettait pas de compiler toutes les applications possibles il y a encore quelques mois. La politique de Slackware n'étant pas d' "overpatcher" les logiciels, il a décidé de sortir Slackware 11.0 avec un gcc qui reste parfaitement fonctionnel (et dans la dernière version de la branche 3.x).
                - Apache 1.x est extrèmement populaire et il a prouvé sa robustesse. Tout comme pour le noyau, il attend que celui fasse ses preuves avant de faire le "grand saut". La stabilité est primordiale pour Slackware. Je ne vois pas ici du conservatisme mais plutôt une certaine continuité.

                Je ne suis pas le dernier pour râler sur certaines longueurs prises par Patrick Volkerding, mais le choix de services stables et d'applications graphiques récentes me paraissent bons.

                • [^] # Re: Et Slack ?

                  Posté par  . Évalué à -3.

                  > - La glibc 2.4 n'est pas utilisable avec un noyau 2.4 standart

                  ??
                  C'est uniquement car il manque linuxthread ?

                  > - gcc ne permettait pas de compiler toutes les applications possibles il y a encore quelques mois.

                  gcc 4 était utilisé par FC4 (pour compiler toute la distribution + extra). FC4 est sorti il y a plus d'un an et demi !
                  Pour FC6 (qui a quelques paquet de plus que FC4) ça fait 3320 src.rpm et 5700 (i386|noarch).rpm. C'est grosso-modo la même chose pour FC4.

                  Donc les applis qui ne compilent pas avec gcc 4 doivent être très rare et très fort probablement non livré par Slackware. A moins que Slack utilise des programmes si vieux qu'ils nécessitent un vieux gcc...

                  > - Apache 1.x est extrèmement populaire et il a prouvé sa robustesse.

                  Apache 2.0.40 (2.0.36 était estimé stable) est sorti il y a plus de 4 ans ! Il était dans RH 8.0. Dans RHEL (pour entreprise et serveurs critiques) c'est utilisé depuis 3 ans !

                  > Tout comme pour le noyau, il attend que celui fasse ses preuves avant de faire le "grand saut".

                  Noyau 2.6 pour RHEL 4 (pour entreprise et serveurs critiques) sorti il y a plus d'an. Idem pour Novell/SuSE.

                  > La stabilité est primordiale pour Slackware.

                  Excuse bidon. C'est plus de la stabilité, c'est de l'immobilisme.

                  • [^] # Re: Et Slack ?

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

                    Mouais alors je vais faire très court ... Attention !

                    -/- La Slackware ne patch pas le noyau ! -/-

                    Bah je crois que j'ai tout dit.

                    • [^] # Re: Et Slack ?

                      Posté par  . Évalué à 1.

                      Même pour les trous de sécurité ?
                      Si t'attends une correction "officielle", ça peut prendre du temps (quelques semaines).

                    • [^] # Re: Et Slack ?

                      Posté par  . Évalué à 1.

                      Bon diou! Peux pas encore plusser!

                      Et comme le dit si bien le message dessous, effectivement même pour les patchs de sécu. Mais si on reprend la config d'origine (ou si on connaît son matos et ses besoins), ça prend à tout casser 1/4 heure pour compiler et installer un kernel patché.

                      • [^] # Re: Et Slack ?

                        Posté par  . Évalué à 1.

                        > ça prend à tout casser 1/4 heure pour compiler et installer un kernel patché.

                        Parles pour toi.

      • [^] # Re: Et Slack ?

        Posté par  . Évalué à 4.

        et il est vraiment stable depuis quand ?

      • [^] # Re: Et Slack ?

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

        Et ça fait quoi, trois ans qu'on a des kernels 2.6 sous slack ?
        En tout cas je suis sous 2.6 depuis qu'il marche correctement. Les premières versions c'était la galère, maintenant c'est nickel.
        Et le kernel 2.6 sous slack est un 2.6.17.13, soit un truc vieux de 23 jours seulement...

        D'autres question ?
        Ca te parait trop difficile à toi de mettre à jour un kernel ?
        Alors ne passe surtout pas sous slack, bien que cette opération soit triviale, cette distrib n'est probablement pas faite pour toi si tu as peur de changer le kernel...


        Yth.

        • [^] # Commentaire supprimé

          Posté par  . Évalué à 5.

          Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Re: Et Slack ?

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

          Il parlait pas de kernel par défaut ?

          • [^] # Re: Et Slack ?

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

            Et alors ?
            Slack met par défaut un kernel stable sûr et bien rodé.
            Et permet aux gens qui le souhaitent de mettre un kernel plus récent.
            Et avec la 11.0 c'est directement au démarrage de l'install que tu peux faire ce choix, ce qui certes n'était pas le cas pour la 10.2 sortie il y a un peu plus d'un an quand le kernel en était à la version 2.6.13, version qui était parmis les premières vraiment utilisable...

            La Slack est robuste, donc oui, par défaut il y a encore un 2.4.
            La Slack est à jour, donc il y a le choix avec un 2.6.17.13 ou même un 2.6.18 !

            C'est pas du conservatisme ça, c'est de la fiabilité, et du choix.

            De plus la Slackware est réputée tourner sur de très vieilles machines (j'ai deux 486 sur lesquels elle tourne nickel), et sur ce genre de matériel, un 2.6 ne s'impose vraiment pas, et on est content d'avoir un 2.4 extrêmement stable, fiable et éprouvé (2.4.33.3 le dernier des 2.4).


            Yth.

  • # C'est dommage

    Posté par  . Évalué à 2.

    utilisant SuSE (entre autres) depuis très longtemps (ce fut ma première distribution), j'étais habitué, mais surtout j'appréciais énormément les qualités de ReiserFS à l'utilisation.
    Je n'ai jamais eu de problèmes du à reiser même, et lors de problèmes qui on atteint le FS (des crashs violents) les outils reiserfs m'ont toujours sorti de toutes situations...
    J'éspère qu'ils vont simplement ne plus le mettre par défaut mais toujours le proposer... (contrairement à plusieurs distribution (FC par example) qui ne le propose même pas (qui propose pas grand chose d'ailleurs, et c'est bien dommage)

    Quand à ReiserFS 4, autant les premières annonces m'avaient bien bottés, autant la longueur d'avancé, les problèmes de mise dans le noyau,..., m'ont -comme beaucoup- un peu refroidi, mais je ne desespère pas...

    • [^] # Re: C'est dommage

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

      Le problème de ReiserFS c'est qu'il gère très mal les badblocks. Et ce cher Hans répond à ce propos quelque chose dans le genre "je m'en fous, de toute façon quand le disque dur commence à avoir des badblocks c'est qu'il va lâcher". C'est bien joli mais quand t'as des badblocks sur un disque dur reiserfs c'est la galère rien que pour sauver les meubles comparé aux autres FS.

    • [^] # Re: C'est dommage

      Posté par  . Évalué à 6.

      les outils reiserfs m'ont toujours sorti de toutes situations...

      J'ai lu je ne sait où un moyen facile de les planter...Ca y est j'ai retrouvé :

      http://zork.net/~nick/mail/why-reiserfs-is-teh-sukc

      "For a very good time, create a few dozen files containing images of reiserfs filesystems on a reiserfs (scratch) filesystem, and force an fsck.reiser. All of reiserfs is a single B-tree, that can be anywhere on disk. So what fsck.reiser does is to search the entire disks for blocks that look vaguely like parts of the filesystem B-tree, and stiches them altogether. Whee!!!!"

      Bon c'est un cas extrème, mais ce n'est pas très rassurant quand même.

      • [^] # Re: C'est dommage

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

        L'essentiel de son argumentation consiste à dire que ReiserFS et XFS ont été conçus pour du matériel haut de gamme, et pas des « cochoneries [crap] de PCs».
        En gros, il explique que ReiserFS journallise le diff des inodes et pas les inodes complets. Selon lui c'est un problème en cas de défaillances car des modifications non loguées des blocs à écrire peuvent être induites directement par le hardware.
        D'après lui, l'économie n'en vaut la peine que sur les systèmes ayant à supporter des charges intenses, qu'il décrit comme rares.
        Je ne suis pas de son avis, car il néglige les portables, qui eux aussi bénéficient d'une charge d'I/O réduites.

        Et pour ce qui est du cas particulier de la position des blocks, je pense qu'il décrit l'option --rebuild-tree, et pas le mode normal.
        Mais il est vrai que ext3 n'a pas ce problème, lui qui préalloue tout les inodes pour des raisons historiques liées à ext2...

        Enfin, de toutes manières, Novell c'est XGL et Mono... ce qui est un autre troll.

        • [^] # Re: C'est dommage

          Posté par  . Évalué à 2.

          > lui qui préalloue tout les inodes pour des raisons historiques liées à ext2...

          Pour que pour des raisons historiques. Aujourd'hui le principe de base de ext2 n'est pas remis en cause. Ext4 sera peut-être compatible ext2.

        • [^] # Re: C'est dommage

          Posté par  . Évalué à 2.

          L'esssentiel de son argumentaion consiste à dire que si tu fais 3 reiserFS sur un disque et que tus fais un fsck dessus, ils se retrouvent mergés. Ce qui est foireux.

          Concernant les histoires de charges, en l'absence de mesures tu as toutes les chances de te planter.

    • [^] # Re: C'est dommage

      Posté par  . Évalué à 3.

      > J'éspère qu'ils vont simplement ne plus le mettre par défaut mais toujours le proposer... (contrairement à plusieurs distribution (FC par example) qui ne le propose même pas

      Si, c'est proposé. Lors de l'installation il faut faire "linux reiser" "linux xfs" "linux etc".
      Fedora propose tous les systèmes de fichier qui sont upstreams.
      Si t'avais utilisé FC, tu aurais vu qu'il y a reiserfs-utils, etc...

      Par contre, Fedora ne supporte QUE ext3. Inutile de faire un rapport de bug sur reiserfs, il sera foutu à la poubelle dans la seconde. Mais il est difficile de reprocher ça Fedora vu que les autres ne supportent RIEN ! Sauf SuSE qui supporte reiserfs mais va arrêter.

      Le fait que l'installation pour reiser ne soit pas proposé de façon visible, est que de Fedora découle RHEL et dans RHEL il n'y a que ext3 qui est supporté (avec des clients payants qui donc peuvent légitimement gueuler si ça merde).

      Pour RHEL 5, c'est "pire" (NB : ça avait été annoncé par Red Hat depuis RHEL 3), il n'y a pas que les modules ext3.

      > (qui propose pas grand chose d'ailleurs, et c'est bien dommage)

      FUD detected : http://fedoraproject.org/wiki/Overview
      C'est dans Fedora qu'à été développé AIGLX, c'est dans Fedora qu'il y a SeLinux pas défaut, c'est dans Fedora qu'il y a GFS, c'est Fedora qui va utiliser en premier libvirt pour du Xen "out of the box", etc, etc...

      Tient, glibc 2.5 vient de tomber dans rawhide. => donc dans FC6.

      http://fedoraproject.org/wiki/Objectives
      Non-Objectives of Fedora
      ...
      Fedora shall not be a dumping ground for unmaintained or poorly designed software.

      • [^] # Re: C'est dommage

        Posté par  . Évalué à 2.

        Ouhhhh là là ce linchage en règle ou presque. Faut pas t'énerver mon petit ni monter sur tes grands chevaux.

        Pour ce qui est de l'utilisation des FC, je le fais, et récement, puisqu'au boulot on a que des RH ou FC d'installé. Et je fais entre autre les install, malheuresement pas que cela non plus, je peux pas passer 4 h à décortiquer la liste des paquets proposés pour voir si après l'installation faite j'aurais loisir d'utiliser ou non tel ou tel FS, cela j'ai pas besoin d'un aquets pour accèder à une fonctinnalité, je sais que je pourrais toujours installer ce dont j'ai besoin par la suite au pire par le biais des sources.
        Ce qui m'importe c'est que lors de l'install, j'ai accès rapidement lorsque je fais le partitionnement/formatage des disques, à la liste des FS -sinon pas la peine de proposer un installeur moderne- et là je suis désolé le chois est limité très limité. Que la distribution de supporte pas un FS ok, mais quand elle permet de l'installer par la suite, je vois pas pourquoi cela gênerai de le mettre dans la liste des FS de l'installeur (avec tout message de dédouanement, non support ou autre qu'ils veulent mettre pour bien faire comprendre qu'il ne supporte pas tel ou tel FS)...


        Je vois donc une différence entre supporter et proposer.... moi j'espère au moins que SuSE va continuer à porposer Reiser -et dès l'installation- même si il ne le supporteront plus comme FS par défaut. C'est tout.

        Pour SeLinux et autres, on pourrat jouer à celui qui a la plus grande aussi, cela n'avancerai à rien. On peut toujorus trouver des choses qu'une disitrib a que l'autre n'a pas. (pour précision SeLinux par défuat dans les SuSEs aussi (SuSE Linux, SLES, OpenSuSE ou SuSEFactory), et les autres je vais pas regarder mais bon ... là je parlais de ResierFS, en clair je suivais le sujet du journal....
        Prend cela pour un FUD si tu le veux, mais je comparais justement avec FC car je l'utilise régulièrement aussi, donc je me vois plus comparer qu'avec une Mandriva. Et quelques soit mes considérations personnelles pour telle ou telle distrib, les fait sont là, l'installeur ne permet pas d'utiliser simplement ReiserFS -Dès la période d'install je rapelle- donc pour moi c'est comme si il n'était pas proposé...

        bon alors je retourne mesurer ma ... pour le prochain concours...

  • # File systems du futur

    Posté par  . Évalué à 1.

    A propos de file systems, j'avais trouvé l'article http://lwn.net/Articles/190222/ très interessant.

    Il présente les contraintes qu'auront a faire face les nouveaux systèmes de fichiers (notamment en gestion des erreurs sur le disque qui deviennent plus courantes avec l'augmentation de la taille).

    • [^] # Re: File systems du futur

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

      Je ne vois pas bien de quoi veut parler l'auteur de cet article.

      Les erreurs de lecture sur le disque se produisent en permanence, mon disque dur en corrige plusieurs dizaines de millions par jour, le système de fichiers n'en voit rien, de toutes façons c'est pas son boulot.

      Lorsque la correction échoue, à part faire quelques tentatives supplémentaires (sachant que le disque en a déjà fait pas mal), il n'y a pas grand chose à faire : les données de ce secteur sont perdues, point.

      Les solutions à la perte de secteurs sont déjà connues : redondance des données, que ce soit sur le même disque (bof) ou sur un autre (RAID). Mais encore une fois, je ne vois pas trop ce que le système de fichiers peut y apporter.

      • [^] # Re: File systems du futur

        Posté par  . Évalué à 1.

        Y'a ZFS qui est assez impressionnant à ce niveau, je te conseille de regarder leurs démos en ligne : http://www.opensolaris.org/os/community/zfs/demos/selfheal/

      • [^] # Re: File systems du futur

        Posté par  . Évalué à 2.

        C'est juste très diffférent avec la différence de taille:


        Recently, the main server for Linux kernel source, kernel.org, suffered file system corruption from a failure at the RAID level. It took over a week for fsck to repair the (ext3) file system, when it would have taken far less time to restore from backup.


        Le raid ne change rien, on veut un système de fichier qui gère le nombre croissant d'erreurs d'E/S et qui soit le plus tolerant aux fautes possible. Par exemple une certaine redondance au niveau du FS est utile, pour justement éviter que les données du secteur soit perdues.

        • [^] # Re: File systems du futur

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

          Je ne pense pas que gérer une redondance supplémentaire des données au niveau du système de fichiers soit utile, sauf dans le cas des métadonnées (superblocks, allocation des inodes, arborescence des noms) dont la perte empêcherait d'accéder à des données pourtant encore parfaitement lisibles.

          Par contre, ce que l'incident sur kernel.org a montré, c'est le besoin croissant de minimiser la phase de vérification / restauration de l'intégrité des données : ça, je comprends tout à fait.

          Ce n'est d'ailleurs pas tant lié à la fiabilité des disques durs eux-mêmes qu'à la fiabilité de l'informatique en général : erreurs de disque, erreurs de mémoire, erreurs de réseau, plantages du système d'exploitation, etc. Quoi qu'il se passe, il faut que le système de fichiers ne se retrouve pas dans un état corrompu, ou puisse en sortir rapidement et sans trop de casse ; et qu'il puisse vérifier la bonne santé des données après un tel incident.

          Là, c'est clair qu'il y a de la marge pour progresser. :-)

    • [^] # Re: File systems du futur

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

      Et les commentaires des linuxfriens à ce propos se trouvent ici :
      http://linuxfr.org/2006/07/23/21124.html

Suivre le flux des commentaires

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