Et puis je sais qu'on peut faire plusieurs partitions raid sur un seul
disque, mais je voulais privilégier la facilité de maintenance en
utilisant un disque > un volume raid.
Et puis je sais qu'on peut faire plusieurs partitions raid sur un seul
disque, mais je voulais privilégier la facilité de maintenance en
utilisant un disque > un volume raid.
Et puis je sais qu'on peut faire plusieurs partitions raid sur un seul
disque, mais je voulais privilégier la facilité de maintenance en
utilisant un disque > un volume raid.
On Wed, 22 Feb 2012 18:07:07 +0100
Goldy wrote:Comme je peux finalement me passer de lvm
pour cette config, j'ai fait des tests avec une installation de la
racine directement sur le raid.
? C'est une chose de booter sur /dev/mdN, et une toute autre d'avoir,
ou non, du LVM sur les autres partoches...
C'est aussi l'une des raisons pour lesquelles on partitionne un HD.La méthode pour que cela fonctionne est de ne pas installer grub par
l'installateur mais à la fin de l'installation de chrooter avec un
terminal, d'installer grub-pc avec aptitude, et de sélectionner /dev/md0
comme disque où installer grub.
Après ça, on peut booter indépendamment sur l'un et l'autre disque.
C'est quand même dommage qu'il ne soit pas possible de faire ça avec lvm
directement.
Pas vraiment, parce qu'autant que je le sache tous les bootloaders
établissent une correspondance entre nom du fichier de boot
(kernel, map, ..) et emplacement *physique* dudit fichier.
Normal, au boot les FS ne sont pas encore dispos et il faut donc
aller pêcho les fichiers par LBA ou CHS.
Donc, pouvoir booter sur un LVM impliquerait toute une suite
d'opérations irréalisables:
* savoir que c'est la partition de boot qu'on agrandit/rétrécit,
* une fois l'op terminée, recalculer l'offset du kernel,
* mettre à jour le bootloader avec le nouvel offset.
Enfin, pas vraiment irréalisables, plutôt irréalistes; parce que si
jamais une panne surgit lors du step 2 ou 3, fini le boot!
Donc ça reviendrait à effectuer l'op en croisant les doigts ou
en priant le dieu de la micro que rien de fâcheux n'arrive, voire à
faire une imposition des mains sur le HD...
Le tout, bien entendu, parce qu'une op grow/shrink est irréversible.
On Wed, 22 Feb 2012 18:07:07 +0100
Goldy <goldy@goldenfish.info> wrote:
Comme je peux finalement me passer de lvm
pour cette config, j'ai fait des tests avec une installation de la
racine directement sur le raid.
? C'est une chose de booter sur /dev/mdN, et une toute autre d'avoir,
ou non, du LVM sur les autres partoches...
C'est aussi l'une des raisons pour lesquelles on partitionne un HD.
La méthode pour que cela fonctionne est de ne pas installer grub par
l'installateur mais à la fin de l'installation de chrooter avec un
terminal, d'installer grub-pc avec aptitude, et de sélectionner /dev/md0
comme disque où installer grub.
Après ça, on peut booter indépendamment sur l'un et l'autre disque.
C'est quand même dommage qu'il ne soit pas possible de faire ça avec lvm
directement.
Pas vraiment, parce qu'autant que je le sache tous les bootloaders
établissent une correspondance entre nom du fichier de boot
(kernel, map, ..) et emplacement *physique* dudit fichier.
Normal, au boot les FS ne sont pas encore dispos et il faut donc
aller pêcho les fichiers par LBA ou CHS.
Donc, pouvoir booter sur un LVM impliquerait toute une suite
d'opérations irréalisables:
* savoir que c'est la partition de boot qu'on agrandit/rétrécit,
* une fois l'op terminée, recalculer l'offset du kernel,
* mettre à jour le bootloader avec le nouvel offset.
Enfin, pas vraiment irréalisables, plutôt irréalistes; parce que si
jamais une panne surgit lors du step 2 ou 3, fini le boot!
Donc ça reviendrait à effectuer l'op en croisant les doigts ou
en priant le dieu de la micro que rien de fâcheux n'arrive, voire à
faire une imposition des mains sur le HD...
Le tout, bien entendu, parce qu'une op grow/shrink est irréversible.
On Wed, 22 Feb 2012 18:07:07 +0100
Goldy wrote:Comme je peux finalement me passer de lvm
pour cette config, j'ai fait des tests avec une installation de la
racine directement sur le raid.
? C'est une chose de booter sur /dev/mdN, et une toute autre d'avoir,
ou non, du LVM sur les autres partoches...
C'est aussi l'une des raisons pour lesquelles on partitionne un HD.La méthode pour que cela fonctionne est de ne pas installer grub par
l'installateur mais à la fin de l'installation de chrooter avec un
terminal, d'installer grub-pc avec aptitude, et de sélectionner /dev/md0
comme disque où installer grub.
Après ça, on peut booter indépendamment sur l'un et l'autre disque.
C'est quand même dommage qu'il ne soit pas possible de faire ça avec lvm
directement.
Pas vraiment, parce qu'autant que je le sache tous les bootloaders
établissent une correspondance entre nom du fichier de boot
(kernel, map, ..) et emplacement *physique* dudit fichier.
Normal, au boot les FS ne sont pas encore dispos et il faut donc
aller pêcho les fichiers par LBA ou CHS.
Donc, pouvoir booter sur un LVM impliquerait toute une suite
d'opérations irréalisables:
* savoir que c'est la partition de boot qu'on agrandit/rétrécit,
* une fois l'op terminée, recalculer l'offset du kernel,
* mettre à jour le bootloader avec le nouvel offset.
Enfin, pas vraiment irréalisables, plutôt irréalistes; parce que si
jamais une panne surgit lors du step 2 ou 3, fini le boot!
Donc ça reviendrait à effectuer l'op en croisant les doigts ou
en priant le dieu de la micro que rien de fâcheux n'arrive, voire à
faire une imposition des mains sur le HD...
Le tout, bien entendu, parce qu'une op grow/shrink est irréversible.
Pourtant, il est tout à fait possible de booter sur du lvm, dans mon cas
présent, il s'agissait juste de pouvoir booter indépendament su r les
deux disques raid, hors je ne pouvais booter sur depuis le premier mais
pas le second. Qu'est-ce qui fait que seul le premier disque était
bootable et pas le second ? Alors que techniquement les données sur les
deux disques sont identiques...
Pourtant, il est tout à fait possible de booter sur du lvm, dans mon cas
présent, il s'agissait juste de pouvoir booter indépendament su r les
deux disques raid, hors je ne pouvais booter sur depuis le premier mais
pas le second. Qu'est-ce qui fait que seul le premier disque était
bootable et pas le second ? Alors que techniquement les données sur les
deux disques sont identiques...
Pourtant, il est tout à fait possible de booter sur du lvm, dans mon cas
présent, il s'agissait juste de pouvoir booter indépendament su r les
deux disques raid, hors je ne pouvais booter sur depuis le premier mais
pas le second. Qu'est-ce qui fait que seul le premier disque était
bootable et pas le second ? Alors que techniquement les données sur les
deux disques sont identiques...
Le 22/02/2012 19:48, Bzzz a écrit :On Wed, 22 Feb 2012 18:07:07 +0100
Goldy wrote:Comme je peux finalement me passer de lvm
pour cette config, j'ai fait des tests avec une installation de la
racine directement sur le raid.
? C'est une chose de booter sur /dev/mdN, et une toute autre d'avoir,
ou non, du LVM sur les autres partoches...
C'est aussi l'une des raisons pour lesquelles on partitionne un HD.La méthode pour que cela fonctionne est de ne pas installer grub par
l'installateur mais à la fin de l'installation de chrooter avec un
terminal, d'installer grub-pc avec aptitude, et de sélectionner /dev/md0
comme disque où installer grub.
Après ça, on peut booter indépendamment sur l'un et l'autre disque.
C'est quand même dommage qu'il ne soit pas possible de faire ça avec lvm
directement.
Pas vraiment, parce qu'autant que je le sache tous les bootloaders
établissent une correspondance entre nom du fichier de boot
(kernel, map, ..) et emplacement *physique* dudit fichier.
Normal, au boot les FS ne sont pas encore dispos et il faut donc
aller pêcho les fichiers par LBA ou CHS.
Donc, pouvoir booter sur un LVM impliquerait toute une suite
d'opérations irréalisables:
* savoir que c'est la partition de boot qu'on agrandit/rétrécit,
* une fois l'op terminée, recalculer l'offset du kernel,
* mettre à jour le bootloader avec le nouvel offset.
Enfin, pas vraiment irréalisables, plutôt irréalistes; parce que si
jamais une panne surgit lors du step 2 ou 3, fini le boot!
Donc ça reviendrait à effectuer l'op en croisant les doigts ou
en priant le dieu de la micro que rien de fâcheux n'arrive, voire à
faire une imposition des mains sur le HD...
Le tout, bien entendu, parce qu'une op grow/shrink est irréversible.
Pourtant, il est tout à fait possible de booter sur du lvm, dans mon cas
présent, il s'agissait juste de pouvoir booter indépendament sur les
deux disques raid, hors je ne pouvais booter sur depuis le premier mais
pas le second. Qu'est-ce qui fait que seul le premier disque était
bootable et pas le second ? Alors que techniquement les données sur les
deux disques sont identiques...
--
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 22/02/2012 19:48, Bzzz a écrit :
On Wed, 22 Feb 2012 18:07:07 +0100
Goldy <goldy@goldenfish.info> wrote:
Comme je peux finalement me passer de lvm
pour cette config, j'ai fait des tests avec une installation de la
racine directement sur le raid.
? C'est une chose de booter sur /dev/mdN, et une toute autre d'avoir,
ou non, du LVM sur les autres partoches...
C'est aussi l'une des raisons pour lesquelles on partitionne un HD.
La méthode pour que cela fonctionne est de ne pas installer grub par
l'installateur mais à la fin de l'installation de chrooter avec un
terminal, d'installer grub-pc avec aptitude, et de sélectionner /dev/md0
comme disque où installer grub.
Après ça, on peut booter indépendamment sur l'un et l'autre disque.
C'est quand même dommage qu'il ne soit pas possible de faire ça avec lvm
directement.
Pas vraiment, parce qu'autant que je le sache tous les bootloaders
établissent une correspondance entre nom du fichier de boot
(kernel, map, ..) et emplacement *physique* dudit fichier.
Normal, au boot les FS ne sont pas encore dispos et il faut donc
aller pêcho les fichiers par LBA ou CHS.
Donc, pouvoir booter sur un LVM impliquerait toute une suite
d'opérations irréalisables:
* savoir que c'est la partition de boot qu'on agrandit/rétrécit,
* une fois l'op terminée, recalculer l'offset du kernel,
* mettre à jour le bootloader avec le nouvel offset.
Enfin, pas vraiment irréalisables, plutôt irréalistes; parce que si
jamais une panne surgit lors du step 2 ou 3, fini le boot!
Donc ça reviendrait à effectuer l'op en croisant les doigts ou
en priant le dieu de la micro que rien de fâcheux n'arrive, voire à
faire une imposition des mains sur le HD...
Le tout, bien entendu, parce qu'une op grow/shrink est irréversible.
Pourtant, il est tout à fait possible de booter sur du lvm, dans mon cas
présent, il s'agissait juste de pouvoir booter indépendament sur les
deux disques raid, hors je ne pouvais booter sur depuis le premier mais
pas le second. Qu'est-ce qui fait que seul le premier disque était
bootable et pas le second ? Alors que techniquement les données sur les
deux disques sont identiques...
--
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/4F454A39.6080401@goldenfish.info
Le 22/02/2012 19:48, Bzzz a écrit :On Wed, 22 Feb 2012 18:07:07 +0100
Goldy wrote:Comme je peux finalement me passer de lvm
pour cette config, j'ai fait des tests avec une installation de la
racine directement sur le raid.
? C'est une chose de booter sur /dev/mdN, et une toute autre d'avoir,
ou non, du LVM sur les autres partoches...
C'est aussi l'une des raisons pour lesquelles on partitionne un HD.La méthode pour que cela fonctionne est de ne pas installer grub par
l'installateur mais à la fin de l'installation de chrooter avec un
terminal, d'installer grub-pc avec aptitude, et de sélectionner /dev/md0
comme disque où installer grub.
Après ça, on peut booter indépendamment sur l'un et l'autre disque.
C'est quand même dommage qu'il ne soit pas possible de faire ça avec lvm
directement.
Pas vraiment, parce qu'autant que je le sache tous les bootloaders
établissent une correspondance entre nom du fichier de boot
(kernel, map, ..) et emplacement *physique* dudit fichier.
Normal, au boot les FS ne sont pas encore dispos et il faut donc
aller pêcho les fichiers par LBA ou CHS.
Donc, pouvoir booter sur un LVM impliquerait toute une suite
d'opérations irréalisables:
* savoir que c'est la partition de boot qu'on agrandit/rétrécit,
* une fois l'op terminée, recalculer l'offset du kernel,
* mettre à jour le bootloader avec le nouvel offset.
Enfin, pas vraiment irréalisables, plutôt irréalistes; parce que si
jamais une panne surgit lors du step 2 ou 3, fini le boot!
Donc ça reviendrait à effectuer l'op en croisant les doigts ou
en priant le dieu de la micro que rien de fâcheux n'arrive, voire à
faire une imposition des mains sur le HD...
Le tout, bien entendu, parce qu'une op grow/shrink est irréversible.
Pourtant, il est tout à fait possible de booter sur du lvm, dans mon cas
présent, il s'agissait juste de pouvoir booter indépendament sur les
deux disques raid, hors je ne pouvais booter sur depuis le premier mais
pas le second. Qu'est-ce qui fait que seul le premier disque était
bootable et pas le second ? Alors que techniquement les données sur les
deux disques sont identiques...
--
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 Wed, 22 Feb 2012 20:59:56 +0100
Goldy wrote:
Et puis je sais qu'on peut faire plusieurs partitions raid sur un seul
disque, mais je voulais privilégier la facilité de maintenance en
utilisant un disque > un volume raid.
IMHO la seule chose à vraiment privilégier ce sont les données.
Et ce n'est une si bonne idée: étant donné la taille des HDz
d'aujourd'hui un seul check (ou reconstruction) doit prendre un
max de temps, alors qu'en sectionnant on peut déplacer les checks
dans le temps et/ou le Nb de montages, notamment en fonction de
l'utilisation de chacune des sections.
Sans compter le vieil adage: "Ne jamais mettre ses œufs dans le même
panier".
On Wed, 22 Feb 2012 20:59:56 +0100
Goldy <goldy@goldenfish.info> wrote:
Et puis je sais qu'on peut faire plusieurs partitions raid sur un seul
disque, mais je voulais privilégier la facilité de maintenance en
utilisant un disque > un volume raid.
IMHO la seule chose à vraiment privilégier ce sont les données.
Et ce n'est une si bonne idée: étant donné la taille des HDz
d'aujourd'hui un seul check (ou reconstruction) doit prendre un
max de temps, alors qu'en sectionnant on peut déplacer les checks
dans le temps et/ou le Nb de montages, notamment en fonction de
l'utilisation de chacune des sections.
Sans compter le vieil adage: "Ne jamais mettre ses œufs dans le même
panier".
On Wed, 22 Feb 2012 20:59:56 +0100
Goldy wrote:
Et puis je sais qu'on peut faire plusieurs partitions raid sur un seul
disque, mais je voulais privilégier la facilité de maintenance en
utilisant un disque > un volume raid.
IMHO la seule chose à vraiment privilégier ce sont les données.
Et ce n'est une si bonne idée: étant donné la taille des HDz
d'aujourd'hui un seul check (ou reconstruction) doit prendre un
max de temps, alors qu'en sectionnant on peut déplacer les checks
dans le temps et/ou le Nb de montages, notamment en fonction de
l'utilisation de chacune des sections.
Sans compter le vieil adage: "Ne jamais mettre ses œufs dans le même
panier".
> IMHO la seule chose à vraiment privilégier ce sont les donn ées.
Je ne vois pas trop comment on peut sécuriser d'avantage en segmenta nt
les volumes comme tu le suggères, l'idée étant justement d e faire
quelque chose de simple de façon à pouvoir facilement répa rer et éviter
de faire une bêtise en cas d'intervention sur la machine, et pour moi
une grappe raid avec du lvm dedans pour segmenter me semble être une
configuration assez pertinente, ou alors faut qu'on m'explique ce que
j'aurai à gagner à ne pas faire ainsi.
La machine que je dois faire est un desktop,
donc je n'aurai pas de
configuration complexe à mettre en place, ce qu'il est nécessai re, c'est
que le système soit robuste et que les données ne s'efface pas en cas de
panne d'un disque dur et que la machine puisse être utilisée le temps
qu'une intervention soit réalisé.
> IMHO la seule chose à vraiment privilégier ce sont les donn ées.
Je ne vois pas trop comment on peut sécuriser d'avantage en segmenta nt
les volumes comme tu le suggères, l'idée étant justement d e faire
quelque chose de simple de façon à pouvoir facilement répa rer et éviter
de faire une bêtise en cas d'intervention sur la machine, et pour moi
une grappe raid avec du lvm dedans pour segmenter me semble être une
configuration assez pertinente, ou alors faut qu'on m'explique ce que
j'aurai à gagner à ne pas faire ainsi.
La machine que je dois faire est un desktop,
donc je n'aurai pas de
configuration complexe à mettre en place, ce qu'il est nécessai re, c'est
que le système soit robuste et que les données ne s'efface pas en cas de
panne d'un disque dur et que la machine puisse être utilisée le temps
qu'une intervention soit réalisé.
> IMHO la seule chose à vraiment privilégier ce sont les donn ées.
Je ne vois pas trop comment on peut sécuriser d'avantage en segmenta nt
les volumes comme tu le suggères, l'idée étant justement d e faire
quelque chose de simple de façon à pouvoir facilement répa rer et éviter
de faire une bêtise en cas d'intervention sur la machine, et pour moi
une grappe raid avec du lvm dedans pour segmenter me semble être une
configuration assez pertinente, ou alors faut qu'on m'explique ce que
j'aurai à gagner à ne pas faire ainsi.
La machine que je dois faire est un desktop,
donc je n'aurai pas de
configuration complexe à mettre en place, ce qu'il est nécessai re, c'est
que le système soit robuste et que les données ne s'efface pas en cas de
panne d'un disque dur et que la machine puisse être utilisée le temps
qu'une intervention soit réalisé.
On Thu, 23 Feb 2012 01:15:38 +0100
Goldy wrote:IMHO la seule chose à vraiment privilégier ce sont les données.
Je ne vois pas trop comment on peut sécuriser d'avantage en segmentant
les volumes comme tu le suggères, l'idée étant justement de faire
quelque chose de simple de façon à pouvoir facilement réparer et éviter
de faire une bêtise en cas d'intervention sur la machine, et pour moi
une grappe raid avec du lvm dedans pour segmenter me semble être une
configuration assez pertinente, ou alors faut qu'on m'explique ce que
j'aurai à gagner à ne pas faire ainsi.
Ce n'est pas ce que je voulais dire, je parlais de segmenter en
plusieurs partitions, chacune en RAID.La machine que je dois faire est un desktop,
Et tu as *besoin* de LVM sur un desktop???donc je n'aurai pas de
configuration complexe à mettre en place, ce qu'il est nécessaire, c'est
que le système soit robuste et que les données ne s'efface pas en cas de
panne d'un disque dur et que la machine puisse être utilisée le temps
qu'une intervention soit réalisé.
C'est un faux PB: on peut gratter des procédures, même pour ceux qui
ne maîtrisent pas le hard, et les glisser dans une pochette crystal
scotchée au micro. (Et de toute façon en cas de casse il faudra bien
arrêter la machine, remplacer le HD et refaire sa table des
partitions; à moins qu'il n'y ait un spare dans l'array).
Dans mon expérience, le couple RAID-LVM est un couple infernal:
c'est la meilleure façon de perdre ses données lors d'un PB LVM (ok,
ça date, mais pas de tant que ça: ~6ans).
Sans compter que si c'est le HA qui prime, du simple RAID-1
suffit; la segmentation c'est juste pour éviter de perdre bcp de
temps lors d'un check; pour une reconstruction ça prendra autant de
temps, mais en cas de coupure ça ne repartira pas de zéro.
ET il ne faut pas oublier de faire des checks: la RAID assure le HA,
PAS l'intégrité des disques.
On Thu, 23 Feb 2012 01:15:38 +0100
Goldy <goldy@goldenfish.info> wrote:
IMHO la seule chose à vraiment privilégier ce sont les données.
Je ne vois pas trop comment on peut sécuriser d'avantage en segmentant
les volumes comme tu le suggères, l'idée étant justement de faire
quelque chose de simple de façon à pouvoir facilement réparer et éviter
de faire une bêtise en cas d'intervention sur la machine, et pour moi
une grappe raid avec du lvm dedans pour segmenter me semble être une
configuration assez pertinente, ou alors faut qu'on m'explique ce que
j'aurai à gagner à ne pas faire ainsi.
Ce n'est pas ce que je voulais dire, je parlais de segmenter en
plusieurs partitions, chacune en RAID.
La machine que je dois faire est un desktop,
Et tu as *besoin* de LVM sur un desktop???
donc je n'aurai pas de
configuration complexe à mettre en place, ce qu'il est nécessaire, c'est
que le système soit robuste et que les données ne s'efface pas en cas de
panne d'un disque dur et que la machine puisse être utilisée le temps
qu'une intervention soit réalisé.
C'est un faux PB: on peut gratter des procédures, même pour ceux qui
ne maîtrisent pas le hard, et les glisser dans une pochette crystal
scotchée au micro. (Et de toute façon en cas de casse il faudra bien
arrêter la machine, remplacer le HD et refaire sa table des
partitions; à moins qu'il n'y ait un spare dans l'array).
Dans mon expérience, le couple RAID-LVM est un couple infernal:
c'est la meilleure façon de perdre ses données lors d'un PB LVM (ok,
ça date, mais pas de tant que ça: ~6ans).
Sans compter que si c'est le HA qui prime, du simple RAID-1
suffit; la segmentation c'est juste pour éviter de perdre bcp de
temps lors d'un check; pour une reconstruction ça prendra autant de
temps, mais en cas de coupure ça ne repartira pas de zéro.
ET il ne faut pas oublier de faire des checks: la RAID assure le HA,
PAS l'intégrité des disques.
On Thu, 23 Feb 2012 01:15:38 +0100
Goldy wrote:IMHO la seule chose à vraiment privilégier ce sont les données.
Je ne vois pas trop comment on peut sécuriser d'avantage en segmentant
les volumes comme tu le suggères, l'idée étant justement de faire
quelque chose de simple de façon à pouvoir facilement réparer et éviter
de faire une bêtise en cas d'intervention sur la machine, et pour moi
une grappe raid avec du lvm dedans pour segmenter me semble être une
configuration assez pertinente, ou alors faut qu'on m'explique ce que
j'aurai à gagner à ne pas faire ainsi.
Ce n'est pas ce que je voulais dire, je parlais de segmenter en
plusieurs partitions, chacune en RAID.La machine que je dois faire est un desktop,
Et tu as *besoin* de LVM sur un desktop???donc je n'aurai pas de
configuration complexe à mettre en place, ce qu'il est nécessaire, c'est
que le système soit robuste et que les données ne s'efface pas en cas de
panne d'un disque dur et que la machine puisse être utilisée le temps
qu'une intervention soit réalisé.
C'est un faux PB: on peut gratter des procédures, même pour ceux qui
ne maîtrisent pas le hard, et les glisser dans une pochette crystal
scotchée au micro. (Et de toute façon en cas de casse il faudra bien
arrêter la machine, remplacer le HD et refaire sa table des
partitions; à moins qu'il n'y ait un spare dans l'array).
Dans mon expérience, le couple RAID-LVM est un couple infernal:
c'est la meilleure façon de perdre ses données lors d'un PB LVM (ok,
ça date, mais pas de tant que ça: ~6ans).
Sans compter que si c'est le HA qui prime, du simple RAID-1
suffit; la segmentation c'est juste pour éviter de perdre bcp de
temps lors d'un check; pour une reconstruction ça prendra autant de
temps, mais en cas de coupure ça ne repartira pas de zéro.
ET il ne faut pas oublier de faire des checks: la RAID assure le HA,
PAS l'intégrité des disques.
Comme je l'ai dit, dans mon cas c'était juste pour avoir une partiti on
de swap, mais ce n'est pas obligatoire, ce que je vais faire c'est crà ©er
un fichier de swap dans le cas présent.
Comme je l'ai dit, dans mon cas c'était juste pour avoir une partiti on
de swap, mais ce n'est pas obligatoire, ce que je vais faire c'est crà ©er
un fichier de swap dans le cas présent.
Comme je l'ai dit, dans mon cas c'était juste pour avoir une partiti on
de swap, mais ce n'est pas obligatoire, ce que je vais faire c'est crà ©er
un fichier de swap dans le cas présent.
Pourtant, il est tout à fait possible de booter sur du lvm, dans mon cas
présent, il s'agissait juste de pouvoir booter indépendament sur les
deux disques raid, hors je ne pouvais booter sur depuis le premier mais
pas le second. Qu'est-ce qui fait que seul le premier disque était
bootable et pas le second ? Alors que techniquement les données sur les
deux disques sont identiques...
Pourtant, il est tout à fait possible de booter sur du lvm, dans mon cas
présent, il s'agissait juste de pouvoir booter indépendament sur les
deux disques raid, hors je ne pouvais booter sur depuis le premier mais
pas le second. Qu'est-ce qui fait que seul le premier disque était
bootable et pas le second ? Alors que techniquement les données sur les
deux disques sont identiques...
Pourtant, il est tout à fait possible de booter sur du lvm, dans mon cas
présent, il s'agissait juste de pouvoir booter indépendament sur les
deux disques raid, hors je ne pouvais booter sur depuis le premier mais
pas le second. Qu'est-ce qui fait que seul le premier disque était
bootable et pas le second ? Alors que techniquement les données sur les
deux disques sont identiques...
On Thu, 23 Feb 2012 02:06:26 +0100
Goldy wrote:
> Comme je l'ai dit, dans mon cas c'était juste pour avoir
> une partition de swap, mais ce n'est pas obligatoire, ce
> que je vais faire c'est créer un fichier de swap dans le
> cas présent.
Profites-en pour la mettre en RAID0 (et au passage, on peut
facilement swapper sur un fichier, la perte de perf reste
minime, sauf évidemment si le fichier est en fin de HD).
On Thu, 23 Feb 2012 02:06:26 +0100
Goldy <goldy@goldenfish.info> wrote:
> Comme je l'ai dit, dans mon cas c'était juste pour avoir
> une partition de swap, mais ce n'est pas obligatoire, ce
> que je vais faire c'est créer un fichier de swap dans le
> cas présent.
Profites-en pour la mettre en RAID0 (et au passage, on peut
facilement swapper sur un fichier, la perte de perf reste
minime, sauf évidemment si le fichier est en fin de HD).
On Thu, 23 Feb 2012 02:06:26 +0100
Goldy wrote:
> Comme je l'ai dit, dans mon cas c'était juste pour avoir
> une partition de swap, mais ce n'est pas obligatoire, ce
> que je vais faire c'est créer un fichier de swap dans le
> cas présent.
Profites-en pour la mettre en RAID0 (et au passage, on peut
facilement swapper sur un fichier, la perte de perf reste
minime, sauf évidemment si le fichier est en fin de HD).
