raid0 vs lvm --stripes 2

Julien Demange

20/07/2010 à 12:10

Bonjour,

Le 20/07/2010 07:54, Daniel Caillibaud a écrit :

Je vois pas mal de tutos sur le net qui mettent du LVM sur un raid0 et je me demande quel est l'intérêt par rapport à du LVM
seul (sur deux disques avec --stripes 2). Ça ajoute un peu de complexité (même si mdadm n'est pas sorcier, ça fait toujours ça
en plus) pour pas vraiment de perfs supplémentaires.

perso, autant, je recommande vivement LVM quand on utilise mdadm (sauf
cas un spé particulier). Auant je ne recommande pas mdadm quand on ne
fait pas de RAID (et le raid0, c'est pas vraiment du RAID).

De mon point de vue, le raid0 avec mdadm peut êtres pratique quand on a
deux disques, plusieurs partitions et que l'on veut que deux de ces
partitions (chacune sur un disque) soit en strpping. Eventuellement deux
autres partitions en raid1. Dans ce genre de cas particulier LVM ajoute
une surcouche peu utile et en plus on a éventuellement déjà mdadm, donc
ça simplifie la gestion.

Mais sinon, qui plus est quand on souhaite utiliser LVM, je ne vois pas
l'intérêt de mettre mdadm alors qu'il n'y a pas de RAID (je ne considère
pas le raid0 comme du RAID).

En plus de la surcouche, ça diminue l'intérêt de LVM. Car sur ton VG,
rien ne t'oblige à tout mettre en strippng. Par exemple, la swap, le
noyau est réputé êtres capable de bien gérer la répartition entre les
swap. Tu peux éventuellement avoir des LV qui ne serait pas en striping.
Alors qu'avec mdadm, tu va tout avoir en raid0 (c'est très cohérent en
raid1/5, mais pas forcément en raid0).

Mais aussi, mdadm, je ne crois pas qu'il permette facilement de
déplacer, à chaud, tes donnés d'un disque à un autre. Cas ou SMART te
rapporterait qu'un disque est en train de mourir. Là, où avec LVM, tu
peux aisément , après avoir ajouté un autre disque, déplacer, en
fonctionnement, les LV d'un PV, vers un autre.

J'ai raté un truc ?

C'est dans l'idée unix "faire un seul truc correctement",

pas sur que ça soit forcément cohérent.

où on considère que le raid soft sait mieux gérer le stripping et lvm
"l'abstraction logique" des volumes, et qu'il vaut mieux séparer ces tâches ?

Aucune idée. Je ne sais pas du tout pour les pref !

[...]

Par ailleurs, si vous avez des conseils, sur le chunksize à choisir par ex, les disques sont des X25-M, c'est pour une
utilisation de serveur web assez classique (apache/php/mysql), pas vraiment de gros fichiers à manipuler...

Je ne sais pas. Je ne suis pas un spécialiste des disques.
Mais ça l'intéresse aussi ;

--
a+,
Julien

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/

Bonjour,

Le 20/07/2010 07:54, Daniel Caillibaud a écrit :

Je vois pas mal de tutos sur le net qui mettent du LVM sur un raid0 et je me demande quel est l'intérêt par rapport à du LVM
seul (sur deux disques avec --stripes 2). Ça ajoute un peu de complexité (même si mdadm n'est pas sorcier, ça fait toujours ça
en plus) pour pas vraiment de perfs supplémentaires.

perso, autant, je recommande vivement LVM quand on utilise mdadm (sauf
cas un spé particulier). Auant je ne recommande pas mdadm quand on ne
fait pas de RAID (et le raid0, c'est pas vraiment du RAID).

De mon point de vue, le raid0 avec mdadm peut êtres pratique quand on a
deux disques, plusieurs partitions et que l'on veut que deux de ces
partitions (chacune sur un disque) soit en strpping. Eventuellement deux
autres partitions en raid1. Dans ce genre de cas particulier LVM ajoute
une surcouche peu utile et en plus on a éventuellement déjà mdadm, donc
ça simplifie la gestion.

Mais sinon, qui plus est quand on souhaite utiliser LVM, je ne vois pas
l'intérêt de mettre mdadm alors qu'il n'y a pas de RAID (je ne considère
pas le raid0 comme du RAID).

En plus de la surcouche, ça diminue l'intérêt de LVM. Car sur ton VG,
rien ne t'oblige à tout mettre en strippng. Par exemple, la swap, le
noyau est réputé êtres capable de bien gérer la répartition entre les
swap. Tu peux éventuellement avoir des LV qui ne serait pas en striping.
Alors qu'avec mdadm, tu va tout avoir en raid0 (c'est très cohérent en
raid1/5, mais pas forcément en raid0).

Mais aussi, mdadm, je ne crois pas qu'il permette facilement de
déplacer, à chaud, tes donnés d'un disque à un autre. Cas ou SMART te
rapporterait qu'un disque est en train de mourir. Là, où avec LVM, tu
peux aisément , après avoir ajouté un autre disque, déplacer, en
fonctionnement, les LV d'un PV, vers un autre.

J'ai raté un truc ?

C'est dans l'idée unix "faire un seul truc correctement",

