Je vois pas mal de tutos sur le net qui mettent du LVM sur un raid0 et je m=
e demande quel est l'int=C3=A9r=C3=AAt par rapport =C3=A0 du LVM
seul (sur deux disques avec --stripes 2). =C3=87a ajoute un peu de complexi=
t=C3=A9 (m=C3=AAme si mdadm n'est pas sorcier, =C3=A7a fait toujours =C3=A7a
en plus) pour pas vraiment de perfs suppl=C3=A9mentaires.
J'ai rat=C3=A9 un truc ?
C'est dans l'id=C3=A9e unix "faire un seul truc correctement", o=C3=B9 on c=
onsid=C3=A8re que le raid soft sait mieux g=C3=A9rer le stripping et lvm
"l'abstraction logique" des volumes, et qu'il vaut mieux s=C3=A9parer ces t=
=C3=A2ches ?
J'ai fait des tests avec 2 ssd (partition de 2,5Go au d=C3=A9but de chaque =
disque), raid soft ou lvm sans raid (mais sur
les 2 pv avec --stripes 2), en lenny
J'ai aussi fait des tests en =C3=A9criture ("for i in $(seq -w 1 99); do cp=
-a /sbin /mnt/test/sbin$i; done;",
mesures plus sujettes =C3=A0 caution car nettement plus variables, il aura=
it fallu faire 10 ou 20 mesures, et faire ensuite la
moyenne en virant les extr=C3=AAmes mais c'=C3=A9tait long, je voulais just=
e avoir une id=C3=A9e, et puis il aurait fallu tester avec petits
et gros fichiers, bref...)=20
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 =C3=A0 gratter qq % de
plus, la fiabilit=C3=A9/stabilit=C3=A9/simplicit=C3=A9 de maintenance =C3=
=A9tant plus importante pour moi.
Par ailleurs, si vous avez des conseils, sur le chunksize =C3=A0 choisir pa=
r 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 =C3=A0 manipuler...
--=20
Daniel
Il y a des temps o=C3=B9 l=E2=80=99on ne doit d=C3=A9penser le m=C3=A9pris =
qu=E2=80=99avec =C3=A9conomie,
=C3=A0 cause du grand nombre de n=C3=A9cessiteux.
Chateaubriand (M=C3=A9moires d'outre-tombe, 1848)
--
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/20100720075425.3c859c0d@h2.lairdutemps.org
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Julien Demange
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
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
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.
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.
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
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.
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 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
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
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
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/
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 debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/4C45A279.5010606@remiremont.fr
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
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/
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 vdanjean@debian.org
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 debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/4C46D2CB.7030503@free.fr
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/
