OVH Cloud OVH Cloud

Performance des type de filesystem

24 réponses
Avatar
Jean
Bonjour,

Une question vielle comme le monde [Linux] : A l'installation de ma
distribution (SuSE) "on" me demande avec quoi (Reiserfs, ext2, ...) formater
ma partition /

J'imagine que le deal se fait entre performance et sécurité ...

Laquelle est la plus rapide ? Laquelle est la plus sécurisante ? Laquelle
serait un meilleurs compromis des 2 aspects ?

Merci, Jean

10 réponses

1 2 3
Avatar
Arnaud Gomes-do-Vale
"J. Mayer" writes:

Ce que tu dis est très étrange, car ext3 se sert de ext2.
Donc, si ext2 est fragile, ext3 l'est fatalement plus
(la fiabilité d'un assemblage est toujours inférieure à celle de
l'élément le plus faible...)


D'ailleurs, c'est bien connu, le journal ne sert qu'à perdre les
données plus facilement. À part ça, depuis que ext3 est réputé fiable
(disons depuis qu'il a été porté sous Linux 2.4), j'ai eu une seule
machine qui ne redémarrait pas toute seule sans rien demander en cas
de problème, et c'était parce que ses disques étaient en train de
mourir. Par contre, si ext2 est effectivement plutôt robuste (peu de
pertes de données), il a bien souvent du mal à remonter sans un bon
coup de pied bien placé.

De toute façon, journal ou pas, rien ne remplace des bonnes
sauvegardes. :-)

--
Arnaud Gomes-do-Vale -*-*-*-
http://www.glou.org/~arnaud/
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
En savoir plus sur GNU/Linux : http://www.linux-france.org/

Avatar
Zouplaz
J. Mayer - :

On Thu, 14 Aug 2003 17:29:34 +0000, Zouplaz wrote:

J. Mayer - :

Oui, mais comment expliquer cette résistance aux crashes (au moins
une bonne cinquantaine de reset ces derniers moirs) alors qu'avant en
ext2 j'ai vraiment eu des problèmes infects, qui ont parfois résulté
dans des systèmes hors d'état de booter (et toujours après un crash
sévère ou un gel) ?


Jamais vu. Tu dois avoir un pb hard...
ext2 est _de loin_ le file-system qui est le plus dur à corrompre
gravement. D'après mon expérience, même en cas de problème hard,
(crash de disque, controleur IDE qui grille...)
il est difficile d'arriver à une situation ou on ne peux pas
récupérer les données. C'est le système de référence,
et ce n'est pas un hasard...


Non, c'était pas du au matériel puisque c'est sur la même machine que
tourne ma RH7.3 en ext3 depuis 1 an...

