cerhu > linux.debian.user.french

Jean-Marc (09/03/2019, 13h40)
salut la liste,

J'ai deux disques dans mon PC que je compte utilisés en plus du SSD sur lequel j'ai mon système.

Je pense les regrouper en RAID, histoire de me protéger de certaines pannes.

Entre mdadm et LVM, j'hésite.

LVM me semble plus souple (RAID au niveau volume logique si j'ai bien lu ladoc).

Des conseils ? D'autres suggestions ?

Merci d'avance.

Jean-Marc <jean-marc>
[..]
Frédéric MASSOT (09/03/2019, 14h00)
Le 09/03/2019 à 10:03, Jean-Marc a écrit :
> salut la liste,
> J'ai deux disques dans mon PC que je compte utilisés en plus du SSD sur lequel j'ai mon système.
> Je pense les regrouper en RAID, histoire de me protéger de certaines pannes.
> Entre mdadm et LVM, j'hésite.
> LVM me semble plus souple (RAID au niveau volume logique si j'ai bien lu la doc).
> Des conseils ? D'autres suggestions ?


Il faut utiliser les deux, tu assembles tes disques dans un ensemble
unique RAID avec mdadm, ensuite tu partitionnes cet ensemble unique avec
LVM.
Guillaume Clercin (09/03/2019, 14h20)
Bonjour,

On Sat, 9 Mar 2019 10:03:28 +0100
Jean-Marc <jean-marc> wrote:

> salut la liste,
> J'ai deux disques dans mon PC que je compte utilisés en plus du SSD
> sur lequel j'ai mon système.
> Je pense les regrouper en RAID, histoire de me protéger de certaines
> pannes.
> Entre mdadm et LVM, j'hésite.
> LVM me semble plus souple (RAID au niveau volume logique si j'ai bien
> lu la doc).
> Des conseils ? D'autres suggestions ?


Tu peut marier les deux en utilisant LVM sur un raid créé par mdadm.

Si tu installes le système dans un volume logique, tu doit avoir un
« /boot » sur une partition à part. Sauf s'il y a un raid logiciel en
dessous du volume logique.

Sur l'ordinateur à mon travail, j'ai deux disques durs et un ssd.
J'assemble les deux disques dur pour faire un raid 1. Ensuite je
partition le raid en trois partitions pour avoir un « /boot » et une
« swap » séparés. Avec la troisième partition et le ssd, je les utlise
avec bcache. Et pour finir, j'ai deux volumes logiques, l'un pour la
racine et l'autre pour « /home ». En bonus, j'ai laissé un peu d'espace
disques dans le volume groupe pour pouvoir créer des snapshots que
j'utilise lorsque que je fais des backups.

La sortie de lsblk donne pour info :
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 1,8T 0 disk
??sda1 8:1 0 1,8T 0 part
??md127 9:127 0 1,8T 0 raid1
??md127p1 259:0 0 1G 0 part /boot
??md127p2 259:1 0 2G 0 part [SWAP]
??md127p3 259:2 0 1,8T 0 part
??bcache0 254:0 0 1,8T 0 disk
??system-root 252:0 0 128G 0 lvm /
??system-home 252:1 0 1,6T 0 lvm /home
sdb 8:16 0 1,8T 0 disk
??sdb1 8:17 0 1,8T 0 part
??md127 9:127 0 1,8T 0 raid1
??md127p1 259:0 0 1G 0 part /boot
??md127p2 259:1 0 2G 0 part [SWAP]
??md127p3 259:2 0 1,8T 0 part
??bcache0 254:0 0 1,8T 0 disk
??system-root 252:0 0 128G 0 lvm /
??system-home 252:1 0 1,6T 0 lvm /home
sdc 8:32 0 55,9G 0 disk
??bcache0 254:0 0 1,8T 0 disk
??system-root 252:0 0 128G 0 lvm /
??system-home 252:1 0 1,6T 0 lvm /home
sr0 11:0 1 1024M 0 rom
[..]
Jean-Michel OLTRA (09/03/2019, 15h00)
Bonjour,

Le samedi 09 mars 2019, Jean-Marc a écrit...

> Des conseils ? D'autres suggestions ?


J'utilise, comme on te l'a déjà conseillé, un système à base de lvm sur
raid1 depuis de nombreuses années, et sans souci.

Sinon, j'ai rajouté un 3ème disque de spare sur mon raid. Lorsque l'un des 2
principaux tombe, j'ai un peu de temps pour remettre l'ensemble à niveau
tout en conservant le raid opérationnel.
Pascal Hambourg (09/03/2019, 21h00)
Le 09/03/2019 à 13:01, Guillaume Clercin a écrit :
> Si tu installes le système dans un volume logique, tu doit avoir un
> « /boot » sur une partition à part.


Non. GRUB sait lire dans les volumes logiques LVM.

> Sauf s'il y a un raid logiciel en dessous du volume logique.


Non plus. En quoi le RAID logiciel changerait-il quelque chose ?
Guillaume Clercin (10/03/2019, 13h50)
On Sat, 9 Mar 2019 19:51:39 +0100
Pascal Hambourg <pascal> wrote:

> Le 09/03/2019 à 13:01, Guillaume Clercin a écrit :
> > Si tu installes le système dans un volume logique, tu doit avoir un
> > « /boot » sur une partition à part.

> Non. GRUB sait lire dans les volumes logiques LVM.

Le problème vient de la commande « grub-install ».J'ai installé sur un
serveur une Debian buster et lors de la première tentative, je n'avais
pas de « /boot » séparé et l'installation a échoué au moment du
« grub-install ». Ensuite, je refais l'installation en créant un
« /boot » dans une partition donc en dehors LVM, et la commande
« grub-install » a fonctionné. Cette expérience confirme la
documentation de la Debian « [..] dans la
partie « bon à savoir ».

> > Sauf s'il y a un raid logiciel en dessous du volume logique.

> Non plus. En quoi le RAID logiciel changerait-il quelque chose ?

C'est lié à la commande « grub-install »
Pascal Hambourg (10/03/2019, 20h10)
Le 10/03/2019 à 12:47, Guillaume Clercin a écrit :
> On Sat, 9 Mar 2019 19:51:39 +0100
> Pascal Hambourg <pascal> wrote:
> Le problème vient de la commande « grub-install ». J'ai installé sur un
> serveur une Debian buster et lors de la première tentative, je n'avais
> pas de « /boot » séparé et l'installation a échoué au moment du
> « grub-install ».


J'ai fait plusieurs installations de diverses versions stables de Debian
avec /boot en LVM, avec succès.

> Ensuite, je refais l'installation en créant un
> « /boot » dans une partition donc en dehors LVM, et la commande
> « grub-install » a fonctionné. Cette expérience confirme la
> documentation de la Debian « [..] dans la
> partie « bon à savoir ».


Ce paragraphe du wiki ne s'applique qu'à l'ancien GRUB "legacy" (version
1). La version actuelle de GRUB (version 2) supporte LVM, le RAID
logiciel, et même les conteneurs de volumes chiffrés LUKS (mais pas avec
l'installateur Debian).

L'exécution de grub-install peut échouer pour bien d'autres raisons.
GRUB peut être installé avec /boot en LVM à condition que l'emplacement
spécifié dans la commande soit compatible avec la mise en place de la
boot image et de la core image de GRUB.

S'il s'agit d'une partition, le format de son contenu doit bien entendu
permettre d'utiliser son premier secteur comme secteur d'amorce (ce
n'est pas spécifique à l'installation avec LVM) mais aussi réserver un
espace utilisable par GRUB pour y installer sa core image. Le format de
PV LVM peut réserver un tel emplacement, mais la version actuelle de
GRUB ne sait pas encore l'exploiter.

S'il s'agit d'un disque entier (au sens large, incluant SSD, clé USB et
carte SD) cela dépend du format de la table de partition. Si elle est au
format DOS/MBR, l'espace non alloué entre le MBR et la première
partition doit être suffisant pour contenir la core image, ce qui est le
cas avec l'alignement actuel qui fait commencer la première partition au
secteur 2048 (1 Mo) mais n'était pas toujours le cas avec l'alignement
traditionnel sur les cylindres qui faisait commencer la première
partition au secteur 63 (32 Ko). Si elle est au format GPT, il faut une
partition non formatée de type "BIOS boot" de taille suffisante.

>>> Sauf s'il y a un raid logiciel en dessous du volume logique.

>> Non plus. En quoi le RAID logiciel changerait-il quelque chose ?

> C'est lié à la commande « grub-install »


Mais encore ?
A mon avis c'est lié à une expérience dont le résultat a été mal interprété.
Stephane Ascoet (11/03/2019, 11h40)
Le 10/03/2019 à 19:04, Pascal Hambourg a écrit :
> J'ai fait plusieurs installations de diverses versions stables de Debian
> avec /boot en LVM, avec succès.


Bonjour, je ne peux en dire autant. J'ai des resultats aleatoires selon
les ordinateurs, les distributions, etc. Je me suis pris la tete un
nombre incroyable de fois ces derniers temps, maudissant UEFI comme je
maudissais window$ 3.1 il y a plus de vingt ans et la limitation des 640
Ko de M$-DO$.
Comme quoi cette firme malfaisante et ses complices me pourrira la vie
jusqu'au bout. On ne peut meme plus les eviter puisqu'ils infectent
jusqu'au materiel.
> S'il s'agit d'une partition, le format de son contenu doit bien entendu
> permettre d'utiliser son premier secteur comme secteur d'amorce (ce
> n'est pas spécifique à l'installation avec LVM) mais aussi réserver un
> espace utilisable par GRUB pour y installer sa core image. Le format de
> PV LVM peut réserver un tel emplacement, mais la version actuelle de
> GRUB ne sait pas encore l'exploiter.


Ah donc le probleme pourrait venir de la? Il me semblait qu'il n'y avait
plus de notion de secteurs d'amorcage avec UEFI?
> S'il s'agit d'un disque entier (au sens large, incluant SSD, clé USB et
> carte SD) cela dépend du format de la table de partition. Si elle est au
> format DOS/MBR, l'espace non alloué entre le MBR et la première
> partition doit être suffisant pour contenir la core image, ce qui est le
> cas avec l'alignement actuel qui fait commencer la première partition au
> secteur 2048 (1 Mo) mais n'était pas toujours le cas avec l'alignement
> traditionnel sur les cylindres qui faisait commencer la première
> partition au secteur 63 (32 Ko). Si elle est au format GPT, il faut une
> partition non formatée de type "BIOS boot" de taille suffisante.

