Comparatif de XFS, ReiserFS, Ext2FS et Fat32

Posté par  . Modéré par Fabien Penso.
Étiquettes : aucune
0
13
mai
2001
Technologie
Le comparatif est en espagnol mais les chiffres des tableaux parlent d'eux-même.

XFS est apparemment le plus rapide sauf pour la suppression de répertoires avec plusieurs fichiers.
ReiserFS n'est pas trop mauvais non plus mais le temps de copie d'un fichier .tar contenant les sources du noyau Linux est très variable (entre 16,94 et 63,48 secondes).
Ext2FS est globalement correct et Fat32 est le moins performant.

Le premier tableau donne les temps pour l'écriture, la lecture et la suppression d'un fichier relativement gros (256 Mo) et le deuxième sur la copie, l'extraction et la suppression d'un fichier .tar de plus de 100Mo (contenant les sources du noyau 2.4.4) ainsi que de la suppression de l'arborescence créée.

Rappelons que ReiserFS et XFS sont des systèmes de fichiers journalisés, que XFS est disponible en version 1.0 depuis peu et que le support de ReiserFS est intégré au noyau 2.4.x de Linux.

Aller plus loin

  • # Chiffres FAT32

    Posté par  . Évalué à 1.

    Ce comparatif est en effet très intéressant, et plutôt sans surprise, puisque n'importe quel personne qui connaisse un peu les différents Systèmes de fichiers journalisés sait que XFS est plus performant que ReiserFS par conception.

    Cependant, je voudrais nuancer un point : D'après mon expérience, il est vrai que la copie de fichiers sous Windows est plus lente que sous Linux. (attention, ceci n'est pas un troll, juste une constatation). Cependant, les mesures du comparatif ayant été prises sous Linux, il me semble que les chiffres doivent être un peu faussés, puisque le support FAT de Linux n'égale probablement pas celui de Windows... D'autant plus qu'elles n'ont pas un grand intérêt, excepté
    pour troller, car on met rarement une partition montée sur un répertoire de l'architecture standard (j'entends par là, /, /usr, /var, etc.).

    Enfin, sinon, il s'agit d'un test effectivement intéressant. Et qui alimente le débat sur le remplacement de ReiserFS par XFS dans le noyau Linux....
    • [^] # Re: Chiffres FAT32

      Posté par  . Évalué à 0.

      Je pense que l'integration de XFS, tout comme Reiserfs, dans le noyau est une erreur.

      On a le droit de choisir Reiserfs ou XFS ou Ext2 ou ext3 si ça nous chante.

      Pour un particulier Reiserfs suffit amplement. Pour un serveur c'est different...
      • [^] # J'comprends pas...

        Posté par  . Évalué à 1.

        > Je pense que l'integration de XFS, tout comme Reiserfs, dans le noyau est une erreur.

        Et, tu fais comment pour démarrer un système qui n'a <g>aucun</g> système de fichiers intégré au noyau? (Attention, j'ai pas dit que c'était impossible, mais ça ne me semble pas évident, en tout cas je ne vois pas comment faire.)
        • [^] # Re: J'comprends pas...

          Posté par  . Évalué à 0.

          Je dis simplement que, a force de vouloir tout integrer dans le noyau les differents SDFJ, e benh ça va faire un noyau lourd. Le mieux c'est de faire un noyau standard auquel on puisse patcher celui ci si necessaire (Methode SuSE)
          • [^] # Re: J'comprends pas...

            Posté par  . Évalué à 1.

            Ah, ben, non, justement, parce que le problème, c'est que si tu veux un système entièrement en XFS par exemple, ben déjà, c'est nettement plus simple d'avoir un support dans le noyau, et puis il n'y a que les sources qui grossissent, quand tu recompiles, tu n'es pas obligé de mettre le support pour tous les systèmes de fichiers imaginables. Tu sais, les sources du noyau 0.99 sont beaucoup plus légères que celles des 2.4, tu n'as qu'à utiliser celle-là.
            Je vois pas bien le rapport entre la tailles du noyau et celle des sources, là...
          • [^] # Re: J'comprends pas non plus...

            Posté par  . Évalué à 1.

            Il me semble que tes arguments sont erronés.
            Il faut d'abord bien préciser de quoi on parle :
            - Parles-tu de la taille des sources du noyau ?
            - Parles-tu de la taille du noyau une fois compilé?

            Dans le premier cas, tu as raison, le support de XFS
            augmentera la taille du tarball. Maintenant, est-ce vraiment un débat ? Linux est un noyau monolithique qui est donc destiné à accueillir en son sein le support de _beaucoup_ de choses. Si vraiment celà te dérange, il existe effectivement des micro-noyaux multi-serveurs, tel le Hurd, qui te conviendront peut-être... Il est aujourd'hui clair que toute implémentation d'un support de FS (ou d'autres choses) libre, stable, et suffisamment bien codée est destinée à être accueillie dans les sources du noyau, à condition bien sûr que celà ait un intérêt. Or, il est clair que XFS a un intérêt, puisque c'est un JFS expérimenté et qu'il est assez performant. (attention, je n'ai pas pris parti pour les noyaux monolithiques :-)

            Si tu parlais de la taille du noyau une fois compilé, comme le terme "noyau lourd" pourrait le faire penser, je ne pense pas que ça ait quelque chose à faire ici : Si tu n'utilises pas XFS, ne met pas le support XFS dans ton noyau.
            Logiquement, ne devrait être inclus dans ton noyau que le support du format de ta partition /, ensuite, s'il te prend l'envie de rajouter le support XFS en module, ça ne ralourdira pas ton noyau.

            Quant à dire que ReiserFS suffit aux utilisateurs,
            c'est probablement vrai, mais pourquoi ne pas leur
            donner encore mieux ?

            Je pense que le réel débat ici reste monolithic vs. µ-kernel, mais une news n'y suffirait pas :-)
  • # Il faire atention au hardware

    Posté par  . Évalué à 0.

    La vitesse de transfert depend de la geometrie du disque dur et de la zone ou la partition est creee,en effet surle bord d'un plateau ca va beaucoup plus vite.Je ne lis pas l'espagnole donc je ne sais pas si il a fait les tests avec dans les memes conditions de lecture physique.
    • [^] # Re: Il faire atention au hardware

      Posté par  . Évalué à 0.

      Le gars dit qu'il a fait les tests à chaque fois sur la meme partition dont il changeait le FS à chaque fois.
      • [^] # Re: Il faire atention au hardware

        Posté par  . Évalué à 1.

        Oui, mais c'était à préciser, parce que le seul truc que je sais dire en Espagnol, c'est "No hablo Espagnol." :)
    • [^] # Re: Il faire atention au hardware

      Posté par  . Évalué à 0.

      De toutes facons le bench est nul.
      On ne peut pas tirer des conclusions avec DEUX tests.
      En particulier chez moi j'ai du Ext2 et du ReiserFS, et je peux confirmer que les effacements de gros fichiers ou d'arbre sont 10 ou 100 FOIS plus rapide sous ReiserFS que sur Ext2. Or ce bench ne met meme pas en evidence ce fait connu de tous !!!!

      Bref, A Jeter !
  • # Réference mais pas très récente

    Posté par  . Évalué à 0.

    Cet article est connu comme la réference sur la comparaison des systèmes de fichiers sous Linux (journalisés ou pas) : cité dans le Linux Mag d'avril 2001 par ex.

    Mais le problème est qu'il date de juillet 2000 !!! Depuis XFS est sorti en version 1.0, ReiserFS est maintenant intégré dans les noyaux 2.4...
    • [^] # Re: Réference mais pas très récente

      Posté par  . Évalué à 1.

      Bon, ya quelqu'un qui traduit, histoire qu'un autre puisse faire les tests dans des conditions similaires (au niveau de l'expérimentation, pas du matos, hein? :) ) ?
      A ce sujet, y a-t-il une prévision pour l'intégration de XFS dans un noyau prochainement?
      • [^] # A mon avis, pas avant la 2.5

        Posté par  . Évalué à 0.

        Ca represente une grosse modification, quand meme!

        Donc il est peu probable que ce soit pris en compte dans la 2.4, je crois qu'un des objectifs de la 2.5 est de modifier le systeme de fichier de telle maniere a ce que l'introduction de n FS journaliste nécéssite d'avoir dans le noyau n Interfaces differentes.

        Donc il va falloir attendre le noyau 2.6 ou installer un patch ou attendre qu'une distribution le fasse.

        Reno (non authentifié, désolé)
        • [^] # Re: A mon avis, pas avant la 2.5

          Posté par  . Évalué à 1.

          Ok, merci, c'est tout ce que je voulais savoir. Mais disons qu'à l'époque, j'avais été surpris d'apprendre que Reiserfs allait etre intégré au noyau 2.4.1 (je me rappelais du troll Reiser/Cox :) )
    • [^] # NTFS

      Posté par  . Évalué à 0.

      et sous Win il n'y a pas que la Fat32, pourquoi le test ne tient pas compte de la ntfs ?
  • # Fat32 plus rapide que ext2 ou reiserfs ?

    Posté par  . Évalué à 0.

    Une question :
    Est-il normal qu'une recherche de fichiers sous win$ soit plus rapide qu'une recherche (avec find) sous linux sur une partition ext2 ou reiserfs ou Fat32 ?

    Chez moi, une recherche sous win$ (4.3Go en 3 partitions fat32) ne prend pas beaucoup de temps. Par contre une recherche sous linux (un disque de 9.1Go uniquement sous linux) que ce soit sous une partitions ext2 ou reiserfs ou fat, ça prend beaucoup plus de temps.....

    A+
    JP
    (Je n'ai pas mis mon login...)
    • [^] # Re: Fat32 plus rapide que ext2 ou reiserfs ?

      Posté par  . Évalué à 0.

      je ne voudrais pas dire une connerie mais je pense que cela vient en partie du nombre beaucoup plus élevé de fichiers et de répertoires présent dans une distribution linux que dans windows
      • [^] # Re: Fat32 plus rapide que ext2 ou reiserfs ?

        Posté par  . Évalué à 0.

        j'ai plus de 25000 fichiers sous C et lorsque je fais une recherche, il ne lui faut que quelques secondes (environ 4 secondes). Sur D j'en ai plus de 22000 et sur E environ 800.
        Lorsque je fais une recherche sur C,D et E, il ne lui faut qu'environ une petite quinzaine de secondes. Je n'ose pas donner les résultats sous linux ! (au minimum 3 fois plus lent)

        A+
        JP
    • [^] # Re: Fat32 plus rapide que ext2 ou reiserfs ?

      Posté par  . Évalué à 1.

      Le principe de la recherche n'est pas du tout le meme : la fonction recherche de windows recherche sur le nom (enventuellement sur la fin du nom pour determiner le type) et la date.
      En revanche le commande 'find' est beaucoup plus précise (fait un 'man find' pour t'en convaincre).
      Il me semble (dites moi si je me trompe) que la recherche windows se situe entre la commande 'find' et 'locate'.
      • [^] # Re: Fat32 plus rapide que ext2 ou reiserfs ?

        Posté par  . Évalué à 0.

        encore une je voudrais pas dire une bétise mais ne serait ce que dans les sources du noyau 2.4.4 tu as plus de douze mille éléments enfin si quelqu'un est mieux informé que moi qu'il nous éclaire
  • # et JFS ????

    Posté par  . Évalué à 0.

    le système de fichiers journalisés d'IBM, sous license GPL, n'a pas eu droit lui au comparatif !
    Ca aurait pu être intéressant pourtant ...
    et il y a aussi ext3 qui pour l'instant en est encore au stade de développement
  • # Les performances c'est bien mais...

    Posté par  . Évalué à 0.

    ou en est XFS,ReiserFS & co par rapport au support raid ( hard et soft ) et par rapport aux ACLs... Pas très loin.

    J'aime bien mon ext2. :)
  • # Commentaire de l'auteur du test

    Posté par  . Évalué à 0.

    On lui a posé cette question sur le site:
    "Was this test done with any mount options such as biosize? Biosize=13 has yielded a great improvement on my system for sure!"

    No, I didn't use that mount option. But I'm going to test it as soon as possible :-D'

    I'd like to repeat this benchmark more "seriously", with at least 5 or 10 samples (not 3) and with the latest kernel available.

    That's because I used RedHat's 2.4.2 kernel patched by SGI, and Alan Cox says that it doesn't have all important ReiserFS patches applied. I think I'll use some 2.4.4-ac or 2.4.5-pre kernel... if SGI's patches work with them :-?

    Il a utilisé un noyau patché par SGI, pas optimisé pour ReiserFS. Il annonce un test plus complet. Comme le dis quelqu'un dans le site, il faut comparer sur la lecture/écriture de plusieurs fichiers à la fois.

Suivre le flux des commentaires

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