pas sur que ça soit forcément cohérent.

où on considère que le raid soft sait mieux gérer le stripping et lvm
"l'abstraction logique" des volumes, et qu'il vaut mieux séparer ces tâches ?

Aucune idée. Je ne sais pas du tout pour les pref !

[...]

Par ailleurs, si vous avez des conseils, sur le chunksize à choisir par ex, les disques sont des X25-M, c'est pour une
utilisation de serveur web assez classique (apache/php/mysql), pas vraiment de gros fichiers à manipuler...

Je ne sais pas. Je ne suis pas un spécialiste des disques.
Mais ça l'intéresse aussi ;

--
a+,
Julien

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/4C4573D3.4050806@remiremont.fr

Vous avez filtré cet utilisateur ! Consultez son message

Bonjour,

Le 20/07/2010 07:54, Daniel Caillibaud a écrit :

Je vois pas mal de tutos sur le net qui mettent du LVM sur un raid0 et je me demande quel est l'intérêt par rapport à du LVM
seul (sur deux disques avec --stripes 2). Ça ajoute un peu de complexité (même si mdadm n'est pas sorcier, ça fait toujours ça
en plus) pour pas vraiment de perfs supplémentaires.

perso, autant, je recommande vivement LVM quand on utilise mdadm (sauf
cas un spé particulier). Auant je ne recommande pas mdadm quand on ne
fait pas de RAID (et le raid0, c'est pas vraiment du RAID).

De mon point de vue, le raid0 avec mdadm peut êtres pratique quand on a
deux disques, plusieurs partitions et que l'on veut que deux de ces
partitions (chacune sur un disque) soit en strpping. Eventuellement deux
autres partitions en raid1. Dans ce genre de cas particulier LVM ajoute
une surcouche peu utile et en plus on a éventuellement déjà mdadm, donc
ça simplifie la gestion.

Mais sinon, qui plus est quand on souhaite utiliser LVM, je ne vois pas
l'intérêt de mettre mdadm alors qu'il n'y a pas de RAID (je ne considère
pas le raid0 comme du RAID).

En plus de la surcouche, ça diminue l'intérêt de LVM. Car sur ton VG,
rien ne t'oblige à tout mettre en strippng. Par exemple, la swap, le
noyau est réputé êtres capable de bien gérer la répartition entre les
swap. Tu peux éventuellement avoir des LV qui ne serait pas en striping.
Alors qu'avec mdadm, tu va tout avoir en raid0 (c'est très cohérent en
raid1/5, mais pas forcément en raid0).

Mais aussi, mdadm, je ne crois pas qu'il permette facilement de
déplacer, à chaud, tes donnés d'un disque à un autre. Cas ou SMART te
rapporterait qu'un disque est en train de mourir. Là, où avec LVM, tu
peux aisément , après avoir ajouté un autre disque, déplacer, en
fonctionnement, les LV d'un PV, vers un autre.

J'ai raté un truc ?

C'est dans l'idée unix "faire un seul truc correctement",

pas sur que ça soit forcément cohérent.

où on considère que le raid soft sait mieux gérer le stripping et lvm
"l'abstraction logique" des volumes, et qu'il vaut mieux séparer ces tâches ?

Aucune idée. Je ne sais pas du tout pour les pref !

[...]

Par ailleurs, si vous avez des conseils, sur le chunksize à choisir par ex, les disques sont des X25-M, c'est pour une
utilisation de serveur web assez classique (apache/php/mysql), pas vraiment de gros fichiers à manipuler...

Je ne sais pas. Je ne suis pas un spécialiste des disques.
Mais ça l'intéresse aussi ;

--
a+,
Julien

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/

Jean-Yves F. Barbier

20/07/2010 à 12:20

Le 20/07/2010 07:54, Daniel Caillibaud a écrit :

Je vois pas mal de tutos sur le net qui mettent du LVM sur un raid0 et je me demande quel est l'intérêt par rapport à du LVM
seul (sur deux disques avec --stripes 2). Ça ajoute un peu de complexité (même si mdadm n'est pas sorcier, ça fait toujours ça
en plus) pour pas vraiment de perfs supplémentaires.

J'ai raté un truc ?

Le fait que lorsque tu planteras un RAID-0 ou un LVM les données seront irrécupérables
(avec de *très* rares exceptions pour LVM.)

C'est dans l'idée unix "faire un seul truc correctement", où on considère que le raid soft sait mieux gérer le stripping et lvm
"l'abstraction logique" des volumes, et qu'il vaut mieux séparer ces tâches ?

"séparer les couches" ne sert qu'à rajouter de la latence.

J'ai fait des tests avec 2 ssd (partition de 2,5Go au début de chaque disque), raid soft ou lvm sans raid (mais sur

^^^^^^^^^^^^^^^^^^^^^^
Mouarf: le truc du début de HD, c'est pour... les HDz, pas pour les SSD
qui sont par essence statiques (le temps de latence reste le même qq soit
l'emplacement sur le "disque" puisqu'on parle d'adressage mémoire et pas
de déplacements de têtes.)

les 2 pv avec --stripes 2), en lenny