Je n'avais pas lu cela et ca semble meme contredire ce que j'avais
trouve lors de mes innombrables recherches. Mais ces dernier resultats
se contredisaient egalement, melangeant les versions de Grub. Le Web est
depuis des annees un ramassis de pseudo-tutoriels ecrits par des
amateurs qui croient connaitre leur sujet alors qu'ils ont juste atteint
leur objectif par hasard, et helas un certain nombre d'ecoles
d'informatiques poussent a cette logique.
Pascal si jamais tu te sens de faire une documentation a jour et claire
sur ce sujet, tu auras au moins un lecteur attentif. Je peux meme te
mettre a disposition un bout de wiki.
Daniel Caillibaud (11/03/2019, 13h10)
Le 09/03/19 à 12:51, Frédéric MASSOT <frederic> a
écrit :
> Il faut utiliser les deux, tu assembles tes disques dans un ensemble
> unique RAID avec mdadm, ensuite tu partitionnes cet ensemble unique avec
> LVM.


C'est visiblement ce que tout le monde fait, mais je ne sais pas pourquoi
car lvm sait très bien faire du raid1 (ou raid0) à lui tout seul (man lvm,
cf stripes & mirror).

J'ai utilisé lvm pour gérer le raid pendant des années, et j'ai fini par
faire comme tout le monde ;-)
(par flemme de refaire le partitionnement de machines livrées avec du raid
mdadm)
Pascal Hambourg (11/03/2019, 23h10)
Le 11/03/2019 à 12:01, Daniel Caillibaud a écrit :
> Le 09/03/19 à 12:51, Frédéric MASSOT <frederic> a
> écrit :
>> Il faut utiliser les deux, tu assembles tes disques dans un ensemble
>> unique RAID avec mdadm, ensuite tu partitionnes cet ensemble unique avec
>> LVM.

