The solution for replacing an aging file system isnt to switch to a
brand new unproven file system, but rather a proven one with a clear
upgrade path. That file system is ext3.
Je doute fort que ReiserFS soit plus rapide. Reiser lui-même l'admettait.
Teste les débits en écriture et en lecture des deux, puis teste avec des fs presque pleins, puis teste encore avec pleins de petits fichiers. reiserfs est régulier (il garde sa vitesse même quand les disques sont très pleins, ou qu'il y a plein de petits fichiers), alors qu'ext3 a des performances très dégradées quand il y a beaucoup de fichiers et/ou beaucoup d'espace occupé.
Seigneur, Google et Giganews vont faire faillite! C'est incroyable le nombre de sysadmins qui gardent 100 000 groupes archivés pendant deux ans!
Emmanuel Florac wrote:
Je doute fort que ReiserFS soit plus rapide. Reiser lui-même l'admettait.
Teste les débits en écriture et en lecture des deux, puis teste avec des
fs presque pleins, puis teste encore avec pleins de petits fichiers.
reiserfs est régulier (il garde sa vitesse même quand les disques sont
très pleins, ou qu'il y a plein de petits fichiers), alors qu'ext3 a des
performances très dégradées quand il y a beaucoup de fichiers et/ou
beaucoup d'espace occupé.
Seigneur, Google et Giganews vont faire faillite! C'est incroyable le nombre
de sysadmins qui gardent 100 000 groupes archivés pendant deux ans!
Je doute fort que ReiserFS soit plus rapide. Reiser lui-même l'admettait.
Teste les débits en écriture et en lecture des deux, puis teste avec des fs presque pleins, puis teste encore avec pleins de petits fichiers. reiserfs est régulier (il garde sa vitesse même quand les disques sont très pleins, ou qu'il y a plein de petits fichiers), alors qu'ext3 a des performances très dégradées quand il y a beaucoup de fichiers et/ou beaucoup d'espace occupé.
Seigneur, Google et Giganews vont faire faillite! C'est incroyable le nombre de sysadmins qui gardent 100 000 groupes archivés pendant deux ans!
Jérémy JUST
Le Tue, 3 Oct 2006 21:39:50 +0000 (UTC),
Jérémy JUST , dans le message , a écrit :
Exemple de ma partition de news: <snip>
ReiserFS me permet d'économiser 43% d'espace. Et sur mon /home, ça fait 1,2%...
C'est bien pour ça que seule ma partition de news est en Reiser. :D Cela dit, ça n'enlève rien à son mérite. Les accès aux fichiers sont aussi devenu beaucoup plus rapides quand je suis passé d'ext3 à Reiser (dans le cas d'un grand nombre de très petits fichiers, donc).
-- Jérémy JUST
Le Tue, 3 Oct 2006 21:39:50 +0000 (UTC),
Jérémy JUST , dans le message
<20061003232913.168314f9@norbert.jejust.info>, a écrit :
Exemple de ma partition de news:
<snip>
ReiserFS me permet d'économiser 43% d'espace.
Et sur mon /home, ça fait 1,2%...
C'est bien pour ça que seule ma partition de news est en Reiser. :D
Cela dit, ça n'enlève rien à son mérite. Les accès aux fichiers sont
aussi devenu beaucoup plus rapides quand je suis passé d'ext3 à Reiser
(dans le cas d'un grand nombre de très petits fichiers, donc).
ReiserFS me permet d'économiser 43% d'espace. Et sur mon /home, ça fait 1,2%...
C'est bien pour ça que seule ma partition de news est en Reiser. :D Cela dit, ça n'enlève rien à son mérite. Les accès aux fichiers sont aussi devenu beaucoup plus rapides quand je suis passé d'ext3 à Reiser (dans le cas d'un grand nombre de très petits fichiers, donc).
-- Jérémy JUST
Emmanuel Florac
Le Tue, 03 Oct 2006 17:51:30 -0400, Yugo a écrit :
Seigneur, Google et Giganews vont faire faillite! C'est incroyable le nombre de sysadmins qui gardent 100 000 groupes archivés pendant deux ans!
Tu dis vraiment n'importe quoi, t'es un vrai boulet. Tu parles de ce que tu ne connais pas, tu n'as fait aucun test comparatif, et tu la ramènes. Pour ma part j'ai testé les différents filesystems sur différents configurations pendant plusieurs semaines d'affilée, parce qu'il se trouve que le stockage, c'est mon boulot.
Pour ton information, google utilise son propre FS, GoogleFS. Par ailleurs je ne sais pas ce qu'utilise giganews mais ça n'est sûrement pas un fs géant en ext3; également pour ton information, sache que free n'utilise aucun fs pour les news (15To quand même aux dernières nouvelles), parce que c'est _trop_lent_, mais une baie de disques utilisée en "raw", sur un mode FIFO, avec des serveurs de news spécialement modifiés.
-- Si ça a l'air facile, c'est difficile. Si ça a l'air difficile, c'est carrément impossible. Si ça a l'air impossible, c'est un compilateur Ada. Théorème de Stockmayer.
Le Tue, 03 Oct 2006 17:51:30 -0400, Yugo a écrit :
Seigneur, Google et Giganews vont faire faillite! C'est incroyable le nombre
de sysadmins qui gardent 100 000 groupes archivés pendant deux ans!
Tu dis vraiment n'importe quoi, t'es un vrai boulet. Tu parles de ce que
tu ne connais pas, tu n'as fait aucun test comparatif, et tu la ramènes.
Pour ma part j'ai testé les différents filesystems sur différents
configurations pendant plusieurs semaines d'affilée, parce qu'il se
trouve que le stockage, c'est mon boulot.
Pour ton information, google utilise son propre FS, GoogleFS. Par ailleurs
je ne sais pas ce qu'utilise giganews mais ça n'est sûrement pas un fs
géant en ext3; également pour ton information, sache que free n'utilise
aucun fs pour les news (15To quand même aux dernières nouvelles), parce
que c'est _trop_lent_, mais une baie de disques utilisée en "raw", sur
un mode FIFO, avec des serveurs de news spécialement modifiés.
--
Si ça a l'air facile, c'est difficile. Si ça a l'air difficile, c'est
carrément impossible. Si ça a l'air impossible, c'est un compilateur
Ada.
Théorème de Stockmayer.
Le Tue, 03 Oct 2006 17:51:30 -0400, Yugo a écrit :
Seigneur, Google et Giganews vont faire faillite! C'est incroyable le nombre de sysadmins qui gardent 100 000 groupes archivés pendant deux ans!
Tu dis vraiment n'importe quoi, t'es un vrai boulet. Tu parles de ce que tu ne connais pas, tu n'as fait aucun test comparatif, et tu la ramènes. Pour ma part j'ai testé les différents filesystems sur différents configurations pendant plusieurs semaines d'affilée, parce qu'il se trouve que le stockage, c'est mon boulot.
Pour ton information, google utilise son propre FS, GoogleFS. Par ailleurs je ne sais pas ce qu'utilise giganews mais ça n'est sûrement pas un fs géant en ext3; également pour ton information, sache que free n'utilise aucun fs pour les news (15To quand même aux dernières nouvelles), parce que c'est _trop_lent_, mais une baie de disques utilisée en "raw", sur un mode FIFO, avec des serveurs de news spécialement modifiés.
-- Si ça a l'air facile, c'est difficile. Si ça a l'air difficile, c'est carrément impossible. Si ça a l'air impossible, c'est un compilateur Ada. Théorème de Stockmayer.
talon
Emmanuel Florac wrote:
Le Tue, 03 Oct 2006 13:07:24 -0400, Yugo a écrit :
Je doute fort que ReiserFS soit plus rapide. Reiser lui-même l'admettait.
Teste les débits en écriture et en lecture des deux, puis teste avec des fs presque pleins, puis teste encore avec pleins de petits fichiers. reiserfs est régulier (il garde sa vitesse même quand les disques sont très pleins, ou qu'il y a plein de petits fichiers), alors qu'ext3 a des performances très dégradées quand il y a beaucoup de fichiers et/ou beaucoup d'espace occupé.
Je ne vois pas pourquoi tu te fatigues à nier la ligne du parti. Ext3 pourrait être 10 fois plus lent qu'on te dirait que c'est le meilleur, parcequ'il a la bénédiction des cadors de l'entourage de Linus. http://www.linux-france.org/article/sys/ext3fs/Benchmarks/ http://www.debian-administration.org/articles/388
--
Michel TALON
Emmanuel Florac <eflorac@imaginet.fr> wrote:
Le Tue, 03 Oct 2006 13:07:24 -0400, Yugo a écrit :
Je doute fort que ReiserFS soit plus rapide. Reiser lui-même l'admettait.
Teste les débits en écriture et en lecture des deux, puis teste avec des
fs presque pleins, puis teste encore avec pleins de petits fichiers.
reiserfs est régulier (il garde sa vitesse même quand les disques sont
très pleins, ou qu'il y a plein de petits fichiers), alors qu'ext3 a des
performances très dégradées quand il y a beaucoup de fichiers et/ou
beaucoup d'espace occupé.
Je ne vois pas pourquoi tu te fatigues à nier la ligne du parti. Ext3
pourrait être 10 fois plus lent qu'on te dirait que c'est le meilleur,
parcequ'il a la bénédiction des cadors de l'entourage de Linus.
http://www.linux-france.org/article/sys/ext3fs/Benchmarks/
http://www.debian-administration.org/articles/388
Le Tue, 03 Oct 2006 13:07:24 -0400, Yugo a écrit :
Je doute fort que ReiserFS soit plus rapide. Reiser lui-même l'admettait.
Teste les débits en écriture et en lecture des deux, puis teste avec des fs presque pleins, puis teste encore avec pleins de petits fichiers. reiserfs est régulier (il garde sa vitesse même quand les disques sont très pleins, ou qu'il y a plein de petits fichiers), alors qu'ext3 a des performances très dégradées quand il y a beaucoup de fichiers et/ou beaucoup d'espace occupé.
Je ne vois pas pourquoi tu te fatigues à nier la ligne du parti. Ext3 pourrait être 10 fois plus lent qu'on te dirait que c'est le meilleur, parcequ'il a la bénédiction des cadors de l'entourage de Linus. http://www.linux-france.org/article/sys/ext3fs/Benchmarks/ http://www.debian-administration.org/articles/388
--
Michel TALON
talon
Emmanuel Florac wrote:
aucun fs pour les news (15To quand même aux dernières nouvelles), parce que c'est _trop_lent_, mais une baie de disques utilisée en "raw", sur un mode FIFO, avec des serveurs de news spécialement modifiés.
Inn a un mode pour utiliser le disque raw en fifo, sans aucune modification. J'en sais quelque chose, je l'utilise.
--
Michel TALON
Emmanuel Florac <eflorac@imaginet.fr> wrote:
aucun fs pour les news (15To quand même aux dernières nouvelles), parce
que c'est _trop_lent_, mais une baie de disques utilisée en "raw", sur
un mode FIFO, avec des serveurs de news spécialement modifiés.
Inn a un mode pour utiliser le disque raw en fifo, sans aucune modification.
J'en sais quelque chose, je l'utilise.
aucun fs pour les news (15To quand même aux dernières nouvelles), parce que c'est _trop_lent_, mais une baie de disques utilisée en "raw", sur un mode FIFO, avec des serveurs de news spécialement modifiés.
Inn a un mode pour utiliser le disque raw en fifo, sans aucune modification. J'en sais quelque chose, je l'utilise.
--
Michel TALON
Côme Desplats
Michel Talon wrote:
Je ne vois pas pourquoi tu te fatigues à nier la ligne du parti. Ext3 pourrait être 10 fois plus lent qu'on te dirait que c'est le meilleur, parcequ'il a la bénédiction des cadors de l'entourage de Linus. http://www.linux-france.org/article/sys/ext3fs/Benchmarks/ http://www.debian-administration.org/articles/388
Il a un autre avantage, c'est sa fiabilité sur du matériel de merde. Et dieu sait s'il y en a un paquet.
Michel Talon wrote:
Je ne vois pas pourquoi tu te fatigues à nier la ligne du parti. Ext3
pourrait être 10 fois plus lent qu'on te dirait que c'est le meilleur,
parcequ'il a la bénédiction des cadors de l'entourage de Linus.
http://www.linux-france.org/article/sys/ext3fs/Benchmarks/
http://www.debian-administration.org/articles/388
Il a un autre avantage, c'est sa fiabilité sur du matériel de merde. Et
dieu sait s'il y en a un paquet.
Je ne vois pas pourquoi tu te fatigues à nier la ligne du parti. Ext3 pourrait être 10 fois plus lent qu'on te dirait que c'est le meilleur, parcequ'il a la bénédiction des cadors de l'entourage de Linus. http://www.linux-france.org/article/sys/ext3fs/Benchmarks/ http://www.debian-administration.org/articles/388
Il a un autre avantage, c'est sa fiabilité sur du matériel de merde. Et dieu sait s'il y en a un paquet.
talon
Côme Desplats <invalid> wrote:
Michel Talon wrote:
Je ne vois pas pourquoi tu te fatigues à nier la ligne du parti. Ext3 pourrait être 10 fois plus lent qu'on te dirait que c'est le meilleur, parcequ'il a la bénédiction des cadors de l'entourage de Linus. http://www.linux-france.org/article/sys/ext3fs/Benchmarks/ http://www.debian-administration.org/articles/388
Il a un autre avantage, c'est sa fiabilité sur du matériel de merde. Et dieu sait s'il y en a un paquet.
Ca c'est possible, je ne suis pas capable de te dire. Le gros problème de la fiabilité c'est le write-cache des disques ATA. Sans write-cache tu as des performances désastreuses, avec tu as des risques de corruption. Maintenant sur les disques modernes il y a un commande de synchronisation du cache qui marche, et il existe des systèmes journalisés qui l'utilisent pour synchroniser correctement l'écriture du cache. Là encore je ne sais pas quels sont les sytèmes journalisés Linux qui le font, j'avais cru comprendre aucun, en fait, mais je peux me tromper. L'autre problème est le sempiternel probème de la journalisation des metadata ou des metadata+data, le premier étant plus rapide, le second plus sûr.
--
Michel TALON
Côme Desplats <invalid> wrote:
Michel Talon wrote:
Je ne vois pas pourquoi tu te fatigues à nier la ligne du parti. Ext3
pourrait être 10 fois plus lent qu'on te dirait que c'est le meilleur,
parcequ'il a la bénédiction des cadors de l'entourage de Linus.
http://www.linux-france.org/article/sys/ext3fs/Benchmarks/
http://www.debian-administration.org/articles/388
Il a un autre avantage, c'est sa fiabilité sur du matériel de merde. Et
dieu sait s'il y en a un paquet.
Ca c'est possible, je ne suis pas capable de te dire. Le gros problème de la
fiabilité c'est le write-cache des disques ATA. Sans write-cache tu as des
performances désastreuses, avec tu as des risques de corruption. Maintenant
sur les disques modernes il y a un commande de synchronisation du cache qui
marche, et il existe des systèmes journalisés qui l'utilisent pour
synchroniser correctement l'écriture du cache. Là encore je ne sais pas quels
sont les sytèmes journalisés Linux qui le font, j'avais cru comprendre aucun,
en fait, mais je peux me tromper.
L'autre problème est le sempiternel probème de la journalisation des metadata
ou des metadata+data, le premier étant plus rapide, le second plus sûr.
Je ne vois pas pourquoi tu te fatigues à nier la ligne du parti. Ext3 pourrait être 10 fois plus lent qu'on te dirait que c'est le meilleur, parcequ'il a la bénédiction des cadors de l'entourage de Linus. http://www.linux-france.org/article/sys/ext3fs/Benchmarks/ http://www.debian-administration.org/articles/388
Il a un autre avantage, c'est sa fiabilité sur du matériel de merde. Et dieu sait s'il y en a un paquet.
Ca c'est possible, je ne suis pas capable de te dire. Le gros problème de la fiabilité c'est le write-cache des disques ATA. Sans write-cache tu as des performances désastreuses, avec tu as des risques de corruption. Maintenant sur les disques modernes il y a un commande de synchronisation du cache qui marche, et il existe des systèmes journalisés qui l'utilisent pour synchroniser correctement l'écriture du cache. Là encore je ne sais pas quels sont les sytèmes journalisés Linux qui le font, j'avais cru comprendre aucun, en fait, mais je peux me tromper. L'autre problème est le sempiternel probème de la journalisation des metadata ou des metadata+data, le premier étant plus rapide, le second plus sûr.
--
Michel TALON
Yugo
Michel Talon wrote:
Emmanuel Florac wrote:
Je doute fort que ReiserFS soit plus rapide. Reiser lui-même l'admettait.
Teste les débits en écriture et en lecture des deux, puis teste avec des fs presque pleins, puis teste encore avec pleins de petits fichiers. reiserfs est régulier (il garde sa vitesse même quand les disques sont très pleins, ou qu'il y a plein de petits fichiers), alors qu'ext3 a des performances très dégradées quand il y a beaucoup de fichiers et/ou beaucoup d'espace occupé.
Je ne vois pas pourquoi tu te fatigues à nier la ligne du parti. Ext3 pourrait être 10 fois plus lent qu'on te dirait que c'est le meilleur, parcequ'il a la bénédiction des cadors de l'entourage de Linus. http://www.linux-france.org/article/sys/ext3fs/Benchmarks/
Allez, on regarde! Les passages plus pertinents sont en gras.
Bench mongo Pour ce test, une configuration x-up est ajoutée. C'est simplement x2a avec un noyau mono processeur. Reiserfs est le plus rapide quand il s'agit de manipuler un grand nombre de fichiers de petite taille (400,000 ou 800,000 fichiers de 100 octets en moyenne en occurrence). Dans des situations plus ordinaires (moins de 68,000 fichiers de taille moyenne entre 1 et 100 Ko), ext2 est sans surprise le plus performant. *Ensuite, ext3 et reiserfs se* *partagent la vedette*, tandis que xfs et jfs sont très légèrement en retrait. Noter que xfs est connu pour sa lenteur dans l'effacement des fichiers. Bien que les choses se soient améliorées dans le noyau 2.4.18, le problème n'est pas encore résolu. Jfs souffre également des mêmes handicapes, mais je ne sais pas si c'est un problème connu.
Un test de la "vie réelle" qui consiste à copier les sources du noyau 2.4.16 vers la partition de test, compiler le noyau et effacer les sources. Dans ce test, *ext3 et reiserfs* sont équivalents. Avec un petit avantage pour reiserfs sur x2a. Voir aussi un autre petit test sur un portable.
Bonnie Le test est effectué sur un fichier de taille 4 fois la Ram. L'écart entre les systèmes de fichiers n'est pas vraiment significatif à mes yeux. *Noter cependant la performance d'ext3 en ré-écriture séquentielle*.
// Pour cette réécriture, ext3 est deux fois plus rapide que Ext3, mais on // n'en parlera pas.
Bonnie++ *Par ordre de performance: ext3*, reiserfs, xfs, jfs.
PostMark Bench simulant un serveur de mail. La différence est très claire entre les systèmes de fichiers: *par ordre de performance: ext3*, reiserfs, xfs, jfs.
Postal Un autre bench sur le serveur de mail. Ici la tendance s'inverse ! On trouve dans l'ordre jfs, xfs, ext3, *et assez loin derrière, reiserfs*. Ce test donne des résultats très variables (pour un même système de fichiers) sur home. *Je décide de ne pas les publier*.
// Alors, on oublie.
Dbench Ici, *reiserfs est nettement meilleur. Suivi de xfs, ext3*, et loin derrière par jfs. À noter un problème d'instabilité (plantage du système) sous xfs. Curieusement, sur x2a, un noyau mono-processeur est plus rapide en situation de haute charge pour tous les systèmes de fichiers,
// Encore que ça dépend du processeur et de la RAM: // // Ext3-wb/home | 52.5312 | 22.6350 | 8.9243 // ----------------------|-------------|--------------|-------------- // reiserfs/home | 51.6706 | 27.1540 | 11.9484
Occupation d'espace disque Reiserfs est le plus économique pour les petits fichiers. En effet il prend *5 fois moins de place* que les autres après la création de 800,000 fichiers *de taille moyenne de 100 octets*. En revanche, pour des fichiers de taille moyenne de 1 Ko, la différence est faible entre les différents systèmes de fichiers avec un avantage d'environ 20% pour reiserfs.
// Ça, c'est connu, mais pouquoi ne pas archiver les 800 000 fichiers en un // seul?
En conclusion, pour Bench mongo, la vie réelle et Bonnie, entre Ext3 et ReiserFS, c'est kif-kif. Pour Bonnie++, PostMark Bench et Postal, Ext3 l'emporte. Pour Dbench, avec un processeur puissant, ReiserFS l'emporte pourvu que tu n'aies rien d'autre qu'une tâche unique à accomplir.
Alors, comme nous le disions, pourquoi tout risquer sur un FS d'une complexité inouïe?
Michel Talon wrote:
Emmanuel Florac <eflorac@imaginet.fr> wrote:
Je doute fort que ReiserFS soit plus rapide. Reiser lui-même l'admettait.
Teste les débits en écriture et en lecture des deux, puis teste avec des
fs presque pleins, puis teste encore avec pleins de petits fichiers.
reiserfs est régulier (il garde sa vitesse même quand les disques sont
très pleins, ou qu'il y a plein de petits fichiers), alors qu'ext3 a des
performances très dégradées quand il y a beaucoup de fichiers et/ou
beaucoup d'espace occupé.
Je ne vois pas pourquoi tu te fatigues à nier la ligne du parti. Ext3
pourrait être 10 fois plus lent qu'on te dirait que c'est le meilleur,
parcequ'il a la bénédiction des cadors de l'entourage de Linus.
http://www.linux-france.org/article/sys/ext3fs/Benchmarks/
Allez, on regarde! Les passages plus pertinents sont en gras.
Bench mongo Pour ce test, une configuration x-up est ajoutée. C'est simplement
x2a avec un noyau mono processeur. Reiserfs est le plus rapide quand il s'agit
de manipuler un grand nombre de fichiers de petite taille (400,000 ou 800,000
fichiers de 100 octets en moyenne en occurrence). Dans des situations plus
ordinaires (moins de 68,000 fichiers de taille moyenne entre 1 et 100 Ko),
ext2 est sans surprise le plus performant. *Ensuite, ext3 et reiserfs se*
*partagent la vedette*, tandis que xfs et jfs sont très légèrement en retrait.
Noter que xfs est connu pour sa lenteur dans l'effacement des fichiers. Bien
que les choses se soient améliorées dans le noyau 2.4.18, le problème n'est
pas encore résolu. Jfs souffre également des mêmes handicapes, mais je ne sais
pas si c'est un problème connu.
Un test de la "vie réelle" qui consiste à copier les sources du noyau 2.4.16
vers la partition de test, compiler le noyau et effacer les sources. Dans ce
test, *ext3 et reiserfs* sont équivalents. Avec un petit avantage pour
reiserfs sur x2a. Voir aussi un autre petit test sur un portable.
Bonnie Le test est effectué sur un fichier de taille 4 fois la Ram. L'écart
entre les systèmes de fichiers n'est pas vraiment significatif à mes yeux.
*Noter cependant la performance d'ext3 en ré-écriture séquentielle*.
// Pour cette réécriture, ext3 est deux fois plus rapide que Ext3, mais on
// n'en parlera pas.
Bonnie++ *Par ordre de performance: ext3*, reiserfs, xfs, jfs.
PostMark Bench simulant un serveur de mail. La différence est très claire
entre les systèmes de fichiers: *par ordre de performance: ext3*, reiserfs,
xfs, jfs.
Postal Un autre bench sur le serveur de mail. Ici la tendance s'inverse ! On
trouve dans l'ordre jfs, xfs, ext3, *et assez loin derrière, reiserfs*. Ce
test donne des résultats très variables (pour un même système de fichiers) sur
home. *Je décide de ne pas les publier*.
// Alors, on oublie.
Dbench Ici, *reiserfs est nettement meilleur. Suivi de xfs, ext3*, et loin
derrière par jfs. À noter un problème d'instabilité (plantage du système) sous
xfs. Curieusement, sur x2a, un noyau mono-processeur est plus rapide en
situation de haute charge pour tous les systèmes de fichiers,
// Encore que ça dépend du processeur et de la RAM:
//
// Ext3-wb/home | 52.5312 | 22.6350 | 8.9243
// ----------------------|-------------|--------------|--------------
// reiserfs/home | 51.6706 | 27.1540 | 11.9484
Occupation d'espace disque Reiserfs est le plus économique pour les petits
fichiers. En effet il prend *5 fois moins de place* que les autres après la
création de 800,000 fichiers *de taille moyenne de 100 octets*. En revanche,
pour des fichiers de taille moyenne de 1 Ko, la différence est faible entre
les différents systèmes de fichiers avec un avantage d'environ 20% pour reiserfs.
// Ça, c'est connu, mais pouquoi ne pas archiver les 800 000 fichiers en un
// seul?
En conclusion, pour Bench mongo, la vie réelle et Bonnie, entre Ext3 et
ReiserFS, c'est kif-kif. Pour Bonnie++, PostMark Bench et Postal, Ext3
l'emporte. Pour Dbench, avec un processeur puissant, ReiserFS l'emporte pourvu
que tu n'aies rien d'autre qu'une tâche unique à accomplir.
Alors, comme nous le disions, pourquoi tout risquer sur un FS d'une complexité
inouïe?
Je doute fort que ReiserFS soit plus rapide. Reiser lui-même l'admettait.
Teste les débits en écriture et en lecture des deux, puis teste avec des fs presque pleins, puis teste encore avec pleins de petits fichiers. reiserfs est régulier (il garde sa vitesse même quand les disques sont très pleins, ou qu'il y a plein de petits fichiers), alors qu'ext3 a des performances très dégradées quand il y a beaucoup de fichiers et/ou beaucoup d'espace occupé.
Je ne vois pas pourquoi tu te fatigues à nier la ligne du parti. Ext3 pourrait être 10 fois plus lent qu'on te dirait que c'est le meilleur, parcequ'il a la bénédiction des cadors de l'entourage de Linus. http://www.linux-france.org/article/sys/ext3fs/Benchmarks/
Allez, on regarde! Les passages plus pertinents sont en gras.
Bench mongo Pour ce test, une configuration x-up est ajoutée. C'est simplement x2a avec un noyau mono processeur. Reiserfs est le plus rapide quand il s'agit de manipuler un grand nombre de fichiers de petite taille (400,000 ou 800,000 fichiers de 100 octets en moyenne en occurrence). Dans des situations plus ordinaires (moins de 68,000 fichiers de taille moyenne entre 1 et 100 Ko), ext2 est sans surprise le plus performant. *Ensuite, ext3 et reiserfs se* *partagent la vedette*, tandis que xfs et jfs sont très légèrement en retrait. Noter que xfs est connu pour sa lenteur dans l'effacement des fichiers. Bien que les choses se soient améliorées dans le noyau 2.4.18, le problème n'est pas encore résolu. Jfs souffre également des mêmes handicapes, mais je ne sais pas si c'est un problème connu.
Un test de la "vie réelle" qui consiste à copier les sources du noyau 2.4.16 vers la partition de test, compiler le noyau et effacer les sources. Dans ce test, *ext3 et reiserfs* sont équivalents. Avec un petit avantage pour reiserfs sur x2a. Voir aussi un autre petit test sur un portable.
Bonnie Le test est effectué sur un fichier de taille 4 fois la Ram. L'écart entre les systèmes de fichiers n'est pas vraiment significatif à mes yeux. *Noter cependant la performance d'ext3 en ré-écriture séquentielle*.
// Pour cette réécriture, ext3 est deux fois plus rapide que Ext3, mais on // n'en parlera pas.
Bonnie++ *Par ordre de performance: ext3*, reiserfs, xfs, jfs.
PostMark Bench simulant un serveur de mail. La différence est très claire entre les systèmes de fichiers: *par ordre de performance: ext3*, reiserfs, xfs, jfs.
Postal Un autre bench sur le serveur de mail. Ici la tendance s'inverse ! On trouve dans l'ordre jfs, xfs, ext3, *et assez loin derrière, reiserfs*. Ce test donne des résultats très variables (pour un même système de fichiers) sur home. *Je décide de ne pas les publier*.
// Alors, on oublie.
Dbench Ici, *reiserfs est nettement meilleur. Suivi de xfs, ext3*, et loin derrière par jfs. À noter un problème d'instabilité (plantage du système) sous xfs. Curieusement, sur x2a, un noyau mono-processeur est plus rapide en situation de haute charge pour tous les systèmes de fichiers,
// Encore que ça dépend du processeur et de la RAM: // // Ext3-wb/home | 52.5312 | 22.6350 | 8.9243 // ----------------------|-------------|--------------|-------------- // reiserfs/home | 51.6706 | 27.1540 | 11.9484
Occupation d'espace disque Reiserfs est le plus économique pour les petits fichiers. En effet il prend *5 fois moins de place* que les autres après la création de 800,000 fichiers *de taille moyenne de 100 octets*. En revanche, pour des fichiers de taille moyenne de 1 Ko, la différence est faible entre les différents systèmes de fichiers avec un avantage d'environ 20% pour reiserfs.
// Ça, c'est connu, mais pouquoi ne pas archiver les 800 000 fichiers en un // seul?
En conclusion, pour Bench mongo, la vie réelle et Bonnie, entre Ext3 et ReiserFS, c'est kif-kif. Pour Bonnie++, PostMark Bench et Postal, Ext3 l'emporte. Pour Dbench, avec un processeur puissant, ReiserFS l'emporte pourvu que tu n'aies rien d'autre qu'une tâche unique à accomplir.
Alors, comme nous le disions, pourquoi tout risquer sur un FS d'une complexité inouïe?
Yugo
Emmanuel Florac wrote:
Seigneur, Google et Giganews vont faire faillite! C'est incroyable le nombre de sysadmins qui gardent 100 000 groupes archivés pendant deux ans!
Tu dis vraiment n'importe quoi, t'es un vrai boulet. Tu parles de ce que tu ne connais pas, tu n'as fait aucun test comparatif, et tu la ramènes.
Absolument. Mais regarde plus bas, Michel Talon en propose, des benchmarks.
Pour ma part j'ai testé les différents filesystems sur différents configurations pendant plusieurs semaines d'affilée, parce qu'il se trouve que le stockage, c'est mon boulot.
C'est bien ça! Tu devrais donner le nom de ta boîte pour que vos clients évaluent si ça leur dit de confier leurs données à ReiserFS.
Par ailleurs, Reiser étant pris dans des problèmes familiaux qui risquent de ne pas lui laisser grand répit et les autres développeurs jugeant qu'il ne vaut même pas la peine de poursuivre le développement, bonne chance si ça merdouille! Parce que, comme pour toute solution informatique, aussitôt que tu n'as pas les deux mains dans le cambouis, Seigneur que la brume s'installe vite, qu'il faut du temps pour reformuler les solutions, hier si évidentes.
Je pense toujours que la simplicité est une vertu.
Emmanuel Florac wrote:
Seigneur, Google et Giganews vont faire faillite! C'est incroyable le nombre
de sysadmins qui gardent 100 000 groupes archivés pendant deux ans!
Tu dis vraiment n'importe quoi, t'es un vrai boulet. Tu parles de ce que
tu ne connais pas, tu n'as fait aucun test comparatif, et tu la ramènes.
Absolument. Mais regarde plus bas, Michel Talon en propose, des benchmarks.
Pour ma part j'ai testé les différents filesystems sur différents
configurations pendant plusieurs semaines d'affilée, parce qu'il se
trouve que le stockage, c'est mon boulot.
C'est bien ça! Tu devrais donner le nom de ta boîte pour que vos clients
évaluent si ça leur dit de confier leurs données à ReiserFS.
Par ailleurs, Reiser étant pris dans des problèmes familiaux qui risquent de
ne pas lui laisser grand répit et les autres développeurs jugeant qu'il ne
vaut même pas la peine de poursuivre le développement, bonne chance si ça
merdouille! Parce que, comme pour toute solution informatique, aussitôt que tu
n'as pas les deux mains dans le cambouis, Seigneur que la brume s'installe
vite, qu'il faut du temps pour reformuler les solutions, hier si évidentes.
Je pense toujours que la simplicité est une vertu.
Seigneur, Google et Giganews vont faire faillite! C'est incroyable le nombre de sysadmins qui gardent 100 000 groupes archivés pendant deux ans!
Tu dis vraiment n'importe quoi, t'es un vrai boulet. Tu parles de ce que tu ne connais pas, tu n'as fait aucun test comparatif, et tu la ramènes.
Absolument. Mais regarde plus bas, Michel Talon en propose, des benchmarks.
Pour ma part j'ai testé les différents filesystems sur différents configurations pendant plusieurs semaines d'affilée, parce qu'il se trouve que le stockage, c'est mon boulot.
C'est bien ça! Tu devrais donner le nom de ta boîte pour que vos clients évaluent si ça leur dit de confier leurs données à ReiserFS.
Par ailleurs, Reiser étant pris dans des problèmes familiaux qui risquent de ne pas lui laisser grand répit et les autres développeurs jugeant qu'il ne vaut même pas la peine de poursuivre le développement, bonne chance si ça merdouille! Parce que, comme pour toute solution informatique, aussitôt que tu n'as pas les deux mains dans le cambouis, Seigneur que la brume s'installe vite, qu'il faut du temps pour reformuler les solutions, hier si évidentes.
Je pense toujours que la simplicité est une vertu.
