Journal Reiserfs 4 !

Posté par  (site web personnel) .
Étiquettes : aucune
0
24
août
2004
Reiserfs 4 est sortit !
La description officielle (très intéressante) est disponible là bas : http://namesys.com/v4/v4.html(...)
Les benchmarks ici : http://www.namesys.com/benchmarks.html(...) (sans être expert, Reiserfs à l'air de roxer mais de bouffer des masses de CPU - et y'a pas le match XFS vs. Reiserfs).
Et la news Slashdot là : http://slashdot.org/article.pl?sid=04/08/24/0058234(...)

  • # Reiser4 debugging sponsored by Lindows

    Posté par  . Évalué à -10.

    voilà voilà...

  • # youhou !

    Posté par  . Évalué à 4.

    Plus qu'a esperer que la convertion v3 -> v4 est possible sans reformater !

    • [^] # Re: youhou !

      Posté par  . Évalué à 6.

      "To upgrade from reiserfs V3 to V4, use tar, or sponsor us to write a convertfs."

      Il faut garder en tête que reiser4 a été refait de fond en comble et n'a plus rien a voir avec reiserFS, ce n'est pas le même cas de figure que ext2 et ext3.

      • [^] # Re: youhou !

        Posté par  . Évalué à 2.

        arf ;(
        Heureusement que j'ai un 120go qui traine parce que les partitions de 50go pleines, c'est un peu chiant :p
        Merci pour l'info en tout cas.

        • [^] # Re: youhou !

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

          Pour toujours l'occase pour faire des sauvegardes. Mon père vient de perdre un disque de 40 Go (mort physiquement) ...

          @+ Haypo

  • # Commentaire supprimé

    Posté par  . Évalué à 7.

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

  • # Pas d'inquiétudes

    Posté par  . Évalué à 10.

    pbpg pourra t'éclairer sur le point de la consommation du CPU :

    Le benchmark montre un haut usage CPU et c'est une BONNE CHOSE.

    Pourquoi ?

    Parce que ca montre que reiserfs ne fait pas bcp d'operations bloquantes, qui font qu'il doit s'arreter sans cesse pour attendre xyz (mutex, I/O,...)

    Si t'essaies de faire qqe chose pendant un mv avec reiserfs, t'auras aucun probleme, car le scheduler file du temps CPU selon la priorite des taches, pas selon le CPU qu'elles occupent. Le scheduler il en a rien a battre que ce soit un mv ou un mozilla, il regarde la priorite de la tache et fait avec(a qqes exceptions pres ou il booste la priorite notamment pour les I/O).

    Sur un systeme charge, ton reiserfs il va pas utiliser 30% du cpu, car d'autres taches vont prendre le cpu de temps en temps.

    Le thread commence ici. Il est trollifère, mais la démonstration de pasBill est convaincante
    http://linuxfr.org/comments/254247.html#254247(...)

    • [^] # Re: Pas d'inquiétudes

      Posté par  . Évalué à 3.

      De mon côté, j'avais très rapidement comparé reiserfs et XFS à coup de gros dd, et y'avait pas photo: en écriture, XFS était 2 fois plus rapide que reiserfs... c'était le seul test que j'avais fait, mais faut avouer que je ne m'attendais pas à une telle différence.

      Pour ce qui est de l'utilisation du CPU, il n'y a aucune logique dans le fait qu'une haute utilisation du CPU implique une meilleure gestion des opérations bloquantes! Si la gestion des opérations bloquantes est bonne, je suis d'accord qu'une plus haute utilisation du CPU n'est pas un gros problème, mais je ne vois pas d'autres liens entre ces 2 paramètres.

      Enfin, il ne faut pas oublier que la charge CPU n'est pas le point le plus important: c'est surtout la charge du système qui importe.

      • [^] # Re: Pas d'inquiétudes

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

        Pour ce qui est de l'utilisation du CPU, il n'y a aucune logique dans le fait qu'une haute utilisation du CPU implique une meilleure gestion des opérations bloquantes!
        euh, un petit peu quand même... Plus le proc est utilisé, moins il y a d'opération bloquante (opration bloquante -> non utilisation du CPU)... Evidemment le proc pourait être utilisé inutilement, mais il faut alors tenir comtpe du temps total d'exécution de l'opération.
        Si le système de fichier met moins de temps à faire une manip mais consomme plus de CPU, c'est qu'il est resté moins longtemps en attente sur une opération bloquante (il utilise donc mieux les ressources CPU à sa disposition), le système de fichier est donc plus performant.

      • [^] # Re: Pas d'inquiétudes

        Posté par  . Évalué à 6.

        Pour ce qui est de l'utilisation du CPU, il n'y a aucune logique dans le fait qu'une haute utilisation du CPU implique une meilleure gestion des opérations bloquantes! Si la gestion des opérations bloquantes est bonne, je suis d'accord qu'une plus haute utilisation du CPU n'est pas un gros problème, mais je ne vois pas d'autres liens entre ces 2 paramètres.

        Ben fait le test suivant :

        Tu ecris deux softs qui font le meme gros calcul.

        Dans un des 2 tu mets un sleep() de 1s de temps en temps.

        Compares le % de CPU utilise dans les 2 cas, marrant, mais le process le plus lent a le % de CPU le plus faible.

        Tu peux comprendre ca de la maniere suivante :

        Les 2 softs font 200'000 operations.

        Un soft les fait en 4s --> 50'000 op/s
        L'autre les fait en 10s --> 20'000 op/s (en 10s car il fait les choses dans le mauvais ordre, pas en non-bloquant, etc...)

        Resultat : le 2eme soft a un % CPU plus faible, mais il est bcp plus lent.

        • [^] # Re: Pas d'inquiétudes

          Posté par  . Évalué à 3.

          C'est vrai, mais pour toujours les mêmes opérations, mais là il s'agit de comparer deux programmes différents.
          Si c'est pas mauvais signe qu'il consomme plus de cpu, c'est pas bon signe non plus, s'il prend trop de cpu parce qu'au pire cela peut vouloir qu'il est juste mal foutu.
          Donc c'est, à opération égales, qui consomme le plus de cpu et qui prend le plus de temps?
          (mais bon ... j'y connais moins que rien! )

          • [^] # Re: Pas d'inquiétudes

            Posté par  . Évalué à 10.

            Faut comprendre cela de la maniere suivante :

            Certaines fois il vaut mieux effectuer plus d'operations, car si c'est fait comme il faut, ca va plus vite.

            Ton soft recoit une "allocation" de 50'000 cycles CPU par secondes ( chiffre fantaisiste pour l'exemple) par le scheduler, le truc dont il faut se souvenir ici, c'est que si tu ne les utilises pas, tu les perds, tes allocations ne s'accumulent pas.

            Un soft qui doit effectuer 200'000 operations, si il veut terminer son job le plus vite possible, a donc tout interet a effectuer le plus d'op/s possible, surtout sur un desktop, car un desktop c'est un gachis enorme de cycles CPU, la charge monte rarement au dessus de 25% sur un desktop, il y a donc bcp de temps dispo pour faire ses operations sans ralentir le systeme.

            Est-ce que avoir un %CPU eleve risque de ralentir tout le systeme ? Pas forcement, car le scheduler va faire la police et donner du temps a tout le monde a tour de role selon les priorites de chaque process. Le truc etant d'avoir les bonnes priorites sur les process, mettre une haute priorite a un process gourmand en CPU, c'est un moyen tres sur d'avoir une machine avec une UI tres lente.

            • [^] # Re: Pas d'inquiétudes

              Posté par  . Évalué à 2.

              (Merci pour l'explication!)

            • [^] # Re: Pas d'inquiétudes

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

              Sachant que le but d'un FS est d'écrire X donné sur le disque, si pour faire la même tache (transfert à débit fixé) un FS prends plus de CPU == il bouffe beaucoup d'op par rapport à l'autre FS == cela sera plus lent sur une machine chargée.

              "La première sécurité est la liberté"

              • [^] # Re: Pas d'inquiétudes

                Posté par  . Évalué à 3.

                Ca sera plus lent sur une machine tres chargee, mais si ta machine est tres chargee, t'auras d'autres problemes a resoudre que les qqe % de perfs de ton FS a mon avis

        • [^] # Re: Pas d'inquiétudes

          Posté par  . Évalué à 5.

          Ma remarque portait sur la relation

          "beaucoup de CPU consommé" implique "meilleure gestion des opérations bloquantes"

          Pour moi, cette relation en fausse, contrairement à la relation

          "bonne gestion des opérations bloquantes" permet "plus de CPU consommé"

          Autrement, je sais qu'il est possible de modifier la priorité des processus qui ont tendance à consommer tous les cycles alloués (les processus préemptés) de façon à ce qu'ils re-obtiennent la main plus rapidement, mais je ne sais pas si c'est géré ainsi sous Linux.

          • [^] # Re: Pas d'inquiétudes

            Posté par  . Évalué à -2.

            Ah, exactement ce que je voulais répondre (matheux inside).
            Pas besoin de faire un post, super! Euh, zut, loupé...

    • [^] # Re: Pas d'inquiétudes

      Posté par  . Évalué à 3.

      Euhhhhhhhhh comment dire.

      Un faible usage CPU provient peut être des fois d'operations bloquantes non constructives. Mais il ne faut pas oublier qu'un FS doit au final écrire sur le disque dur, et là à moins d'avoir un HD plus rapide que le CPU, ou un FS qui fait des tonnes de calculs, la plupart du temps le FS passe simplement son temps a attendre que le HD ai fait son oeuvre.

      Alors si il y a une forte occupation CPU en cas de lectures ecritures simultannées, la OK c'est pas forcement mauvaise signe. Mais une grosse occupation CPU en cas d'acces sequentiel ne me parraitrait pas etre une bonne chose du tout.

      Bref la théorie du FS qui bouffe du CPU c'est bien ne peut etre valable que si par ailleurs le FS obtient de meilleurs performances que d'autres FS. Et la on peut etre confronté à une machine lente, par exemple, ce qui ferait que la charge CPU ralentirait les access disques, ce qui est un comble :)

      Du coup je la transformerais en "le FS qui bouffe du CPU c'est pas forcement mal, selon le contexte, et selon la manière dont le CPU est bouffé".

    • [^] # Re: Pas d'inquiétudes

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

      Avec quand même une exception : sur certain serveurs ou le CPU est vraiment limité par rapport au débit du disque, les système qui ont le plus haut rapport débit/cycle sont plus interessants (cas constaté sur mon petit serveur domestique en XFS).
      Mais vu la vitesse à laquelle les proc. goinflent, on est forcés de reconnaître que les choix de reiserfs sont parfaitement adéquats.

  • # Attention : bench foireux ?

    Posté par  . Évalué à 6.

    Il faut faire gaffe au bench !
    Noyaux : 2.6.0-test<5 pour la plupart, un seul test avec un 2.6.5-rc2
    Tests provenant de/sélectionnés par Namesys qui produit ReiserFS
    Tests effectués le 26 mars 2004 et d'aout à novembre 2003 -> ReiserFS 4 non final...

    • [^] # Re: Attention : bench foireux ?

      Posté par  . Évalué à 2.

      Donc... Est-ce que quelqu'un a un/des lien(s) vers des benchs un peu moins "discutables" ou moins biaises ?

      Et qu'est-ce que reiser4 apporte a la menagere de moins de 50ans ? A part laver plus blanc que blanc et les operations atomiques qui nous degradent la motrosphere ?

      • [^] # Re: Attention : bench foireux ?

        Posté par  . Évalué à 10.

        Sebastien Binet a dit «Et qu'est-ce que reiser4 apporte a la menagere de moins de 50ans ? A part laver plus blanc que blanc et les operations atomiques qui nous degradent la motrosphere ?»

        Hormis l'aspect performance, voilà ce que reiserfs4 pourrait apporter :

        http://linuxfr.org/comments/317399.html#317399(...) ( voir mon commentaire «Posté par JSL (page perso) le 17/12/2003 à 21:01»)

        Dans cette petite bafouille, je dis que «Un truc qui m'a frappé, c'est que certaines potentialités du nouveau design sont «mis de côté» pour rester compatible avec l'interface standard VFS (Virtual File System) du kernel Linux». Pour voir où tout cela pourrait nous mener tellement plus loin à l'avenir, voir ce document :
        http://www.namesys.com/whitepaper.html(...)

        Bref, pour combattre les futures avancées de windows type winfs, hormis une tentative en userland (http://www.gnome.org/~seth/storage/,(...) sympa mais ne marche pas en ligne de commande, n'est qu'une pièce rajoutée au niveau graphique), seul reiserfs a le potentiel nécessaire, c'est pourquoi je pense qu'il serait bon de le soutenir.

  • # Attention à ce qu'on dit !

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

    Si ReiserFS est la v3, la v4 s'appelle Reiser4 et non pas Reiserfs4.

Suivre le flux des commentaires

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