hdparm -t (3 mesures, toujours dans +/- 5% donc j'ai pris l'intermédiaire) :
raid1 64k 202.68 MB/sec
raid1 128k 196.22 MB/sec
raid0 64k 398.62 MB/sec
raid0 128k 428.77 MB/sec

Là je ne comprends plus, tu mélanges du RAID-0 et du RAID-1 dans ton
test alors que les finalités sont totalement opposées.

lvm 2/64 398.36 MB/sec (--stripes 2 --stripesize 64)
lvm 2/128 425.87 MB/sec
lvm 2/256 454.28 MB/sec
lvm 2/512 454.98 MB/sec

J'ai aussi fait des tests en écriture ("for i in $(seq -w 1 99); do cp -a /sbin /mnt/test/sbin$i; done;",
mesures plus sujettes à caution car nettement plus variables, il aurait fallu faire 10 ou 20 mesures, et faire ensuite la
moyenne en virant les extrêmes mais c'était long, je voulais juste avoir une idée, et puis il aurait fallu tester avec petits
et gros fichiers, bref...)
raid1 64k 0m28.615s
raid1 128k 0m25.864s
raid0 64k 0m13.032s
raid0 128k 0m11.372s
lvm 2/64 0m12.806s
lvm 2/128 0m13.678s
lvm 2/256 0m13.990s
lvm 2/512 0m13.162s

Il faudrait aussi tester lvm au dessus d'un raid0 128k, mais si j'ai besoin de perfs je cherche pas trop à gratter qq % de
plus, la fiabilité/stabilité/simplicité de maintenance étant plus importante pour moi.

Par ailleurs, si vous avez des conseils, sur le chunksize à choisir par ex, les disques sont des X25-M, c'est pour une

Comme le dit la doc, seule l'expérimentation peut indiquer les résultats
escomptés en fonction de l'utilisation de chacun.

utilisation de serveur web assez classique (apache/php/mysql), pas vraiment de gros fichiers à manipuler...

Dans cette configuration, les goulets d'étranglement seraient plutôt apache et php
que mysql (et d'ailleurs, que font-ils tous sur le même HD?)
Si la vitesse et le temps de réponse sont primordiaux, considère plutôt des
serveurs HTTP performants comme nginx ou yaws.

--
<Overfiend> penis jokes are okay in mixed company. VMS is NOT!!!

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/

Le 20/07/2010 07:54, Daniel Caillibaud a écrit :

Je vois pas mal de tutos sur le net qui mettent du LVM sur un raid0 et je me demande quel est l'intérêt par rapport à du LVM
seul (sur deux disques avec --stripes 2). Ça ajoute un peu de complexité (même si mdadm n'est pas sorcier, ça fait toujours ça
en plus) pour pas vraiment de perfs supplémentaires.

J'ai raté un truc ?

Le fait que lorsque tu planteras un RAID-0 ou un LVM les données seront irrécupérables
(avec de *très* rares exceptions pour LVM.)

C'est dans l'idée unix "faire un seul truc correctement", où on considère que le raid soft sait mieux gérer le stripping et lvm
"l'abstraction logique" des volumes, et qu'il vaut mieux séparer ces tâches ?

"séparer les couches" ne sert qu'à rajouter de la latence.

J'ai fait des tests avec 2 ssd (partition de 2,5Go au début de chaque disque), raid soft ou lvm sans raid (mais sur

^^^^^^^^^^^^^^^^^^^^^^
Mouarf: le truc du début de HD, c'est pour... les HDz, pas pour les SSD
qui sont par essence statiques (le temps de latence reste le même qq soit
l'emplacement sur le "disque" puisqu'on parle d'adressage mémoire et pas
de déplacements de têtes.)

les 2 pv avec --stripes 2), en lenny

hdparm -t (3 mesures, toujours dans +/- 5% donc j'ai pris l'intermédiaire) :
raid1 64k 202.68 MB/sec
raid1 128k 196.22 MB/sec
raid0 64k 398.62 MB/sec
raid0 128k 428.77 MB/sec

Là je ne comprends plus, tu mélanges du RAID-0 et du RAID-1 dans ton
test alors que les finalités sont totalement opposées.

lvm 2/64 398.36 MB/sec (--stripes 2 --stripesize 64)
lvm 2/128 425.87 MB/sec
lvm 2/256 454.28 MB/sec
lvm 2/512 454.98 MB/sec

J'ai aussi fait des tests en écriture ("for i in $(seq -w 1 99); do cp -a /sbin /mnt/test/sbin$i; done;",
mesures plus sujettes à caution car nettement plus variables, il aurait fallu faire 10 ou 20 mesures, et faire ensuite la
moyenne en virant les extrêmes mais c'était long, je voulais juste avoir une idée, et puis il aurait fallu tester avec petits
et gros fichiers, bref...)
raid1 64k 0m28.615s
raid1 128k 0m25.864s
raid0 64k 0m13.032s
raid0 128k 0m11.372s
lvm 2/64 0m12.806s
lvm 2/128 0m13.678s
lvm 2/256 0m13.990s
lvm 2/512 0m13.162s