ext3 est encore _très_ fragile...
Ce que tu dis est très étrange, car ext3 se sert de ext2.
Donc, si ext2 est fragile, ext3 l'est fatalement plus
(la fiabilité d'un assemblage est toujours inférieure à celle de
l'élément le plus faible...)

De toute façon, même après un crash ou un freeze, tu peux
rebooter proprement:
il faut se servir des Magic-Sys-Rq:
Alt-Sys-Une autre touche.
La séquence magique pour rebooter:
Alt-Sys-s
Alt-Sys-u
Alt-Sys-b

A noter dans un coin, au cas ou...

Vérifie que ton kernel les supporte:
cat /proc/sys/kernel/sysrq
Si ça te sort 0, change de kernel...



J'ignorais cette possibilité.
Chez moi, un sysrq n'existe pas dans /proc/sys/kernel
C'est supporté par le kernel 2.4.20 ? Parce que si oui je peux le
recompiler...


Avatar
Zouplaz
Zouplaz - :

J'ignorais cette possibilit‚.
Chez moi, un sysrq n'existe pas dans /proc/sys/kernel
C'est support‚ par le kernel 2.4.20 ? Parce que si oui je peux le
recompiler...


Je me reponds tout seul : oui ça existe ! Je vais donc m'en recompiler un
tout neuf !

Avatar
J. Mayer
On Sat, 16 Aug 2003 12:06:52 +0200, Arnaud Gomes-do-Vale wrote:

"J. Mayer" writes:

Ce que tu dis est très étrange, car ext3 se sert de ext2.
Donc, si ext2 est fragile, ext3 l'est fatalement plus
(la fiabilité d'un assemblage est toujours inférieure à celle de
l'élément le plus faible...)


D'ailleurs, c'est bien connu, le journal ne sert qu'à perdre les
données plus facilement.
Non, mais tout assemblage est forcément plus fragile que chacun de ces

composants. ext2 étant un des composants de ext3, ce dernier est forcément
plus fragile que ext2. Mais le journal lui offre des possibilté
de reprise que ext2 n'a pas et lui permet de ne pas checker tout
le file-system (ce qui est surtout l'effet recherché, vu la taille
des disques actuels).

Par contre, si ext2 est effectivement plutôt robuste (peu de
pertes de données), il a bien souvent du mal à remonter sans un bon
coup de pied bien placé.

C'est à dire ?

Je n'ai que très rarement vu un fs ext2 qui ne puisse pas
être remonté, du moins sur un disque sain ?
Le seul cas que j'ai rencontré, c'est un superbloc corrompu
(ce qui montre que le disque ne doit pas être très bien dans sa
peau puisque le superbloc est sensé rester le même...),
qui nécessite un fsck manuel. Je n'ai jamais rien recontré
de plus grave, même sur un noyau expérimental..

De toute façon, journal ou pas, rien ne remplace des bonnes
sauvegardes. :-)


Enfin une parole sage :=)


Avatar
Arnaud Gomes-do-Vale
"J. Mayer" writes:

Par contre, si ext2 est effectivement plutôt robuste (peu de
pertes de données), il a bien souvent du mal à remonter sans un bon
coup de pied bien placé.

C'est à dire ?

Je n'ai que très rarement vu un fs ext2 qui ne puisse pas
être remonté, du moins sur un disque sain ?


C'est vrai, mais ça nécessite souvent une intervention humaine alors
que ext3 par exemple revient généralement en ligne tout seul sans que
l'administrateur ait à y toucher. Quand la salle machine est à 15°C,
c'est important. :-)

--
Arnaud Gomes-do-Vale -*-*-*-
http://www.glou.org/~arnaud/
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
En savoir plus sur GNU/Linux : http://www.linux-france.org/


Avatar
J. Mayer
On Sun, 17 Aug 2003 19:11:37 +0200, Arnaud Gomes-do-Vale wrote:

"J. Mayer" writes:

Par contre, si ext2 est effectivement plutôt robuste (peu de
pertes de données), il a bien souvent du mal à remonter sans un bon
coup de pied bien placé.

C'est à dire ?

Je n'ai que très rarement vu un fs ext2 qui ne puisse pas
être remonté, du moins sur un disque sain ?


C'est vrai, mais ça nécessite souvent une intervention humaine alors
que ext3 par exemple revient généralement en ligne tout seul sans que
l'administrateur ait à y toucher. Quand la salle machine est à 15°C,
c'est important. :-)


Je touche du bois, je n'ai eu besoin d'intervenir que quand les
disques se sentaient mal ou avec des noyaux expérimentaux
(les 2.4...-test et le 2.6 m'a fait le coup après une coupure
de courant la semaine dernière...).

L'important, c'est que chacun soit content du fs qu'il utilise :=)
... et qu'il retrouve ses données...



Avatar
Qing Liu
"J. Mayer" writes:

Je n'utilise pas ext3, car il est trop lent et le concept
ne me parait pas bon.
Je me base sur les nombreux rapports de bugs qui arrivent sur
la mailing list du kernel pour affirmer qu'il manque de maturité.
C'est le file-systems de tous les ennuis, si on regarde ce critère.
Les développeurs kernel le considèrent d'ailleurs comme expérimental.


Bonjour,

