Voici comme prévu le second épisode de notre fabuleuse saga...
*** REISERFS AUJOURD'HUI ***
Les performances des versions actuelles de ReiserFS dépendent énormément de
ce que l'on en fait. Pour les accès en lecture, c'est en général beaucoup
plus rapide qu'Ext2, surtout si l'on s'amuse à faire des déplacement un peu
partout dans les fichiers. En écriture... ça dépend. C'est souvent comparable
à Ext2, mais la journalisation ajoute quelques limitations. Tout d'abord,
les appels à fsync() ou fsyncdata() sont lents. Car actuellement, appeler
ces fonctions conduit à une synchronisation complete du journal. Toutes les
transactions sont réalisées, y compris celles concernant d'autres fichiers
que celui sur lequel on appelle fsync(). Pour cette raison, des logiciels
comme les serveurs de mail et les bases de donées sont plus lents en mise à
jour avec ReiserFS que Ext2. Solution radicale pour accélérer tout ça :
enlever la journalisation.
ReiserFS est aussi très rapide pour accéder à des répertoires contenant des
millions de fichiers. En effet, tous les noms sont indexés dans une table de
hash pour les repérer rapidement (c'est ça, le R5 hash, TEA hash, etc...) .
C'est très intéressant, car pour une application genre 'forum' par exemple,
il n'y a aucune honte à coller tous les messages dans un répertoire, un
fichier par message. Ca ne pose aucun problème, c'est simple à coder et
c'est très rapide. L'Ext2 tire très vite la langue dans des conditions
similaires.
Et pour encore plus de performances dans une telle situation, on peut
désormais accéder aux fichiers directement à partir de leur numéro d'inode.
Aucune recherche n'est donc effectuée, l'accès est immédiat. Ce sont des
travaux qui ont été réalisés pour l'optimisation de Squid, mais d'autres
applications peuvent en tirer partie.
ReiserFS a un autre intéret : il peut vous faire gagner de l'espace disque
(voir l'épisode 1 - plusieurs choses dans un même bloc) . Ce sont les
'tails'. Prenez une partition ext2, convertissez-là en ReiserFS et ... oh
miracle, vous avez environ 5% de place en plus qu'avant. Tout dépend de la
taille des fichiers, mais tous les petits fichiers de config y gagnent.
D'un autre coté, l'écriture (et surtout le fait d'y ajouter des données)
dans ces fichiers 'compactés' est plus lente qu'en temps normal. Vous pouvez
accélérer les choses en montant vos filesystems ReiserFS avec l'option
'-notail'.
Sinon, puisque quelqu'un parlait d'un problème avec Lilo... Le problème
venait justement de l'histoire des tails. Lilo a du mal à charger des données
qui débutent en plein milieu d'un secteur. Un appel système a donc été rajouté
sur les versions récentes de ReiserFS pour 'décompacter' un fichier. Cet
appel est utilisé sur les versions récentes de Lilo. Votre partition /boot
(ou /) peut donc utiliser les tails sans problème, pensez juste à mettre à
jour votre Lilo.
Quid des autres filesystems....
Ext3 : malgré son numéro de version faiblard, il est assez stable. Mais très
lent. Trop lent même. Intéret : on peut migrer de ext3 vers ext2 et
inversement facilement.
Tux2 : instable, encore beaucoup de travail à y apporter, mais le concept
est intéressant et l'auteur bosse bien dessus.
XFS et JFS : quelqu'un qui a testé longuement les derniers snapshots peut
nous en parler ?
Quoi qu'il en soit, le meilleur filesystem "traditionnel" (organisation
linéaire pour les applications, pas de plug-ins) est à mon avis celui de
Netapp. Il a d'ailleurs été programmé par l'équipe qui avait pondu le XFS à
l'époque. Mais je doute qu'il soit un jour porté sur nos linuxettes.
# REISERFS : Episode 2
Posté par j . En réponse à la dépêche ReiserFS sous Linux. Évalué à 5.
*** REISERFS AUJOURD'HUI ***
Les performances des versions actuelles de ReiserFS dépendent énormément de
ce que l'on en fait. Pour les accès en lecture, c'est en général beaucoup
plus rapide qu'Ext2, surtout si l'on s'amuse à faire des déplacement un peu
partout dans les fichiers. En écriture... ça dépend. C'est souvent comparable
à Ext2, mais la journalisation ajoute quelques limitations. Tout d'abord,
les appels à fsync() ou fsyncdata() sont lents. Car actuellement, appeler
ces fonctions conduit à une synchronisation complete du journal. Toutes les
transactions sont réalisées, y compris celles concernant d'autres fichiers
que celui sur lequel on appelle fsync(). Pour cette raison, des logiciels
comme les serveurs de mail et les bases de donées sont plus lents en mise à
jour avec ReiserFS que Ext2. Solution radicale pour accélérer tout ça :
enlever la journalisation.
ReiserFS est aussi très rapide pour accéder à des répertoires contenant des
millions de fichiers. En effet, tous les noms sont indexés dans une table de
hash pour les repérer rapidement (c'est ça, le R5 hash, TEA hash, etc...) .
C'est très intéressant, car pour une application genre 'forum' par exemple,
il n'y a aucune honte à coller tous les messages dans un répertoire, un
fichier par message. Ca ne pose aucun problème, c'est simple à coder et
c'est très rapide. L'Ext2 tire très vite la langue dans des conditions
similaires.
Et pour encore plus de performances dans une telle situation, on peut
désormais accéder aux fichiers directement à partir de leur numéro d'inode.
Aucune recherche n'est donc effectuée, l'accès est immédiat. Ce sont des
travaux qui ont été réalisés pour l'optimisation de Squid, mais d'autres
applications peuvent en tirer partie.
ReiserFS a un autre intéret : il peut vous faire gagner de l'espace disque
(voir l'épisode 1 - plusieurs choses dans un même bloc) . Ce sont les
'tails'. Prenez une partition ext2, convertissez-là en ReiserFS et ... oh
miracle, vous avez environ 5% de place en plus qu'avant. Tout dépend de la
taille des fichiers, mais tous les petits fichiers de config y gagnent.
D'un autre coté, l'écriture (et surtout le fait d'y ajouter des données)
dans ces fichiers 'compactés' est plus lente qu'en temps normal. Vous pouvez
accélérer les choses en montant vos filesystems ReiserFS avec l'option
'-notail'.
Sinon, puisque quelqu'un parlait d'un problème avec Lilo... Le problème
venait justement de l'histoire des tails. Lilo a du mal à charger des données
qui débutent en plein milieu d'un secteur. Un appel système a donc été rajouté
sur les versions récentes de ReiserFS pour 'décompacter' un fichier. Cet
appel est utilisé sur les versions récentes de Lilo. Votre partition /boot
(ou /) peut donc utiliser les tails sans problème, pensez juste à mettre à
jour votre Lilo.
Quid des autres filesystems....
Ext3 : malgré son numéro de version faiblard, il est assez stable. Mais très
lent. Trop lent même. Intéret : on peut migrer de ext3 vers ext2 et
inversement facilement.
Tux2 : instable, encore beaucoup de travail à y apporter, mais le concept
est intéressant et l'auteur bosse bien dessus.
XFS et JFS : quelqu'un qui a testé longuement les derniers snapshots peut
nous en parler ?
Quoi qu'il en soit, le meilleur filesystem "traditionnel" (organisation
linéaire pour les applications, pas de plug-ins) est à mon avis celui de
Netapp. Il a d'ailleurs été programmé par l'équipe qui avait pondu le XFS à
l'époque. Mais je doute qu'il soit un jour porté sur nos linuxettes.
-Jedi.