Il faudrait aussi tester lvm au dessus d'un raid0 128k, mais si j'ai besoin de perfs je cherche pas trop à gratter qq % de
plus, la fiabilité/stabilité/simplicité de maintenance étant plus importante pour moi.

Par ailleurs, si vous avez des conseils, sur le chunksize à choisir par ex, les disques sont des X25-M, c'est pour une

Comme le dit la doc, seule l'expérimentation peut indiquer les résultats
escomptés en fonction de l'utilisation de chacun.

utilisation de serveur web assez classique (apache/php/mysql), pas vraiment de gros fichiers à manipuler...

Dans cette configuration, les goulets d'étranglement seraient plutôt apache et php
que mysql (et d'ailleurs, que font-ils tous sur le même HD?)
Si la vitesse et le temps de réponse sont primordiaux, considère plutôt des
serveurs HTTP performants comme nginx ou yaws.

--
<Overfiend> penis jokes are okay in mixed company. VMS is NOT!!!

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/4C4575F9.2040902@gmail.com

Vous avez filtré cet utilisateur ! Consultez son message

Le 20/07/2010 07:54, Daniel Caillibaud a écrit :

Je vois pas mal de tutos sur le net qui mettent du LVM sur un raid0 et je me demande quel est l'intérêt par rapport à du LVM
seul (sur deux disques avec --stripes 2). Ça ajoute un peu de complexité (même si mdadm n'est pas sorcier, ça fait toujours ça
en plus) pour pas vraiment de perfs supplémentaires.

J'ai raté un truc ?

Le fait que lorsque tu planteras un RAID-0 ou un LVM les données seront irrécupérables
(avec de *très* rares exceptions pour LVM.)

C'est dans l'idée unix "faire un seul truc correctement", où on considère que le raid soft sait mieux gérer le stripping et lvm
"l'abstraction logique" des volumes, et qu'il vaut mieux séparer ces tâches ?

"séparer les couches" ne sert qu'à rajouter de la latence.

J'ai fait des tests avec 2 ssd (partition de 2,5Go au début de chaque disque), raid soft ou lvm sans raid (mais sur

^^^^^^^^^^^^^^^^^^^^^^
Mouarf: le truc du début de HD, c'est pour... les HDz, pas pour les SSD
qui sont par essence statiques (le temps de latence reste le même qq soit
l'emplacement sur le "disque" puisqu'on parle d'adressage mémoire et pas
de déplacements de têtes.)

les 2 pv avec --stripes 2), en lenny

hdparm -t (3 mesures, toujours dans +/- 5% donc j'ai pris l'intermédiaire) :
raid1 64k 202.68 MB/sec
raid1 128k 196.22 MB/sec
raid0 64k 398.62 MB/sec
raid0 128k 428.77 MB/sec

Là je ne comprends plus, tu mélanges du RAID-0 et du RAID-1 dans ton
test alors que les finalités sont totalement opposées.

lvm 2/64 398.36 MB/sec (--stripes 2 --stripesize 64)
lvm 2/128 425.87 MB/sec
lvm 2/256 454.28 MB/sec
lvm 2/512 454.98 MB/sec

J'ai aussi fait des tests en écriture ("for i in $(seq -w 1 99); do cp -a /sbin /mnt/test/sbin$i; done;",
mesures plus sujettes à caution car nettement plus variables, il aurait fallu faire 10 ou 20 mesures, et faire ensuite la
moyenne en virant les extrêmes mais c'était long, je voulais juste avoir une idée, et puis il aurait fallu tester avec petits
et gros fichiers, bref...)
raid1 64k 0m28.615s
raid1 128k 0m25.864s
raid0 64k 0m13.032s
raid0 128k 0m11.372s
lvm 2/64 0m12.806s
lvm 2/128 0m13.678s
lvm 2/256 0m13.990s
lvm 2/512 0m13.162s

Il faudrait aussi tester lvm au dessus d'un raid0 128k, mais si j'ai besoin de perfs je cherche pas trop à gratter qq % de
plus, la fiabilité/stabilité/simplicité de maintenance étant plus importante pour moi.

Par ailleurs, si vous avez des conseils, sur le chunksize à choisir par ex, les disques sont des X25-M, c'est pour une

Comme le dit la doc, seule l'expérimentation peut indiquer les résultats
escomptés en fonction de l'utilisation de chacun.

utilisation de serveur web assez classique (apache/php/mysql), pas vraiment de gros fichiers à manipuler...

Dans cette configuration, les goulets d'étranglement seraient plutôt apache et php
que mysql (et d'ailleurs, que font-ils tous sur le même HD?)
Si la vitesse et le temps de réponse sont primordiaux, considère plutôt des
serveurs HTTP performants comme nginx ou yaws.

--
<Overfiend> penis jokes are okay in mixed company. VMS is NOT!!!

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/

Daniel Caillibaud

20/07/2010 à 14:00

Le 20/07/10 Ã 12:00, Julien Demange a Ã©crit :
JD> Mais sinon, qui plus est quand on souhaite utiliser LVM, je ne vois pas
JD> l'intÃ©rÃªt de mettre mdadm alors qu'il n'y a pas de RAID (je n e considÃ¨re
JD> pas le raid0 comme du RAID).

OK, j'avais la mÃªme impression.

