Banc d'essai de FS journalisés, le retour

Posté par  . Modéré par Fabien Penso.
Étiquettes :
0
9
avr.
2002
Linux
En novembre dernier, j'ai publié des comparatifs de performances de systèmes de fichiers journalisés sous Linux (ext3, reiserfs, xfs, jfs). Je reviens avec une nouvelle configuration matérielle (un bi-processeur avec disque SCSI) ainsi que des benchmarks supplémentaires. Le but initial était de voir si xfs justifie sa réputation de FS plus adapté un environnement professionnel (SMP + SCSI). Au vu des résultats, il me semble que ce n'est pas encore le cas au stade du développement actuel.

Aller plus loin

  • # Pas de gagnant !

    Posté par  . Évalué à 10.

    D'après l'article, on voit qu'il n'y a pas de fs vraiment meilleur qu'un autre. En fait ça dépend de l'utilisation qu'on en fait ...

    • [^] # Re: Mais un perdant....

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

      Regardez ce qu'il y a en bas de http://www.linux-france.org/article/sys/ext3fs/Benchmarks/benchmark(...)
      C'est quand même très grave pour un FS sur une machine de production.
      Espérons que ce problème soit résolu, car xfs était à la base un bon FS.

      • [^] # Re: Mais un perdant....

        Posté par  . Évalué à 8.

        Remarque qu'il faut pas être bien quand même pour lancer des benchs sur une machine en production.

      • [^] # Re: Mais un perdant....

        Posté par  . Évalué à 2.

        Oui, si seulement la liste de diffusion xfs avait pu avoir trace de ces plantages... Liu, que dis-tu de poster sur la ml à propos de ce problème ? Jamais eu ce genre de problème de mon coté, pas plus après une récuperation après panne. Je me demande d'ailleurs ce que donnerait les autres FS... Il est vrai que je ne me suis pas amusé à stresser les machines non plus. Ca va me donner des idées...

        • [^] # Re: Mais un perdant....

          Posté par  . Évalué à 8.

          Le plantage de xfs avec dbench est un problème connu, il est mentionné dans la FAQ. La méthode préconisée est d'augmenter la taille du journal, ce que j'ai fait. Il ne faut pas trop se focaliser sur ce problème. Dbench génère une charge système peu habituelle. Cela dit, j'ai quand même comme impression que xfs est moins stable que ext3 et reiserfs. C'est un FS plein de fonctionalités intéressantes, mais pas encore mûr ahma. Vu son fonctionnement (le patch xfs est énorme, et modifie pas mal de paramètres du noyau), et le peu d'enthousiame de ses développeurs à découper le patch pour que Linus les accepte, xfs n'est pas près d'être intégré dans le noyau officiel. C'est un handicap pour pouvoir être testé par un plus grand nombre d'utilisateurs. Mais il paraît que la Slackware va intégrer xfs dans sa prochaine distribution. Est-ce un signe de stabilisation ? Les autres FS n'ont pas provoqué de plantage chez moi, sauf jfs dans une version antérieure. Poster sur la liste xfs, pourquoi pas. Mais dans ce genre de situation, la chose qu'on me demandera de faire en premier, c'est d'essayer la dernière version d'abord. Il faut que je me trouve une soirée pour ça. Pour répondre au message de oje, je ferais remarquer que la compilation du noyau fait peu intervenir le système de fichiers. C'est le CPU qui fait un rôle primordial. C'est pour ça qu'on ne voit pas de différence entre les FS. Pour répondre à Cédric Delfosse: j'ai testé xfs sous 2.4.18 pour l'effacement d'un répertoire (voir http://www.linux-france.org/article/sys/ext3fs/Benchmarks/petit-test.txt ) xfs est encore loin de rattraper les autres sur ce point. Un test approfondi serait intéressant. Mais il faut savoir que ça prend beaucoup de temps mine de rien :). Liu

          • [^] # Re: Mais un perdant....

            Posté par  . Évalué à 2.

            Pour répondre au message de oje, je ferais remarquer que la compilation du noyau fait peu intervenir le système de fichiers. C'est le CPU qui fait un rôle primordial.

            En effet le CPU est prépondérant dans ce cas, mais comme il y a plusieurs dizaines de méga de sources, on pourrait espérer qu'un FS rapide améliore plus nettement la compilation. Dans pas mal de cas de la vie courante, le CPU attend les données plutôt que l'inverse (le CPU est plus rapide que la mémoire, qui elle est plus rapide que le disque). Un bi-P3 1 GHz ça dépote sacrément quand même !
            Il serait intéressant de voir ce que donnerait la compilation du noyau stocké en ramdisk (ramdisk classique ou tmpfs). Il est possible que la différence ne soit pas énorme en effet.

            A mon avis, le genre de test qui est vraiment significatif est un test de base de données. Le test PostMark (ça dépend comment il est fait) en est un et semble avoir des résultats significatifs. J'avais fait des tests de ext2/ext3/reiserfs avec PostgreSQL et pgbench (bench du type TPC-B) et ça lissait pas mal les résultats bruts des FS, c'était sur un noyau 2.2 . ext2 était en tête d'environ 6-10 %.

            • [^] # Re: Mais un perdant....

              Posté par  . Évalué à 1.

              Bonne idée de compiler dans tmpfs. Mais pour l'instant je n'ai que 128 Mo de ram, le reste ayant grillé. Dès que possible je mettrai les tests à jours.

              J'ai passé xfs/2.4.18 avec dbench, pas de plantage après six tests à 42 clients et 2 tests à 60 clients. La performance est très légèrement inférieure à xfs/2.4.16, mais on a gagné en stabilité, ce qui est plus important ahma.

              Liu

            • [^] # Re: Mais un perdant....

              Posté par  . Évalué à 1.

              Je viens de faire la compilation dans /dev/shm tmpfs (de taille 256 mo) à la maison. Le temps est
              real 5m23.099s
              user 5m08.940s
              sys 0m14.120s
              Soit 2 à 3% de différence qu'avec la compilation sur une partition normale. Donc le FS joue vraiment peu de rôle ici. Avec mon .config, il se crée moins de 400 fichiers .o.

    • [^] # Re: Pas de gagnant !

      Posté par  . Évalué à 2.

      D'après l'article, on voit qu'il n'y a pas de fs vraiment meilleur qu'un autre Excepté sur les tests style Mongo ou Bonnie, qui sont un peu artificiels (même s'ils peuvent servir à mettre en évidence des faiblesses), les résultats sont en effet assez proches, le cas le plus flagrant étant la compilation de noyau. C'est même vexant d'avoir aussi peu de différence après tous ces efforts ! (même pas 1% pour le bi-proc, moins de 3% pour la machine "home") 
      (dans l'ordre :       ext2,  ext3,  rfs,   xfs,   jfs)
cas machine bi-proc : 4m10s  4m11s  4m12s  4m12s  4m12s
cas machine maison  : 5m27s  5m33s  5m34s  5m36s  5m31s
      Heureusement, pour le test du serveur de mail (PostMark), les différences semblent bien être là.

  • # Reiserfs RULEZ

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

    Bah quoi c vrai quand meme. :)

    --->> [jesors]

    • [^] # Re: Reiserfs RULEZ

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

      Il y a plus de deux ans que je l'utilise systématiquement. Je l'ai installé sur des dizaines de machines sans le moindre problème.
      Le gain de place de reiserfs est appréciable. En moyenne de 10 à 25% et le temps d'accès à un fichier perdu au milieu de /usr/bin par exemple est raccourci. Les tailles et nombre de fichiers n'ont pratiquement plus de limitation.
      C'est pour cela que j'apprécie le travail de Hans Reiser et de son équipe de Saint-Petersbourg.

  • # Intérêt de XFS et de JFS

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

    XFS vient d'Irix, l'unix de Silicon Graphics
    JFS vient d'AIX, l'unix de IBM.
    Leur plus gand intérêt est de récupérer directement des disques issus des anciens systèmes et de les monter sur des machines Linux.
    Doit-on les utiliser pour de nouvelles machines en dehors des contextes Irix et AIX ? Je vous pose la question.

    • [^] # Re: Intérêt de XFS et de JFS

      Posté par  . Évalué à 8.

      Le JFS d'aix a des fonctionnalites qui n'existent pas ou pas encore sur la version linux. Comme par exemple la possibilité de resizer a chaud les partitions.

      • [^] # Re: Intérêt de XFS et de JFS

        Posté par  . Évalué à 10.

        Non, pas du tout. Tu ne resizes pas du JFS. Par contre, les fs sous aix (comme tout les unix qui utilisent le Logical Volume Manager) sont composés de partitions logiques (LP) mappé sur des partitions physiques (PP) de petite taille : 4 Mo ~ 128 Mo. Tu peux agrandir un filesystem en ajoutant à la volée des LP. Mais chaque PP est de taille fixe et formatée en jfs pour aix.

        • [^] # Re: Intérêt de XFS et de JFS

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

          dodgy rulez

        • [^] # Re: Intérêt de XFS et de JFS

          Posté par  . Évalué à 2.

          Tu ne resizes pas du JFS. Par contre, les fs sous aix [...] Tu peux agrandir un filesystem en ajoutant à la volée des LP

          Pas tout à fait logique ce que tu dis.
          Si tu peux agrandir un filesystem, et si ce filesystem est JFS, on PEUT "resizer" du JFS.

          Mais chaque PP est de taille fixe et formatée en jfs pour aix

          Comment ça marche ton système ? Comme tu l'exposes, on dirait qu'on peut agréger des partitions JFS classiques pour en faire une partition JFS plus grande.
          Je suis curieux de comprendre. D'habitude, le filesystem est au-dessus du système LVM, qui lui fait l'agrégation des partitions physiques pour en présenter une plus grande.

      • [^] # Re: Intérêt de XFS et de JFS

        Posté par  . Évalué à 5.

        et LVM alors ?
        http://www.sistina.com/products_lvm.htm(...)

        • [^] # Re: Intérêt de XFS et de JFS

          Posté par  . Évalué à 7.

          [ Le JFS d'aix a des fonctionnalites qui n'existent pas ou pas encore sur la version linux. Comme par exemple la possibilité de resizer a chaud les partitions ]
          et LVM alors ?

          Le LVM permet de présenter une grande partition en agrégeant des partitions plus petites, et de changer la taille de cette partition par ajout ou retrait de ces "petites" partitions. LVM fonctionne au niveau bloc et ne sait pas ce qu'est un filesystem.
          Un filesystem quant à lui fonctionne sur une partition.

          Pour pouvoir tirer parti du "resize" à chaud de LVM (en pratique, agrandir une partition LVM tout en gardant les fichiers qui sont dessus, pour avoir plus de place), il faut que le système de fichier le permette. Le FAT ou VFAT (MS-DOS) ne le permet pas par exemple, alors que ext2 et reiserfs oui. Pour ext2 c'est expérimental mais disponible il me semble. Le système de fichier de Digital Unix (Tru64 à présent) le permet aussi.
          A noter que le FAT/VFAT permet le repartionnement à froid (filesystem démonté), avec GNU Parted sous Linux et Partition Magic sous Windows.

          • [^] # Re: Intérêt de XFS et de JFS

            Posté par  . Évalué à 5.

            xfs_growfs permet d'agrandir dynamiquement un file system XFS (D'ailleurs il ne semble pas possible de ne pas l'agrandir sans etre online)

  • # XFS officiel et CVS

    Posté par  . Évalué à 10.

    Dans cet article, il est dit que la version de développement de XFS serait plus véloce que la version officielle:

    http://www-106.ibm.com/developerworks/linux/library/l-fs10.html(...)

    A peut-être bencher aussi.

  • # Amusant

    Posté par  . Évalué à 5.

    Le but de l'article etait de voir si les perf de xfs justifie sa reputation...
    et il a des plantage systeme avec xfs!

    ==> je vais rester en ReiserFS !!

Suivre le flux des commentaires

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