Bonjour,
Je joue un peu avec LVM2 et j'ai du mal à comprendre
l'intérêt d'un LV "strippé" quand la politique d'allocation
du VG dans lequel on le crée est par défaut à normal, qui
semble déjà réaliser une sorte de stripping (d'après le man
lvm). Par exemple, si j'ai 2 disques durs de 1 To, donc 2
PVs, je crée un VG avec ces 2 PVs puis un LV de 500 Go, les
PE correspondant à ce LV vont être répartis plus ou moins
également sur ces 2 disques, non ? Ce qui permet d'obtenir
des performances accrues en terme de taux de transfert (Ã
partir du moment où on accède à des fichiers de taille
supérieure à celle d'un PE), un peu comme un RAID0 ?
Bonjour,
Je joue un peu avec LVM2 et j'ai du mal à comprendre
l'intérêt d'un LV "strippé" quand la politique d'allocation
du VG dans lequel on le crée est par défaut à normal, qui
semble déjà réaliser une sorte de stripping (d'après le man
lvm). Par exemple, si j'ai 2 disques durs de 1 To, donc 2
PVs, je crée un VG avec ces 2 PVs puis un LV de 500 Go, les
PE correspondant à ce LV vont être répartis plus ou moins
également sur ces 2 disques, non ? Ce qui permet d'obtenir
des performances accrues en terme de taux de transfert (Ã
partir du moment où on accède à des fichiers de taille
supérieure à celle d'un PE), un peu comme un RAID0 ?
Bonjour,
Je joue un peu avec LVM2 et j'ai du mal à comprendre
l'intérêt d'un LV "strippé" quand la politique d'allocation
du VG dans lequel on le crée est par défaut à normal, qui
semble déjà réaliser une sorte de stripping (d'après le man
lvm). Par exemple, si j'ai 2 disques durs de 1 To, donc 2
PVs, je crée un VG avec ces 2 PVs puis un LV de 500 Go, les
PE correspondant à ce LV vont être répartis plus ou moins
également sur ces 2 disques, non ? Ce qui permet d'obtenir
des performances accrues en terme de taux de transfert (Ã
partir du moment où on accède à des fichiers de taille
supérieure à celle d'un PE), un peu comme un RAID0 ?
Le jeudi 22 septembre 2011 à 23:26:23, dju` a écrit :
> Bonjour,
âjour,
> Je joue un peu avec LVM2 et j'ai du mal à comprendre
> l'intérêt d'un LV "strippé" quand la politique d'allocat ion
> du VG dans lequel on le crée est par défaut à normal, qu i
> semble déjà réaliser une sorte de stripping (d'aprè s le man
^^ attention :
to stripe â striping, a stripe [stɹaɪp]
to strip â stripping, a strip-tease [stɹɪp]
;o)
> lvm). Par exemple, si j'ai 2 disques durs de 1 To, donc 2
> PVs, je crée un VG avec ces 2 PVs puis un LV de 500 Go, les
> PE correspondant à ce LV vont être répartis plus ou moin s
> également sur ces 2 disques, non ? Ce qui permet d'obtenir
> des performances accrues en terme de taux de transfert (Ã
> partir du moment où on accède à des fichiers de taille
> supérieure à celle d'un PE), un peu comme un RAID0 ?
Non.
Quand on veut du /striping/ on le dit avec lâoption --stripes.
Sinon, dâaprès ce que je comprends et souhaiterais, il nâ y en a
pas (ce nâest pas toujours ce que lâon veut ni ce qui est
utile).
Quand le man nous dit que la politique dâallocation /normal/
fait que les bandes parallèles ne seront pas placées sur le m ême
PV, je crois quâil faut faire attention au mot « parallà ¨les » :
le parallélisme nâa de sens que dans le contexte dâu n mirroir.
Rien nâest dit sur lâalternance des PV sans --stripes. O n sait
juste que, dans le cas avec --stripes :
â /contigue/ se fout des bandes ;
â /anywhere/ _peut_ les placer sur le même PV ;
â /cling/ fait du contigu à lâintérieur des ban des.
Le jeudi 22 septembre 2011 à 23:26:23, dju` a écrit :
> Bonjour,
âjour,
> Je joue un peu avec LVM2 et j'ai du mal à comprendre
> l'intérêt d'un LV "strippé" quand la politique d'allocat ion
> du VG dans lequel on le crée est par défaut à normal, qu i
> semble déjà réaliser une sorte de stripping (d'aprè s le man
^^ attention :
to stripe â striping, a stripe [stɹaɪp]
to strip â stripping, a strip-tease [stɹɪp]
;o)
> lvm). Par exemple, si j'ai 2 disques durs de 1 To, donc 2
> PVs, je crée un VG avec ces 2 PVs puis un LV de 500 Go, les
> PE correspondant à ce LV vont être répartis plus ou moin s
> également sur ces 2 disques, non ? Ce qui permet d'obtenir
> des performances accrues en terme de taux de transfert (Ã
> partir du moment où on accède à des fichiers de taille
> supérieure à celle d'un PE), un peu comme un RAID0 ?
Non.
Quand on veut du /striping/ on le dit avec lâoption --stripes.
Sinon, dâaprès ce que je comprends et souhaiterais, il nâ y en a
pas (ce nâest pas toujours ce que lâon veut ni ce qui est
utile).
Quand le man nous dit que la politique dâallocation /normal/
fait que les bandes parallèles ne seront pas placées sur le m ême
PV, je crois quâil faut faire attention au mot « parallà ¨les » :
le parallélisme nâa de sens que dans le contexte dâu n mirroir.
Rien nâest dit sur lâalternance des PV sans --stripes. O n sait
juste que, dans le cas avec --stripes :
â /contigue/ se fout des bandes ;
â /anywhere/ _peut_ les placer sur le même PV ;
â /cling/ fait du contigu à lâintérieur des ban des.
Le jeudi 22 septembre 2011 à 23:26:23, dju` a écrit :
> Bonjour,
âjour,
> Je joue un peu avec LVM2 et j'ai du mal à comprendre
> l'intérêt d'un LV "strippé" quand la politique d'allocat ion
> du VG dans lequel on le crée est par défaut à normal, qu i
> semble déjà réaliser une sorte de stripping (d'aprè s le man
^^ attention :
to stripe â striping, a stripe [stɹaɪp]
to strip â stripping, a strip-tease [stɹɪp]
;o)
> lvm). Par exemple, si j'ai 2 disques durs de 1 To, donc 2
> PVs, je crée un VG avec ces 2 PVs puis un LV de 500 Go, les
> PE correspondant à ce LV vont être répartis plus ou moin s
> également sur ces 2 disques, non ? Ce qui permet d'obtenir
> des performances accrues en terme de taux de transfert (Ã
> partir du moment où on accède à des fichiers de taille
> supérieure à celle d'un PE), un peu comme un RAID0 ?
Non.
Quand on veut du /striping/ on le dit avec lâoption --stripes.
Sinon, dâaprès ce que je comprends et souhaiterais, il nâ y en a
pas (ce nâest pas toujours ce que lâon veut ni ce qui est
utile).
Quand le man nous dit que la politique dâallocation /normal/
fait que les bandes parallèles ne seront pas placées sur le m ême
PV, je crois quâil faut faire attention au mot « parallà ¨les » :
le parallélisme nâa de sens que dans le contexte dâu n mirroir.
Rien nâest dit sur lâalternance des PV sans --stripes. O n sait
juste que, dans le cas avec --stripes :
â /contigue/ se fout des bandes ;
â /anywhere/ _peut_ les placer sur le même PV ;
â /cling/ fait du contigu à lâintérieur des ban des.
[â¦]
Concernant la taille des stripes, elle ne doit pas dépasser
celle d'un PE. Donc en fait chaque PE est subdivisé en
fragments ?
Moi qui pensait que le PE était la plus petite
unité de données possible au sein de LVM... Dans ce cas,
autant spécifier la taille minimale pour les stripes (4 Ko
d'après mes tests), ce qui fera bénéficier des performances
du striping pour un maximum de fichiers (et pas seulement
les plus gros), non ?
Autre question, est-ce possible de re-répartir un LV sur
moins de stripes que prévu à sa création (avec le paramà ¨tre
--stripes), dans le cas où l'on voudrait retirer un disque
physique du VG ?
[â¦]
Concernant la taille des stripes, elle ne doit pas dépasser
celle d'un PE. Donc en fait chaque PE est subdivisé en
fragments ?
Moi qui pensait que le PE était la plus petite
unité de données possible au sein de LVM... Dans ce cas,
autant spécifier la taille minimale pour les stripes (4 Ko
d'après mes tests), ce qui fera bénéficier des performances
du striping pour un maximum de fichiers (et pas seulement
les plus gros), non ?
Autre question, est-ce possible de re-répartir un LV sur
moins de stripes que prévu à sa création (avec le paramà ¨tre
--stripes), dans le cas où l'on voudrait retirer un disque
physique du VG ?
[â¦]
Concernant la taille des stripes, elle ne doit pas dépasser
celle d'un PE. Donc en fait chaque PE est subdivisé en
fragments ?
Moi qui pensait que le PE était la plus petite
unité de données possible au sein de LVM... Dans ce cas,
autant spécifier la taille minimale pour les stripes (4 Ko
d'après mes tests), ce qui fera bénéficier des performances
du striping pour un maximum de fichiers (et pas seulement
les plus gros), non ?
Autre question, est-ce possible de re-répartir un LV sur
moins de stripes que prévu à sa création (avec le paramà ¨tre
--stripes), dans le cas où l'on voudrait retirer un disque
physique du VG ?
[Pas de CC, merci.]
Le samedi 24 septembre 2011 à 00:22:32, dju` a écrit :
>[â¦]
> Concernant la taille des stripes, elle ne doit pas dépasser
> celle d'un PE. Donc en fait chaque PE est subdivisé en
> fragments ?
Ah oui, tiens, jâavais pas fait gaffeâ¦
> Moi qui pensait que le PE était la plus petite
> unité de données possible au sein de LVM... Dans ce cas,
> autant spécifier la taille minimale pour les stripes (4 Ko
> d'après mes tests), ce qui fera bénéficier des performan ces
> du striping pour un maximum de fichiers (et pas seulement
> les plus gros), non ?
Pas vraiment. Il vaut mieux spécifier la taille minimale qui
est lue par le disque en une opération. Ce qui nâest pas à ©vident
à établir avec tous les caches intermédiaires (et les poli tiques
de pré-lecture)â¦
> Autre question, est-ce possible de re-répartir un LV sur
> moins de stripes que prévu à sa création (avec le param ètre
> --stripes), dans le cas où l'on voudrait retirer un disque
> physique du VG ?
Sais pasâ¦
[Pas de CC, merci.]
Le samedi 24 septembre 2011 à 00:22:32, dju` a écrit :
>[â¦]
> Concernant la taille des stripes, elle ne doit pas dépasser
> celle d'un PE. Donc en fait chaque PE est subdivisé en
> fragments ?
Ah oui, tiens, jâavais pas fait gaffeâ¦
> Moi qui pensait que le PE était la plus petite
> unité de données possible au sein de LVM... Dans ce cas,
> autant spécifier la taille minimale pour les stripes (4 Ko
> d'après mes tests), ce qui fera bénéficier des performan ces
> du striping pour un maximum de fichiers (et pas seulement
> les plus gros), non ?
Pas vraiment. Il vaut mieux spécifier la taille minimale qui
est lue par le disque en une opération. Ce qui nâest pas à ©vident
à établir avec tous les caches intermédiaires (et les poli tiques
de pré-lecture)â¦
> Autre question, est-ce possible de re-répartir un LV sur
> moins de stripes que prévu à sa création (avec le param ètre
> --stripes), dans le cas où l'on voudrait retirer un disque
> physique du VG ?
Sais pasâ¦
[Pas de CC, merci.]
Le samedi 24 septembre 2011 à 00:22:32, dju` a écrit :
>[â¦]
> Concernant la taille des stripes, elle ne doit pas dépasser
> celle d'un PE. Donc en fait chaque PE est subdivisé en
> fragments ?
Ah oui, tiens, jâavais pas fait gaffeâ¦
> Moi qui pensait que le PE était la plus petite
> unité de données possible au sein de LVM... Dans ce cas,
> autant spécifier la taille minimale pour les stripes (4 Ko
> d'après mes tests), ce qui fera bénéficier des performan ces
> du striping pour un maximum de fichiers (et pas seulement
> les plus gros), non ?
Pas vraiment. Il vaut mieux spécifier la taille minimale qui
est lue par le disque en une opération. Ce qui nâest pas à ©vident
à établir avec tous les caches intermédiaires (et les poli tiques
de pré-lecture)â¦
> Autre question, est-ce possible de re-répartir un LV sur
> moins de stripes que prévu à sa création (avec le param ètre
> --stripes), dans le cas où l'on voudrait retirer un disque
> physique du VG ?
Sais pasâ¦
[â¦]
Bon, donc autant garder les tailles de stripes par défaut (64
Ko) ?
[⦠de la possibilité de remplacer un disque dans une
configuration en alternance â¦]
[â¦]
Bon, donc autant garder les tailles de stripes par défaut (64
Ko) ?
[⦠de la possibilité de remplacer un disque dans une
configuration en alternance â¦]
[â¦]
Bon, donc autant garder les tailles de stripes par défaut (64
Ko) ?
[⦠de la possibilité de remplacer un disque dans une
configuration en alternance â¦]
