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
- Plus d'infos sur Linux Gazette (42 clics)
# Chiffres FAT32
Posté par Manuel Menal . Évalué à 1.
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 Anonyme . Évalué à 0.
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 Jak . Évalué à 1.
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 Anonyme . Évalué à 0.
[^] # Re: J'comprends pas...
Posté par Jak . Évalué à 1.
Je vois pas bien le rapport entre la tailles du noyau et celle des sources, là...
[^] # Re: J'comprends pas non plus...
Posté par Manuel Menal . Évalué à 1.
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 Anonyme . Évalué à 0.
[^] # Re: Il faire atention au hardware
Posté par Anonyme . Évalué à 0.
[^] # Re: Il faire atention au hardware
Posté par Jak . Évalué à 1.
[^] # Re: Il faire atention au hardware
Posté par Anonyme . Évalué à 0.
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 Anonyme . Évalué à 0.
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 Jak . Évalué à 1.
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 Anonyme . Évalué à 0.
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 Jak . Évalué à 1.
[^] # NTFS
Posté par Anonyme . Évalué à 0.
# Fat32 plus rapide que ext2 ou reiserfs ?
Posté par Anonyme . Évalué à 0.
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 Anonyme . Évalué à 0.
[^] # Re: Fat32 plus rapide que ext2 ou reiserfs ?
Posté par Anonyme . Évalué à 0.
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 Jar Jar Binks (site web personnel) . Évalué à 1.
En tout cas, je n'ai jamais vu de vraies recherches durant 3 secondes sous Windows.
[^] # Re: Fat32 plus rapide que ext2 ou reiserfs ?
Posté par Étienne . Évalué à 1.
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 Anonyme . Évalué à 0.
[^] # Re: Fat32 plus rapide que ext2 ou reiserfs ? Teste sous linux
Posté par Anonyme . Évalué à 0.
Résultat : ça fait plus de 6 minutes que ça tourne et je n'ai toujours pas le résultat ! (Je n'avais pasmis /mnt dans le test)
JP
# et JFS ????
Posté par Anonyme . Évalué à 0.
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 Anonyme . Évalué à 0.
J'aime bien mon ext2. :)
# Commentaire de l'auteur du test
Posté par Anonyme . Évalué à 0.
"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.