D'un autre coté espérer corriger des problèmes de perf juste en changeant le type de filesysteme ca me parait illusoire.
Mon avis:
- Le filesystème se doit avant tout d'être fiable et léger en conso cpu/io.
- le redimentionnement a chaud est pratique (lvm/....) sur les serveurs.
- la journalisation permet des reboot plus rapides.
Après on module en fonction de ces paramètres et d'une certaine volontré d'homogénéité du parc installé (par question d'avoir un fs différent sur chaque serveur sinon bonjour la galère pour les admins ...).
Et quand les perfs manquent y a certainement plein de solutions avant de changer de fs (plus l'optimisation est faite a haut niveau (application par exemple) plus les gains sont importants). Surtout qu'il y a des solutions simples (plus de ram ==> plus de cache disque) pour 'accélérer' les lecures/ecritures.
Et quand le service est TRES important, un cluster avec réplication des datas entre plusieurs nodes permet de s'affranchir des problèmes de fsck trop long au reboot (haute dispo de toute manière ...) voir de répartir la charge quand tous les nodes sont actifs ...
Conclusion:
Ces benchs sont TRES interessants, en premier lieu pour ceux qui DEVELOPPENT les fs. Ce genre de résultats de bench est publié régulièrement sur la liste kernel et permet aux développeurs d'optimiser leur produit aux endroits ou ils sont les plus mauvais. Du coup les fs évoluent TOUS grace à ces bench et le choix du fs pour le PROD se fait sur d'autres critères que les perfs.
[^] # Re: Ici Radio Tux.
Posté par PLuG . En réponse à la dépêche Benchmarks 'compréhensibles' des systèmes de fichiers sous Linux. Évalué à 6.
Mon avis:
- Le filesystème se doit avant tout d'être fiable et léger en conso cpu/io.
- le redimentionnement a chaud est pratique (lvm/....) sur les serveurs.
- la journalisation permet des reboot plus rapides.
Après on module en fonction de ces paramètres et d'une certaine volontré d'homogénéité du parc installé (par question d'avoir un fs différent sur chaque serveur sinon bonjour la galère pour les admins ...).
Et quand les perfs manquent y a certainement plein de solutions avant de changer de fs (plus l'optimisation est faite a haut niveau (application par exemple) plus les gains sont importants). Surtout qu'il y a des solutions simples (plus de ram ==> plus de cache disque) pour 'accélérer' les lecures/ecritures.
Et quand le service est TRES important, un cluster avec réplication des datas entre plusieurs nodes permet de s'affranchir des problèmes de fsck trop long au reboot (haute dispo de toute manière ...) voir de répartir la charge quand tous les nodes sont actifs ...
Conclusion:
Ces benchs sont TRES interessants, en premier lieu pour ceux qui DEVELOPPENT les fs. Ce genre de résultats de bench est publié régulièrement sur la liste kernel et permet aux développeurs d'optimiser leur produit aux endroits ou ils sont les plus mauvais. Du coup les fs évoluent TOUS grace à ces bench et le choix du fs pour le PROD se fait sur d'autres critères que les perfs.