Le problème avec cette hypothèse, c'est qu'elle n'est valable que s'il existe un moyen de permettre à cette tâche d'atteindre les 100% de taux d'utilisation de CPU dans son accomplissement, que ceci soit intéressant ou non en pratique.
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 :)
[^] # Re: Validation d'une hypothèse...
Posté par chucky . En réponse à la dépêche À nouveau noyau, nouveaux benchs de systèmes de fichiers. É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