JD> En plus de la surcouche, Ã§a diminue l'intÃ©rÃªt de LVM. Ca r sur ton VG,
JD> rien ne t'oblige Ã tout mettre en strippng. Par exemple, la swap, le
JD> noyau est rÃ©putÃ© Ãªtres capable de bien gÃ©rer la r Ã©partition entre les
JD> swap.

Donc, la swap dans le vg, il vaudrait mieux avoir deux lv, un sur chaque pv (me suis jamais demandÃ© si c'Ã©tait possible),
plutÃ´t qu'un lv avec 2 stripes ?

JD> Tu peux Ã©ventuellement avoir des LV qui ne serait pas en striping.
JD> Alors qu'avec mdadm, tu va tout avoir en raid0 (c'est trÃ¨s cohÃ ©rent en
JD> raid1/5, mais pas forcÃ©ment en raid0).
JD>
JD> Mais aussi, mdadm, je ne crois pas qu'il permette facilement de
JD> dÃ©placer, Ã chaud, tes donnÃ©s d'un disque Ã un autr e. Cas ou SMART te
JD> rapporterait qu'un disque est en train de mourir. LÃ , oÃ¹ avec LVM, tu
JD> peux aisÃ©ment , aprÃ¨s avoir ajoutÃ© un autre disque, dÃ ©placer, en
JD> fonctionnement, les LV d'un PV, vers un autre.

C'est vrai aussi.
De toute faÃ§on il me faut du lvm (pour les snapshots), donc je vais me passer de mdadm.

JD> > Par ailleurs, si vous avez des conseils, sur le chunksize Ã choi sir par ex, les disques sont des X25-M, c'est pour une
JD> > utilisation de serveur web assez classique (apache/php/mysql), pas vr aiment de gros fichiers Ã manipuler...
JD>
JD> Je ne sais pas. Je ne suis pas un spÃ©cialiste des disques.
JD> Mais Ã§a l'intÃ©resse aussi ;

Entre temps, j'ai testÃ© lvm "standard" au dessus de mdadm en raid0 ave c des chunk de 128k, on perd ~15% sur du hdparm -t (par
rapport Ã du raid0 seul ou du lvm --stripes 2 seul).

--
Daniel

Le philosophe cherche des solutions aux problÃ¨mes et
ne trouve que des problÃ¨mes sans solutions.
Sim

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/

Le 20/07/10 Ã 12:00, Julien Demange <julien.demange@remiremont.fr> a Ã©crit :
JD> Mais sinon, qui plus est quand on souhaite utiliser LVM, je ne vois pas
JD> l'intÃ©rÃªt de mettre mdadm alors qu'il n'y a pas de RAID (je n e considÃ¨re
JD> pas le raid0 comme du RAID).

OK, j'avais la mÃªme impression.

JD> En plus de la surcouche, Ã§a diminue l'intÃ©rÃªt de LVM. Ca r sur ton VG,
JD> rien ne t'oblige Ã tout mettre en strippng. Par exemple, la swap, le
JD> noyau est rÃ©putÃ© Ãªtres capable de bien gÃ©rer la r Ã©partition entre les
JD> swap.

Donc, la swap dans le vg, il vaudrait mieux avoir deux lv, un sur chaque pv (me suis jamais demandÃ© si c'Ã©tait possible),
plutÃ´t qu'un lv avec 2 stripes ?

JD> Tu peux Ã©ventuellement avoir des LV qui ne serait pas en striping.
JD> Alors qu'avec mdadm, tu va tout avoir en raid0 (c'est trÃ¨s cohÃ ©rent en
JD> raid1/5, mais pas forcÃ©ment en raid0).
JD>
JD> Mais aussi, mdadm, je ne crois pas qu'il permette facilement de
JD> dÃ©placer, Ã chaud, tes donnÃ©s d'un disque Ã un autr e. Cas ou SMART te
JD> rapporterait qu'un disque est en train de mourir. LÃ , oÃ¹ avec LVM, tu
JD> peux aisÃ©ment , aprÃ¨s avoir ajoutÃ© un autre disque, dÃ ©placer, en
JD> fonctionnement, les LV d'un PV, vers un autre.

C'est vrai aussi.
De toute faÃ§on il me faut du lvm (pour les snapshots), donc je vais me passer de mdadm.

JD> > Par ailleurs, si vous avez des conseils, sur le chunksize Ã choi sir par ex, les disques sont des X25-M, c'est pour une
JD> > utilisation de serveur web assez classique (apache/php/mysql), pas vr aiment de gros fichiers Ã manipuler...
JD>
JD> Je ne sais pas. Je ne suis pas un spÃ©cialiste des disques.
JD> Mais Ã§a l'intÃ©resse aussi ;

Entre temps, j'ai testÃ© lvm "standard" au dessus de mdadm en raid0 ave c des chunk de 128k, on perd ~15% sur du hdparm -t (par
rapport Ã du raid0 seul ou du lvm --stripes 2 seul).

--
Daniel

Le philosophe cherche des solutions aux problÃ¨mes et
ne trouve que des problÃ¨mes sans solutions.
Sim

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/20100720135620.47a81b2a@h2.lairdutemps.org

