Dernièrement, ce fut le tour des systèmes de fichiers d'être évalués, avec le très attendu ReiserFS-4
Au final, ext3fs et reiser4 (bien que toujours en béta) s'en sortent admirablement bien, et laissent ainsi présager un bel avenir pour Linux-2.6 From: Grant Miner
To: linux-kernel
Subject: Filesystem Tests
Date: Tue, 05 Aug 2003 21:30:48 -0500
I tested the performace of various filesystems with a mozilla build tree
of 295MB, with primarily writing and copying operations. The test
system is Linux 2.6.0-test2, 512MB memory, 11531.85MB partition for
tests. Sync is run a few times throughout the test (for full script see
bottom of this email). I ran mkfs on the partition before every test.
Running the tests again tends to produces similar times, about +/- 3
seconds.
The first item number is time, in seconds, to complete the test (lower
is better). The second number is CPU use percentage (lower is better).
reiser4 171.28s, 30%CPU (1.0000x time; 1.0x CPU)
reiserfs 302.53s, 16%CPU (1.7663x time; 0.53x CPU)
ext3 319.71s, 11%CPU (1.8666x time; 0.36x CPU)
xfs 429.79s, 13%CPU (2.5093x time; 0.43x CPU)
jfs 470.88s, 6%CPU (2.7492x time 0.20x CPU)
What's interesting:
* ext3's syncs tended to take the longest 10 seconds, except
* JFS took a whopping 38.18s on its final sync
* xfs used more CPU than ext3 but was slower than ext3
* reiser4 had highest throughput and most CPU usage
* jfs had lowest throughput and least CPU usage
* total performance of course depends on how IO or CPU bound your task is
Aller plus loin
- La news + thread sur Kerneltrap (1 clic)
# Re: À nouveau noyau, nouveau benchs de systèmes de fichiers
Posté par Panda Voyageur (site web personnel, Mastodon) . Évalué à 10.
- quelle est la dépendance avec le matériel? (en clair sur mon vieux portable, qu'est-ce que cela pourrait donner? Le disque dur n'est pas un modèle de rapidité...)
- la journalisation n'entre-t-elle pas en jeu dans tout ca? (délais supplémentaires pour synchroniser, différents modes pour ext3...)
- comment ces chiffres peuvent-ils être exploités pour une utilisation "normale" (chargement de navigateur, enregistrement d'images et de petites archives, mails, enfin des "petites" activités disques) et non pas copie du source mozilla-sync-on recommence?
Sinon est-ce qu'il y a des chiffres sur le même test avec d'anciennes versions du noyau et/ou des systèmes de fichiers? La-dessus la comparaison serait possible, non?
[^] # Re: À nouveau noyau, nouveau benchs de systèmes de fichiers
Posté par jerome (site web personnel) . Évalué à 9.
Celui ci a avant tout le mérite d'exister mais présente à mon gout assez peu de rigueur, voyons y plutôt une vertu illustrative que démonstrative.
Il faudrait en effet répéter l'opération sur différents types de machines et utiliser les différentes options offertes par les différents systèmes de fichiers, faire des manip avec en partie des gros et des petits fichiers, bref ça fait beaucoup de choses.
Ce test montre la voie, si quelqu'un se sent de le prolonger ...
# Re: À nouveau noyau, nouveaux benchs de systèmes de fichiers
Posté par bmc . Évalué à 4.
Bref, encore un bench qui ne sert pas à grand chose.
[^] # Re: À nouveau noyau, nouveaux benchs de systèmes de fichiers
Posté par jmfayard . Évalué à 8.
C'est bien d'en avoir une confirmation, parceque ça ouvre de nouveaux horizons.
Lis par exemple
http://www.kuro5hin.org/story/2003/8/9/172159/7912(...)
[^] # Re: À nouveau noyau, nouveaux benchs de systèmes de fichiers
Posté par bmc . Évalué à 1.
Quant à avoir la confirmation que Reiser est rapide dans le traitement de multiples fichiers de petite taille, on l'avait depuis longtemps, et je ne vois pas de liaison directe entre ce fait et les horizons dont parle le lien. De toute façon, ce dont parle le lien peut très bien être implémenté d'une autre façon, tant que le système de fichier te le fait apparaître de la bonne façon et rapidement, peu importe ce qui se cache réellement dessous.
[^] # Re: À nouveau noyau, nouveaux benchs de systèmes de fichiers
Posté par jmfayard . Évalué à 1.
D'après ce que j'ai compris, les filesystems classiques ont du mal avec les petits fichiers. Si tu dois utiliser un bloc de 4ko pour chaque fichier, tu ne risques pas de transformer ton fichier /etc/passwd en une arborescence
/etc
|-- passwd
|--
|-- 107
|-- shell
|-- home directory
Idem pour les tags MP3, ...
[^] # Re: À nouveau noyau, nouveaux benchs de systèmes de fichiers
Posté par skimmy . Évalué à 6.
Ok reiser4 est fait pour mieux traiter les fichiers de petites tailles, alors c'est qd meme bien de le voir en fonctionnement.
Ce genre de bench est plus credible que de pauvre sondage sur les fs preferer des lecteurs de tel ou tel site, et son tres ciblé.
Par contre tu ne trouvera peut-etre pas de bench complet qui te demonte d'utiliser tel ou tel systeme de fichier. Ton choix devar se porter sur tes besoins :
- espace occuper par le FS plutot que les données (quoi que les giga ne sont pas cher)
- temps cpu
- gestion gros fichier
- gestion petit fichier
- qualite journalisation
- recuperation de données perdues / crash
- temps acces au données/sauvegarde
- ...
[^] # Re: À nouveau noyau, nouveaux benchs de systèmes de fichiers
Posté par bmc . Évalué à 8.
Sinon, je pense que les cas où ce genre de problèmes sont réellement étudiés de façon utile sont les machines de style serveur très chargés, et certainement pas le système de fichiers de ton /home.
Personnellement, j'ai choisi ext3, certainement pas après une étude de ses performances, mais parce qu'il me permet de monter mes partitions en ext2 quand tout foire, et qu'il me permet également de ne pas attendre 3 plombes quand je reboote mon portable quand X ou le frame buffer l'ont rendu inutilisable. Le reste, je m'en fiche un peu, surtout les performances, car chacun a plus ou moins son domaine de prédilection.
Ensuite, libre à chacun de choisir son système de fichiers selon ses besoins et ses «croyances» ;)
[^] # Re: À nouveau noyau, nouveaux benchs de systèmes de fichiers
Posté par Jean-Claude Ben . Évalué à 1.
Je me voit mal utiliser Reiser en prod si c'est pas aussi sur que ext3 par exemple
[^] # Re: À nouveau noyau, nouveaux benchs de systèmes de fichiers
Posté par Pierre Jarillon (site web personnel) . Évalué à 3.
Il ne faut pas confondre avec Reiser4 http://namesys.com/v4/v4.html(...) qui est encore en phase de tests.
Reiser4 est vraiment novateur. Hans Reiser fait faire un grand pas aux systèmes de fichiers. D'ailleurs les chiffres de ce bench montrent bien qu'il s'agit d'une nouvelle génération.
La sortie initialement révue fin juin a été reportée de quelques mois. On ne peut pas le reprocher aux auteurs, car ils jouent dans un domaine où les bugs sont très mal vus. Seule l'excellence est autorisée. Et puis, y a pas l'feu au lac !
[^] # Re: À nouveau noyau, nouveaux benchs de systèmes de fichiers
Posté par jeanmarc . Évalué à 3.
Ce genre d'affirmation est un peu gratuite tant que tu ne nous dis pas dans quel cadre tu l'utilises, quels sont les tests en utilisation extrème que tu as réalisés, quelles simulations de cas critiques tu as réalisés.
Si tu l'utilises depuis plusieurs années sur une machine personnelle ou même pour un serveur web, ça ne te permet pas d'affirmer qu'il est apte au passage en production.
"En production" est un terme bien vague pour parler d'un serveur en entreprise mais, étant donné que celà peut représenter un simple serveur de fichiers de PME ou un gros cluster de base de données, ce sont les conditions d'utilisation les plus extrèmes et exigeantes qu'il faut pouvoir assurer pour pouvoir être considéré comme prés pour la production. A ce moment là, on est sûr que la plus grande partie des utilisations du produit se feront dans des conditions optimales.
[^] # Re: À nouveau noyau, nouveaux benchs de systèmes de fichiers
Posté par ptit_tux . Évalué à 4.
Le fsck de reiserfs ne gère pas les blocks défectueux contrairement à e2fsck (dont l'excellence n'est plus à démontrer).
Les quotas ne sont pas journalisés par reiserfs 3.
Reiserfs 3 ne journalise pas les donnés. Par contre reiserfs 4 le fait.
Alan Cox un peu énervé avec les demandes répétés d'avoir reiserfs dans RedHat (c'est fourni mais pas officiellement (faire "linux reiserfs" au boot lilo), et non fourni dans la version Enterprise) a indiqué que reiserfs ne passe pas les tests/critères RedHat.
Il faut bien reconnaitre que reiserfs c'est fait une mauvaise réputation en sortant trop tôt à cause de la pression de Hans sur Linus. Et Hans fait de nouveau la même erreur en demandant d'intégration de reiserfs 4 dans 2.6.0. Ext3 était dispo pour 2.2 (patch) mais n'a été officiellement intégré à Linux que dans la version 2.4.9 .
A chaque fois que j'ai eu des problèmes avec ext3, c'était lié à un problème hard. S'il n'y a pas de problème hard, ça roule. Mais moins vite que reiserfs...
[^] # Re: À nouveau noyau, nouveaux benchs de systèmes de fichiers
Posté par Boa Treize (site web personnel) . Évalué à 1.
Ah, j'ai une mauvais mémoire. Tu peux me refaire une démonstration ?
Reiserfs 3 ne journalise pas les donnés.
Il peut le faire, je crois (use the man, Luke). Il ne le fait pas par défaut car ça divise par deux les performances d'écriture.
[^] # Re: À nouveau noyau, nouveaux benchs de systèmes de fichiers
Posté par ptit_tux . Évalué à 2.
Non, j'ai pas de problème actuellement.
> Il peut le faire
Non. Mais reiserfs 4 le fait. Enfin je le garantis pas mais j'ai lu ça.
[^] # Re: À nouveau noyau, nouveaux benchs de systèmes de fichiers
Posté par Boa Treize (site web personnel) . Évalué à 1.
Hé ben moi j'ai lu (de la main de Hans Reiser) que reiserfs 3 le faisait aussi, mais que vu que ça diminuait les perfs d'écriture par deux (écriture dans le journal puis écriture dans le fichier, beurk), c'était désactivé par défaut. Seuls les metadata étaient journalisés. Un simple switch était censé permettre d'activer la journalisation complète, au dépend des performances.
La nouveauté dans reiserfs 4, c'est qu'ils ont trouvé un moyen de faire une journalisation complète sans double écriture, donc sans contre-performance, donc activé par défaut. Je vois ça comme ça : les données sont écrites sur le disque, elles font parties du « journal », puis quand elles sont commitées, elles restent sur place, c'est l'aspect « journal » qui disparaît (tout à fait faisable avec un peu de jonglage de pointeurs).
[^] # Re: À nouveau noyau, nouveaux benchs de systèmes de fichiers
Posté par syntaxerror . Évalué à 2.
toute la stratégie de gestion du disque pour l'économie d'énergie bicoze les commit
à intervalle régulier (5 secondes), à moins d'avoir un noyau récent (>= 2.4.20) et de régler
certains paramètres selon le noyo (2.4 ou 2.6).
[^] # Re: À nouveau noyau, nouveaux benchs de systèmes de fichiers
Posté par Olivier Jeannet . Évalué à 1.
Je ne comprends pas.
Un système de fichier non journalisé comme ext2 effectue également des commits à intervalle régulier (bien entendu uniquement si des écritures sont effectuées), de l'ordre de 5 secondes si je ne m'abuse. Pour ext2 il s'agit surtout d'un flush du cache disque (les pages qui sont "sales").
[^] # Re: À nouveau noyau, nouveaux benchs de systèmes de fichiers
Posté par syntaxerror . Évalué à 4.
le mécanisme d'écriture différée du noyau, ce qui empêche noflushd de remplir son office (voir le readme de noflushd).
Bon, apparement on peut en minimiser les effets en supprimant tout ce qui écrit sur le disque de manière superflue:
http://marc.theaimsgroup.com/?l=ext3-users&m=103002533601418&am(...)
http://bulmalug.net/body.phtml?nIdNoticia=1511(...)
D'autre part l'intervalle du commit pour le driver ext3 est maintenant configurable:
http://www.ussg.iu.edu/hypermail/linux/kernel/0208.1/0464.html(...)
Le patch est aussi inclus dans le 2.4.20. En revanche je suppose que "pdflush" est spécifique au noyau 2.6,
et que sous 2.4 il faut plutot bricoler bdflush (sysctl vm.bdflush)
Je teste ça dès que possible.
# Re: À nouveau noyau, nouveaux benchs de systèmes de fichiers
Posté par asailor . Évalué à 2.
reiser4 : 171.28 * 0.30 = 51.38
reiserfs : 302.53 * 0.16 = 48.40
ext3 : 319.71 * 0.11 = 35.17
xfs : 429.79 * 0.13 = 55.87
jfs : 470.88 * 0.06 = 28.25
Alors jfs est le plus efficace !
[^] # Re: À nouveau noyau, nouveaux benchs de systèmes de fichiers
Posté par jmfayard . Évalué à 1.
La y la y la y la
[^] # Re: Validation d'une hypothèse...
Posté par chucky . Évalué à 7.
Or, si tu réfléchis, le temps pendant lequel le processeur effectue ses E/S pour la tâche en question est un temps pendant lequel il ne sait contribuer à l'avancement de cette tâche, ce qui fait que même avec un gros méchant "renice -20" (augmentation au maximum de la priorité de la tâche, voir "man renice"), la tâche ne pourrait monter en charge de CPU pour atteindre les 100%.
Ainsi, tu ne peux dire que la tâche en Jfs ne tourne qu'en 28.25 secondes... puisqu'il n'y a pas moyen, en pratique, d'approcher cette valeur théorique. Je suppose que tous ici sont d'accord sur le fait qu'on veut des performances en pratique... et que celles de la théorie ne nous intéressent pas trop ;)
Je ne dis pas cela pour valoriser un autre système de fichiers par rapport à JFS, mais juste pour relever la falsification possible à partir de ton hypothèse... qui m'avait pourtant séduit a priori.
De toute façon, pour ceux qui cherchent à trouver le meilleur système de fichiers(FS en anglais) pour leurs besoins, il vaudrait mieux qu'ils cherchent dans les particularités de chacun de ces systèmes. Par exemple, dans les possibilités de :
- d'auto-défragmentation (souvent, en évitant la fragmentation ;) tout court)
- récupération de fichiers effacés "maladroitement" (possible avec ext3fs),
- indication au FS que certains clusters sont désormais inutilisables, souvent appelé "marquage des bad clusters" par les geeks (impossible avec ReiserFS une fois le FS créé),
- modifier la taille de la partition et du FS une fois qu'il est créé,
- trouver des outils stables de management de ce type de FS (pas en alpha ou bêta ou Release Candidate (RC)), pour la distibution linux qu'on utilise... faudrait voir à ne pas scier la brance sur laquelle on est assis !
Il existe aussi d'autres caractéristiques :
- la rapidité de la suppression de fichiers en masse (surprenante rapidité avec ReiserFS),
- la taille maximale des fichiers (en Gigaoctets ou Teraoctets),
- la taille maximale du système de fichiers (FS) (en Gigaoctets ou Teraoctets),
- la perte de place pour les petits fichiers.
Enfin, il y a le type de soutien que l'on peut attendre du journal (pour pas perdre des cycles de cpu pour rien) :
- récupération en cas de plantage système ou de crash disque (et pas de trolls sur les possibilités de plantage de linux, svp)
- surcoût en taille pour le journal (utilisable sur disquettes ? sur petites partitions (par exemple sur un i386 avec un hdd de 40 mégas...)
- coût des synchronisations : borne de temps maximale, si elle existe...!
- ...
Enfin, tout ça pour dire que pour choisir le bon FS, dans mon cas, je préfère lire des documents un peu plus détaillés sur ces FS en question, plutôt que de me fier à des résultats de benchmarks qui n'égratignent qu'un tout petit peu les enjeux de ces FS. Et puis, choisir les plus connues, c'est s'assurer de trouver plus facilement de l'aide si on a un pépin :)
Chucky
[^] # Re: Validation d'une hypothèse...
Posté par syntaxerror . Évalué à 1.
nan, désolé, aux dernières nouvelles ce n'était pas possible:
http://lists.insecure.org/lists/linux-kernel/2003/Jan/1763.html(...)
[^] # Re: Validation d'une hypothèse...
Posté par asailor . Évalué à 1.
Le petit calcul simple que j'ai fait permet de voir (en partie) l'optimisation du code pour effectuer une tâche donnée (ici le test).
JFS (que je n'ai jamais utilisé, donc je n'en fais pas du tout la promotion) semble donc avoir le code le plus performant car au final c'est celui qui utilise le moins le CPU par rapport à la tâche à effectuer.
En prenant les cas extrêmes suivants, je pense qu'un bon système de fichier est tout simplement un bon équilibre entre ces 2 cas (sûrement très difficile à trouver) :
1) le processeur est à 100% pendant 150s
avantage : c'est le plus rapide
inconvénient : tu ne peux presque plus rien faire avec ton ordinateur pendant qu'il manipule des fichiers
2) le processeur est à 0.01% pendant 500s
avantage : ton processeur est libre à 99% tout le temps
inconvénient : c'est le plus lent
Mais, je reste persuadé que le code 2) est le plus efficace car 500s * 0.01 = 5s au lieu de 150s (il y a un facteur 30) !
Il ne faut pas me faire dire ce que je n'ai pas dit : je n'ai pas dit que JFS tournait en 28.25 secondes, j'ai dit que c'était le temps CPU utilisé pour exécuter la tâche (enfin ce n'était peut être pas clair, j'espère que ça l'est plus maintenant).
De même que mon hypothèse n'est pas falsificatrice dans le sens que je viens de donner plus haut, tout dépend de ce que l'on met dans "efficacité". C'était pour se poser la question de ce que peut être l'efficacité d'un système de fichier.
On peut donc conclure que l'on peut calculer un certain nombre de quantités à partir des chiffres des benchmarks qui ont chacune un intérêt.
:o)
[^] # Re: Validation d'une hypothèse...
Posté par Christophe . Évalué à 2.
Avec la montee en puissance des processeurs, l'optimisation ce fait maintenant sur les acces disque et memoire qui sont beaucoup plus couteux. Et ca explique (en partie) pourquoi Reiser4 est plus rapide meme si il utilise plus de CPU.
amicalement
[^] # Re: Validation d'une hypothèse...
Posté par asailor . Évalué à 1.
toujours sans arrière pensée trollitique ;)
[^] # Re: Validation d'une hypothèse...
Posté par Christophe . Évalué à 1.
De plus les acces fs sont demandes par des apllications (generalement) , elles sont donc bloquees tant que le noyau ne repond pas. Enfin ...
je peux dire trollistiquement ?
non ?
bon ben tant pis.
et pis comme un peu de culture g ne fait pas de mal (a defaut de lien plus specialise) :
Modern Operating Systems (2nd Edition)
by Andrew Tanenbaum
ISBN: 0130313580
[^] # Re: Validation d'une hypothèse...
Posté par pasBill pasGates . Évalué à 4.
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.
[^] # Re: Validation d'une hypothèse...
Posté par asailor . Évalué à 1.
Il me semble que le benchmark dont nous parlons a été fait avec un CPU sans charge de calcul (quel qu'il soit, système ou non).
En faisant l'hypthèse que la charge de calcul est importante (100% s'il n'y a rien d'autre à faire) ET que le scheduler ne donne pas la priorité absolue à la gestion du système de fichier (mais ça je ne le sais pas), si le système lui donne un peu de temps CPU de temps en temps, alors il y a un goulot d'étranglement au niveau du CPU pour la gestion du système de fichier.
Si ce goulot peut atteindre 30% du CPU alors reiser4 sera le plus rapide, si ce goulot est de 6% alors JFS sera le plus rapide non ?
[^] # Re: Validation d'une hypothèse...
Posté par pasBill pasGates . Évalué à 3.
Il faut lire ces benchs de la facon suivante :
Reiserfs est CAPABLE d'utiliser au maxium le temps CPU qu'on lui donne.
Ca veut pas dire que Reiserfs est un ogre niveau cpu.
Le scheduler il va filer une tranche de temps a ton process 'mv', quel que soit le filesystem en dessous. Avec JFS et autres, le process 'mv' doit s'arreter de temps en temps pour attendre sur qqe chose (mutex, I/O,...) et de ce fait, redonne la main au system avant la fin de sa tranche de temps, donc son pourcentage d'occupation CPU est plus faible, reiserfs lui utilise pleinement le temps qui lui est alloue, et finit plus vite car il a besoin de moins de tranches de temps pour finir son boulot.
Sur un systeme charge, 'mv' se verra attribuer x tranches de temps, quel que soit le fileystem utilise. Avec JFS ces tranches ne seront pas utilisees pleinement car le fileystem s'arrete pour attendre certaines choses, avec reiserfs ces tranches seront pleinement utilisees.
Bref, lis ca comme : JFS et autres gaspillent le temps qui leur est alloue, alors que reiserfs l'utilise mieux.
Il se peut bien que reiserfs ait besoin de plus de cycles pour faire la meme chose, mais la realite est que sur un systeme, meme charge, il y a des millions de cycles cpus qui ne sont pas utilises, et au final, reiserfs fait les choses en moins de temps en secondes que les autres, meme si il lui faut peut-etre plus de cycles CPU. Et sur cette planete, la seule unite qui nous interesse c'est les secondes, les cycles cpu on s'en tape car on en a assez.
[^] # Re: Validation d'une hypothèse...
Posté par asailor . Évalué à 1.
Alors pourquoi cette remarque :
"The first item number is time, in seconds, to complete the test (lower
is better). The second number is CPU use percentage (lower is better)."
?
[^] # Re: Validation d'une hypothèse...
Posté par pasBill pasGates . Évalué à 1.
Un usage CPU de 30% pendant 3 secondes c'est mieux que 10% du CPU pendant 9 secondes.
[^] # Re: Validation d'une hypothèse...
Posté par asailor . Évalué à 1.
http://testing.lkml.org/slashdot.php?mid=322496(...)
voici quelques extraits :
I just can't believe reiser4 is so fast on an unloaded system (from the numbers one could also expect it's the slowest on loaded systems and JFS seems to be the winner on those).
Hans Reiser lui même dit cela :
reiser4 cpu consumption is still dropping rapidly as others and I find kruft in the code and remove it. Major kruft remains still.
(kruft = unpleasant substance)
et les nouveaux résultats (plus d'opérations) incluent *mes* calculs :o)
http://epoxy.mrs.umn.edu/~minerg/fstests/results.html(...)
[^] # Re: Validation d'une hypothèse...
Posté par pasBill pasGates . Évalué à 2.
Les locks et autres sont des problemes tres connus, et le symptome No1, c'est un faible usage du cpu et un temps d'execution plus long.
[^] # Re: Validation d'une hypothèse...
Posté par Boa Treize (site web personnel) . Évalué à 2.
Il y a encore des « bad clusters » sur les disques durs modernes ? Ça fait pas mal d'années que lorsqu'un secteur est défectueux, les disques durs allouent de manière transparente un secteur de remplacement pris dans une réserve ad hoc. La taille de la réserve est calculée par le fabricant pour pallier à toute déficience de secteur sur la durée de vie prévue du disque dur (plusieurs centaines de milliers d'heures).
Et puis, même en cas de « bad cluster », une petite remise à zéro du disque (avec l'utilitaire quivabien du constructeur), et ça repart.
[^] # Re: Validation d'une hypothèse...
Posté par Julien Danjou (site web personnel) . Évalué à 1.
Oui et 6 mois apres le disque lache en moins de 2h.
C'est du vécu. Avec un disque d'une celebre marque a 3 lettres.
[^] # Re: Validation d'une hypothèse...
Posté par ptit_tux . Évalué à 2.
SCO ?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Validation d'une hypothèse...
Posté par PeYotL . Évalué à 2.
heureusement c'est reglé, et les serie 120GXP et 180GXP etait meme dans les plus fiables..
[^] # Re: Validation d'une hypothèse...
Posté par Fabien Jakimowicz . Évalué à 2.
C'est un peu comme les clans vim/emacs ou kde/gnome ...
[^] # Re: À nouveau noyau, nouveaux benchs de systèmes de fichiers
Posté par Tutur . Évalué à 1.
Les temps dd dependent des caratéristiques du dd (temps d'accés, vitesse de transfert) et de l'emplacement physique des fichiers sur le disque.
De plus, dans certains cas, il peut être intéressant d'avoir des accés disques rapide car si d'autres process ont besoin du dd, ils doivent alors attendre.
En plus l'utilisation du proc depent du hard. Avec des dd SCSI, il serait presque nul, même avec un proc peu puissant. Au fait dans ce % quel est la part utilisé pour gerer le hard?
[^] # Re: À nouveau noyau, nouveaux benchs de systèmes de fichiers
Posté par Olivier Jeannet . Évalué à 1.
Tu confonds 2 choses : le temps pris par les accès disque à bas niveau, et le temps pris par le filesystem lui-même.
Dans le temps, l'IDE était géré essentiellement par le CPU et donc les accès disque avaient tendance à le monopoliser (ce qui entre autres n'arrangeait pas les affaires de ceux qui gravaient un CD). A présent que l'IDE utilise les transferts DMA, le taux d'occupation du processeur est assez bas (quelques pourcents), mais toujours supérieur à celui constaté avec du SCSI. Ca se ressent à l'usage même si les mesures semblent montrer une différence assez faible.
Dans le benchmark dont il est question ici, on compare le temps pris par chaque filesystem (sur un même disque). En effet, le filesystem utilise des algorithmes plus ou moins complexes pour placer ses données sur le disque. Reiserfs 4 prend plus de temps mais ça vaut le coup puisqu'il est plus rapide, il doit être plus astucieux dans l'agencement des lectures et des écritures sur disque.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.