> C'est visiblement ce que tout le monde fait, mais je ne sais pas pourquoi


Je pense que c'est essentiellement pour des raisons historiques et de
philosophie Unix "une fonction, un outil".
LVM n'a pas toujours su faire du RAID nativement, et mdadm n'a pas
toujours su faire des ensembles RAID partitionnables.

> car lvm sait très bien faire du raid1 (ou raid0) à lui tout seul (man lvm,
> cf stripes & mirror).


Certes, LVM permet de faire du RAID nativement et de façon plus souple
que mdadm, mais est-il aussi robuste et simple à reconstruire que le
RAID de mdadm en cas de défaillance d'un disque ?
Pascal Hambourg (11/03/2019, 23h20)
Le 11/03/2019 à 10:30, Stephane Ascoet a écrit :
> Le 10/03/2019 à 19:04, Pascal Hambourg a écrit :
> Bonjour, je ne peux en dire autant. J'ai des resultats aleatoires selon
> les ordinateurs, les distributions, etc. Je me suis pris la tete un
> nombre incroyable de fois ces derniers temps, maudissant UEFI comme je
> maudissais window$ 3.1 il y a plus de vingt ans et la limitation des 640
> Ko de M$-DO$.


A ma connaissance, l'UEFI n'a aucun impact sur LVM.