Vous avez filtré cet utilisateur ! Consultez son message

Le 20/07/10 Ã 12:00, Julien Demange a Ã©crit :
JD> Mais sinon, qui plus est quand on souhaite utiliser LVM, je ne vois pas
JD> l'intÃ©rÃªt de mettre mdadm alors qu'il n'y a pas de RAID (je n e considÃ¨re
JD> pas le raid0 comme du RAID).

OK, j'avais la mÃªme impression.

JD> En plus de la surcouche, Ã§a diminue l'intÃ©rÃªt de LVM. Ca r sur ton VG,
JD> rien ne t'oblige Ã tout mettre en strippng. Par exemple, la swap, le
JD> noyau est rÃ©putÃ© Ãªtres capable de bien gÃ©rer la r Ã©partition entre les
JD> swap.

Donc, la swap dans le vg, il vaudrait mieux avoir deux lv, un sur chaque pv (me suis jamais demandÃ© si c'Ã©tait possible),
plutÃ´t qu'un lv avec 2 stripes ?

JD> Tu peux Ã©ventuellement avoir des LV qui ne serait pas en striping.
JD> Alors qu'avec mdadm, tu va tout avoir en raid0 (c'est trÃ¨s cohÃ ©rent en
JD> raid1/5, mais pas forcÃ©ment en raid0).
JD>
JD> Mais aussi, mdadm, je ne crois pas qu'il permette facilement de
JD> dÃ©placer, Ã chaud, tes donnÃ©s d'un disque Ã un autr e. Cas ou SMART te
JD> rapporterait qu'un disque est en train de mourir. LÃ , oÃ¹ avec LVM, tu
JD> peux aisÃ©ment , aprÃ¨s avoir ajoutÃ© un autre disque, dÃ ©placer, en
JD> fonctionnement, les LV d'un PV, vers un autre.

C'est vrai aussi.
De toute faÃ§on il me faut du lvm (pour les snapshots), donc je vais me passer de mdadm.

JD> > Par ailleurs, si vous avez des conseils, sur le chunksize Ã choi sir par ex, les disques sont des X25-M, c'est pour une
JD> > utilisation de serveur web assez classique (apache/php/mysql), pas vr aiment de gros fichiers Ã manipuler...
JD>
JD> Je ne sais pas. Je ne suis pas un spÃ©cialiste des disques.
JD> Mais Ã§a l'intÃ©resse aussi ;

Entre temps, j'ai testÃ© lvm "standard" au dessus de mdadm en raid0 ave c des chunk de 128k, on perd ~15% sur du hdparm -t (par
rapport Ã du raid0 seul ou du lvm --stripes 2 seul).

--
Daniel

Le philosophe cherche des solutions aux problÃ¨mes et
ne trouve que des problÃ¨mes sans solutions.
Sim

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/

Daniel Caillibaud

20/07/2010 à 14:00

Le 20/07/10 Ã 12:10, "Jean-Yves F. Barbier" a Ã ©crit :
JYFB> Le 20/07/2010 07:54, Daniel Caillibaud a Ã©crit :
JYFB> > J'ai ratÃ© un truc ?
JYFB>
JYFB> Le fait que lorsque tu planteras un RAID-0 ou un LVM les donnÃ©es seront irrÃ©cupÃ©rables
JYFB> (avec de *trÃ¨s* rares exceptions pour LVM.)

Non, Ã§a je suis au courant, c'est pareil dans les deux cas, mais c'est pas grave, si Ã§a crash y'en a une autre qui prend le
relai.

JYFB> "sÃ©parer les couches" ne sert qu'Ã rajouter de la latence.

C'est ce qu'il me semblait, mais comme plein de gens apparemment calÃ©s ajoutent du lvm au dessus de mdadm, je me posais la
question...

JYFB> Mouarf: le truc du dÃ©but de HD, c'est pour... les HDz, pas pour les SSD

Oui, merci de le rappeler ;-)

JYFB> LÃ je ne comprends plus, tu mÃ©langes du RAID-0 et du RAID-1 dans ton
JYFB> test alors que les finalitÃ©s sont totalement opposÃ©es.