Si on voit beaucoup de rapports de bugs sur ext3, c'est sans parce
que c'est le FS le plus utilisé en ce moment. Il ne faut pas trop
s'en faire. Je pense que les bugs les plus embêtants sont liés à
quota et aux disques en raid. Note que même ext2 a eu de sérieux
bugs (corruption de données) sur toute une série de noyaux 2.2.x
sans qu'on le dise expérimental :). La stabilité est une notion
très subjective. A mon sens, ext3 est tout à fait stable.

Mais, je ne doutes pas qu'il atteindra un jour un niveau de stabilité
correct. Je pense que ce sera le file-system journalisé par défaut
des distribs, car il est compatible ext2.


C'est déjà fait par RedHat depuis deux ans au détriment d'ext2.

Par contre, sa conception
(due à cette comptabilité voulue) fait qu'il ne sera jamais très
performant et que, pour la même raison, sa sécurité ne sera jamais
optimale:
le journal est contenu dans un fichier, ce qui localise toute
l'information la plus importante. Sur JFS (et je pense reiser et
XFS), la journalisation est dispersée sur le disque, ce qui accélère
le file-system (moins de seek pour accéder au journal) et le fiabilise
(un bout de disque corrompu, quel qu'il soit, ne peux pas corrompre
la partition entière...).


Ça se discute. Le design d'ext3 est peut-être vieillot, mais tout
comme le noyau Linux lui-même, c'est l'efficacité qui prime.
Pour la sécurité des données, ext3 offre deux modes de journalisation
(data=ordered et data=journal) que les autres n'ont pas. Ils
ne journalisent que les métadonnées.

Pour la rapidité, j'ai fait moi-même quelques petits tests (assez
complets amha) du temps du noyau 2.4.16
http://www.linux-france.org/article/sys/ext3fs/Benchmarks/
Globalement, ext3 et reiserfs sont les meilleurs (en mettant
ext2 de côté), tandis que jfs traîne en général derrière.
Les benchs valent ce qu'ils valent, mais quand jfs jusqu'à
six fois plus de temps à copier et effacer un arbre /usr/src/linux,
ça doit se ressentir parfois dans la vie de tous les jours.
Ces tests datent d'y a un an et demi, il est possible que
les choses aient beaucoup changé. As-tu des liens récents ?

Sur le plan théorique, le journal d'ext3 est dans une suite
de blocks contiguës (s'il est crée avec la partition). Comme
l'écriture du journal comme des données est en général
"cachée" (cached), l'écriture est regroupée et séquentielle
dans le journal. On peut donc penser que c'est plus performant
qu'un journal dispersé sur le disque. Enfin, il ne faut pas
se fier toujours à la supériorité du design (cf Hurd :)).

Les FS c'est comme les distributions Linux, quand il y en
a beaucoup, ça donne toujours de longs débats. L'avantage
pour les FS c'est que c'est moins politique, donc on trolle
moins. On n'est pas obligé d'aller dans fcol.debats.

--
Liu

Avatar
Emmanuel Florac
Dans article ,
disait...
Globalement, ext3 et reiserfs sont les meilleurs (en mettant
ext2 de côté), tandis que jfs traîne en général derrière.



Je pense qu'il faudrait reprendre ces tests avec du bon matos (des
disques ultra-rapides FC, par exemple), pour bien distinguer la part du
FS là-dedans... En effet avec une SGI à 200 Mhz, je faisais du 100Mo/s en
écriture sur une baie FC en XFS comme un rien, il y a déjà 5 ans.

--
Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?

Avatar
J. Mayer
On Wed, 20 Aug 2003 11:22:54 +0200, Qing Liu wrote:

Pour la rapidité, j'ai fait moi-même quelques petits tests (assez
complets amha) du temps du noyau 2.4.16
http://www.linux-france.org/article/sys/ext3fs/Benchmarks/
Globalement, ext3 et reiserfs sont les meilleurs (en mettant
ext2 de côté), tandis que jfs traîne en général derrière.
Les benchs valent ce qu'ils valent, mais quand jfs jusqu'à
six fois plus de temps à copier et effacer un arbre /usr/src/linux,
ça doit se ressentir parfois dans la vie de tous les jours.
Ces tests datent d'y a un an et demi, il est possible que
les choses aient beaucoup changé. As-tu des liens récents ?