>> S'il s'agit d'une partition, le format de son contenu doit bien entendu
>> permettre d'utiliser son premier secteur comme secteur d'amorce (ce
>> n'est pas spécifique à l'installation avec LVM) mais aussi réserver un
>> espace utilisable par GRUB pour y installer sa core image. Le format de
>> PV LVM peut réserver un tel emplacement, mais la version actuelle de
>> GRUB ne sait pas encore l'exploiter.

> Ah donc le probleme pourrait venir de la?


Seulement si on veut installer l'amorce de GRUB dans le secteur d'amorce
d'une partition.

> Il me semblait qu'il n'y avait
> plus de notion de secteurs d'amorcage avec UEFI?


En effet. Et la core image de GRUB EFI est installée en tant que simple
fichier .efi dans la partition système EFI. Beaucoup plus simple, donc
(en théorie).

> Je n'avais pas lu cela et ca semble meme contredire ce que j'avais
> trouve lors de mes innombrables recherches.


Tout ceci ne s'applique qu'à la variante de GRUB pour BIOS/legacy, pas
auxs variantes pour UEFI.

> Pascal si jamais tu te sens de faire une documentation a jour et claire
> sur ce sujet, tu auras au moins un lecteur attentif. Je peux meme te
> mettre a disposition un bout de wiki.


J'ai renoncé à essayer d'écrire de la documentation qui serait à la fois
précise, détaillée, aussi exhaustive que possible en restant
compréhensible et universelle et ne serait pas rapidement périmée. Je me
limite à intervenir sur des cas pratiques.
Jean-Marc (12/03/2019, 08h00)
Mon, 11 Mar 2019 22:07:07 +0100
Pascal Hambourg <pascal> écrivait :

> Certes, LVM permet de faire du RAID nativement et de façon plus souple
> que mdadm, mais est-il aussi robuste et simple à reconstruire que le
> RAID de mdadm en cas de défaillance d'un disque ?


Ce une des questions que je me suis posées.
Note, je pense opter pour un truc simple mdadm et LVM par dessus.

Jean-Marc <jean-marc>
[..]
Stephane Ascoet (12/03/2019, 10h30)
Le 11/03/2019 à 22:19, Pascal Hambourg a écrit :
> A ma connaissance, l'UEFI n'a aucun impact sur LVM.


Bonjour, bien sur, mais j'ai pourtant constate que faire du tout LVM
rajoute aux problemes deja presents avec UEFI et j'ai du me resoudre a
faire une /boot hors LVM dans certains cas pour rendre le systeme
amorcable. Je pense que Grub n'arrive pas dans tous les cas a contourner
tous les chausse-trappes de l'amorcage UEFI.
Discussions similaires
mdadm et nom d'hôte

[RAID_1]-mdadm

HS: mdadm et grub2

mdadm et udev


Fuseau horaire GMT +2. Il est actuellement 09h31. | Privacy Policy