Oui, c'Ã©tait juste pour vÃ©rifier que j'avais bien mon facteur 2 ( et aussi parce que la machine Ã©tait livrÃ©e en raid1, donc
avant de le casser je l'ai testÃ© aussi).

JYFB> > Par ailleurs, si vous avez des conseils, sur le chunksize Ã ch oisir par ex, les disques sont des X25-M, c'est pour une
JYFB>
JYFB> Comme le dit la doc, seule l'expÃ©rimentation peut indiquer les r Ã©sultats
JYFB> escomptÃ©s en fonction de l'utilisation de chacun.

Certes...
Mais si y'a des trucs Ã Ã©viter, autant le savoir (j'ai lu qq part qu'il valait mieux des chunk de 128k sur ces ssd, mais dans
un seul post sur un forum, sans l'avoir lu ailleurs).

JYFB> > utilisation de serveur web assez classique (apache/php/mysql), pas vraiment de gros fichiers Ã manipuler...
JYFB>
JYFB> Dans cette configuration, les goulets d'Ã©tranglement seraient pl utÃ´t apache et php
JYFB> que mysql (et d'ailleurs, que font-ils tous sur le mÃªme HD?)

Ils sont dans des VM diffÃ©rentes.
Si mysql devient trop goinfre il migrera sur un host pour lui seul.

JYFB> Si la vitesse et le temps de rÃ©ponse sont primordiaux, considÃ ¨re plutÃ´t des
JYFB> serveurs HTTP performants comme nginx ou yaws.

Sans vouloir lancer de troll, j'ai pas vu de diffÃ©rence significative (avec php en fastCgi) entre apache2 "minimaliste" (sans
rewrite ni htaccess) et nginx, et comme je connais mieux apache je l'ai gar dÃ©.

Chez moi, la saturation viendrait plutÃ´t du wrapper fastCgi (unique po ur profiter du cache APC), mais il faut que je teste
davantage.

--
Daniel

Si on ne peut plus tricher avec ses amis,
ce n'est plus la peine de jouer aux cartes.
Marcel Pagnol.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/

Le 20/07/10 Ã 12:10, "Jean-Yves F. Barbier" <12ukwn@gmail.com> a Ã ©crit :
JYFB> Le 20/07/2010 07:54, Daniel Caillibaud a Ã©crit :
JYFB> > J'ai ratÃ© un truc ?
JYFB>
JYFB> Le fait que lorsque tu planteras un RAID-0 ou un LVM les donnÃ©es seront irrÃ©cupÃ©rables
JYFB> (avec de *trÃ¨s* rares exceptions pour LVM.)

Non, Ã§a je suis au courant, c'est pareil dans les deux cas, mais c'est pas grave, si Ã§a crash y'en a une autre qui prend le
relai.

JYFB> "sÃ©parer les couches" ne sert qu'Ã rajouter de la latence.

C'est ce qu'il me semblait, mais comme plein de gens apparemment calÃ©s ajoutent du lvm au dessus de mdadm, je me posais la
question...

JYFB> Mouarf: le truc du dÃ©but de HD, c'est pour... les HDz, pas pour les SSD

Oui, merci de le rappeler ;-)

JYFB> LÃ je ne comprends plus, tu mÃ©langes du RAID-0 et du RAID-1 dans ton
JYFB> test alors que les finalitÃ©s sont totalement opposÃ©es.

Oui, c'Ã©tait juste pour vÃ©rifier que j'avais bien mon facteur 2 ( et aussi parce que la machine Ã©tait livrÃ©e en raid1, donc
avant de le casser je l'ai testÃ© aussi).

JYFB> > Par ailleurs, si vous avez des conseils, sur le chunksize Ã ch oisir par ex, les disques sont des X25-M, c'est pour une
JYFB>
JYFB> Comme le dit la doc, seule l'expÃ©rimentation peut indiquer les r Ã©sultats
JYFB> escomptÃ©s en fonction de l'utilisation de chacun.

Certes...
Mais si y'a des trucs Ã Ã©viter, autant le savoir (j'ai lu qq part qu'il valait mieux des chunk de 128k sur ces ssd, mais dans
un seul post sur un forum, sans l'avoir lu ailleurs).

JYFB> > utilisation de serveur web assez classique (apache/php/mysql), pas vraiment de gros fichiers Ã manipuler...
JYFB>
JYFB> Dans cette configuration, les goulets d'Ã©tranglement seraient pl utÃ´t apache et php
JYFB> que mysql (et d'ailleurs, que font-ils tous sur le mÃªme HD?)

Ils sont dans des VM diffÃ©rentes.
Si mysql devient trop goinfre il migrera sur un host pour lui seul.

JYFB> Si la vitesse et le temps de rÃ©ponse sont primordiaux, considÃ ¨re plutÃ´t des
JYFB> serveurs HTTP performants comme nginx ou yaws.

Sans vouloir lancer de troll, j'ai pas vu de diffÃ©rence significative (avec php en fastCgi) entre apache2 "minimaliste" (sans
rewrite ni htaccess) et nginx, et comme je connais mieux apache je l'ai gar dÃ©.

Chez moi, la saturation viendrait plutÃ´t du wrapper fastCgi (unique po ur profiter du cache APC), mais il faut que je teste
davantage.

--
Daniel

Si on ne peut plus tricher avec ses amis,
ce n'est plus la peine de jouer aux cartes.
Marcel Pagnol.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/20100720135813.3c9bb573@h2.lairdutemps.org

Vous avez filtré cet utilisateur ! Consultez son message

Le 20/07/10 Ã 12:10, "Jean-Yves F. Barbier" a Ã ©crit :
JYFB> Le 20/07/2010 07:54, Daniel Caillibaud a Ã©crit :
JYFB> > J'ai ratÃ© un truc ?
JYFB>
JYFB> Le fait que lorsque tu planteras un RAID-0 ou un LVM les donnÃ©es seront irrÃ©cupÃ©rables
JYFB> (avec de *trÃ¨s* rares exceptions pour LVM.)

Non, Ã§a je suis au courant, c'est pareil dans les deux cas, mais c'est pas grave, si Ã§a crash y'en a une autre qui prend le
relai.

JYFB> "sÃ©parer les couches" ne sert qu'Ã rajouter de la latence.

C'est ce qu'il me semblait, mais comme plein de gens apparemment calÃ©s ajoutent du lvm au dessus de mdadm, je me posais la
question...

JYFB> Mouarf: le truc du dÃ©but de HD, c'est pour... les HDz, pas pour les SSD

Oui, merci de le rappeler ;-)