Je n'ai pas de benchs précis, mais je suis étonné par les performances
de JFS: je l'utilise en permanence, et je ne constate pas de différence
sensible de vitesse entre ext2 et JFS (copie récursive, compils
de plusieurs Go...). Il n'est peut-être pas aussi rapide que IBM
le prétend, mais à l'utilisation, je suis très loin d'un facteur
6 en performances... Et même les versions anciennes, avec pas
mal de code de débug, ne m'ont jamais paru aussi lentes...
Il faudrait que je fasse des benchs sérieux, sans doute...


Enfin, il ne faut pas
se fier toujours à la supériorité du design (cf Hurd :)).

Ca, c'est mequin :-)


Les FS c'est comme les distributions Linux, quand il y en
a beaucoup, ça donne toujours de longs débats. L'avantage
pour les FS c'est que c'est moins politique, donc on trolle
moins. On n'est pas obligé d'aller dans fcol.debats.


Au moins, il y a l'avantage qu'il y en ai beaucoup, et que chacun
en trouve un qui lui convient...


Je viens de faire un bench simple, pour voir.
Je n'ai que des partitions en ext2 et JFS...
JFS à l'air ~ 2 fois moins rapide que ext2 (pas 6, ouf !).
Donc, c'est moins rapide que je ne le pensais, mais pas aussi
catastrophique que ce que tu as vu... A noter
que j'ai obtenu de grandes différences entre les essais suivant
le fs d'origine des fichiers et l'état du cache. J'ai donc décidé
de partir de la RAM pour avoir un résultat reproductible.
Mon test consiste à recopier les sources du 2.6.0-test3 (219 Mo),
à faire un grep dedans puis à les effacer:

time cp -a --no-dereference /dev/shm/linux-2.6.0-test3bis /tmp ; time sync
JFS:
real 0m19.328s
user 0m0.265s
sys 0m4.625s
sync 0m8.657s

ext2:
real 0m8.358s
user 0m0.222s
sys 0m3.447s
sync 0m6.046s

time rm -rf linux-2.6.0-test3bis/ ; time sync
JFS:
real 0m6.827s
user 0m0.059s
sys 0m0.833s
sync 0m0.010s

ext2:
real 0m4.043s
user 0m0.050s
sys 0m0.375s
sync 0m0.165s

time sh -c "grep -r whatszis linux-2.6.0-test3bis/ >/dev/null 2>&1"
JFS:
real 0m17.501s
user 0m0.332s
sys 0m1.284s

ext2:
real 0m9.605s
user 0m0.348s
sys 0m1.411s

Avatar
Qing Liu
"J. Mayer" writes:

Je n'ai pas de benchs précis, mais je suis étonné par les performances
de JFS: je l'utilise en permanence, et je ne constate pas de différence
sensible de vitesse entre ext2 et JFS (copie récursive, compils
de plusieurs Go...). Il n'est peut-être pas aussi rapide que IBM
le prétend, mais à l'utilisation, je suis très loin d'un facteur
6 en performances... Et même les versions anciennes, avec pas
mal de code de débug, ne m'ont jamais paru aussi lentes...
Il faudrait que je fasse des benchs sérieux, sans doute...


Le facteur de 1/6 c'est sur un disque SCSI/bi-pro. Sur
du IDE/mono-proc, c'est de l'ordre de 1/2 (ext2/jfs).
C'est en gros ce que donne tes tests. Dans mes tests
(cp, rm) ext2 et ext3 sont à peu près comparables.

Enfin, il ne faut pas
se fier toujours à la supériorité du design (cf Hurd :)).

Ca, c'est mequin :-)



Mince c'est s'est vu :)

--
Liu


1 2 3