JYFB> LÃ je ne comprends plus, tu mÃ©langes du RAID-0 et du RAID-1 dans ton
JYFB> test alors que les finalitÃ©s sont totalement opposÃ©es.

Oui, c'Ã©tait juste pour vÃ©rifier que j'avais bien mon facteur 2 ( et aussi parce que la machine Ã©tait livrÃ©e en raid1, donc
avant de le casser je l'ai testÃ© aussi).

JYFB> > Par ailleurs, si vous avez des conseils, sur le chunksize Ã ch oisir par ex, les disques sont des X25-M, c'est pour une
JYFB>
JYFB> Comme le dit la doc, seule l'expÃ©rimentation peut indiquer les r Ã©sultats
JYFB> escomptÃ©s en fonction de l'utilisation de chacun.

Certes...
Mais si y'a des trucs Ã Ã©viter, autant le savoir (j'ai lu qq part qu'il valait mieux des chunk de 128k sur ces ssd, mais dans
un seul post sur un forum, sans l'avoir lu ailleurs).

JYFB> > utilisation de serveur web assez classique (apache/php/mysql), pas vraiment de gros fichiers Ã manipuler...
JYFB>
JYFB> Dans cette configuration, les goulets d'Ã©tranglement seraient pl utÃ´t apache et php
JYFB> que mysql (et d'ailleurs, que font-ils tous sur le mÃªme HD?)

Ils sont dans des VM diffÃ©rentes.
Si mysql devient trop goinfre il migrera sur un host pour lui seul.

JYFB> Si la vitesse et le temps de rÃ©ponse sont primordiaux, considÃ ¨re plutÃ´t des
JYFB> serveurs HTTP performants comme nginx ou yaws.

Sans vouloir lancer de troll, j'ai pas vu de diffÃ©rence significative (avec php en fastCgi) entre apache2 "minimaliste" (sans
rewrite ni htaccess) et nginx, et comme je connais mieux apache je l'ai gar dÃ©.

Chez moi, la saturation viendrait plutÃ´t du wrapper fastCgi (unique po ur profiter du cache APC), mais il faut que je teste
davantage.

--
Daniel

Si on ne peut plus tricher avec ses amis,
ce n'est plus la peine de jouer aux cartes.
Marcel Pagnol.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/

Julien Demange

20/07/2010 à 15:30

Le 20/07/2010 13:56, Daniel Caillibaud a écrit :

JD> En plus de la surcouche, ça diminue l'intérêt de LVM. Car sur ton VG,
JD> rien ne t'oblige à tout mettre en strippng. Par exemple, la swap, le
JD> noyau est réputé êtres capable de bien gérer la répartition entre les
JD> swap.

Donc, la swap dans le vg, il vaudrait mieux avoir deux lv, un sur chaque pv (me suis jamais demandé si c'était possible),
plutôt qu'un lv avec 2 stripes ?

ben, je ne garanti pas que c'est plus performant, mais ça enlève une
couche. J'ai lu plusieurs fois que c'est mieux. Je n'ai jamais fait de
test de perf.
Et donc oui, c'est possible, faut bien spécifier au noyau que chaque
swap doit être utliser en même temp, i.e avec la même priorité. Ceci
avec l'option "pri=X" dans le "fstab" ou "-p X" dans les paramètres de
"swapon".

--
Julien

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/

Vincent Danjean

21/07/2010 à 13:00

On 20/07/2010 13:58, Daniel Caillibaud wrote:

JYFB> > Par ailleurs, si vous avez des conseils, sur le chunksize à choisir par ex, les disques sont des X25-M, c'est pour une
JYFB>
JYFB> Comme le dit la doc, seule l'expérimentation peut indiquer les résultats
JYFB> escomptés en fonction de l'utilisation de chacun.

Certes...
Mais si y'a des trucs à éviter, autant le savoir (j'ai lu qq part qu'il valait mieux des chunk de 128k sur ces ssd, mais dans
un seul post sur un forum, sans l'avoir lu ailleurs).

Il faut aussi aligner les partitions correctement (gpt fait ça mieux que
msdos : l'outil parted permet de manipuler tout ça) sinon ça ne sert à rien
d'aligner les chunk.
Je viens de faire ces manip pour deux DD avec des secteurs physiques
de 4ko (mais un firmware qui persiste à les déclarer en 512o :-( )

Un bon point d'entrée pour la doc :
http://thunk.org/tytso/blog/2009/02/20/aligning-filesystems-to-an-ssds-erase-block-size/

A+
Vincent

--
Vincent Danjean GPG key ID 0x9D025E87
GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87
Unofficial packages: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo: deb http://perso.debian.org/~vdanjean/debian unstable main

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/

raid0 vs lvm --stripes 2

6 réponses

Veuillez sélectionner un problème