[Partitions] Migrer vers LVM avec RAID (Résolu)

[Xorg]

Salutations la communauté,

J'envisage sérieusement de faire un nettoyage en profondeur de ma machine (aussi bien au niveau matériel que logiciel ), et niveau software, je pense directement me lancer dans une réinstallation, car j'envisage de faire de gros changements dans mon partitionnement.

En effet, actuellement, ma machine contient :
- 1 SSD de 120Go (/dev/sda)
- 2 HDD de 500Go chacun (/dev/sd{b,c})

Voici la sortie (tronquée) d'un fdisk -l :

Code : Tout sélectionner

Périphérique  Début       Fin  Secteurs Taille Type
/dev/sda1       2048   1050623   1048576   512M Système EFI					# ESP (monté sur [i]/boot/efi[/i])
/dev/sda2    1050624 234440703 233390080 111,3G Système de fichiers Linux	# Root (monté sur [i]/[/i])

/dev/sdb1         2048   2099199   2097152     1G Partition d'échange Linux	# /dev/md1 (RAID 0), Swap
/dev/sdb2      2099200  23070719  20971520    10G Système de fichiers Linux	# /dev/md0 (RAID 0), Var, (monté sur [i]/var[/i])
/dev/sdb3     23070720 128235519 105164800  50,2G Système de fichiers Linux	# /dev/md3 (RAID 0), VMs, (monté sur [i]$HOME/.VirtualBox[/i])
/dev/sdb6    128235520 976773134 848537615 404,6G Système de fichiers Linux	# /dev/md2 (RAID 1), Home, (monté sur [i]/home[/i])

/dev/sdc1         2048   2099199   2097152     1G Partition d'échange Linux	# /dev/md1 (RAID 0), Swap
/dev/sdc2      2099200  23070719  20971520    10G Système de fichiers Linux	# /dev/md0 (RAID 0), Var, (monté sur [i]/var[/i])
/dev/sdc3     23070720 128235519 105164800  50,2G Système de fichiers Linux	# /dev/md3 (RAID 0), VMs, (monté sur [i]$HOME/.VirtualBox[/i])
/dev/sdc6    128235520 976773134 848537615 404,6G Système de fichiers Linux	# /dev/md2 (RAID 1), Home, (monté sur [i]/home[/i])

L’occupation des disques étant la suivante :

Code : Tout sélectionner

/dev/sda1          536M    520M   17M  98% /boot/efi
/dev/sda2          118G     66G   35G  66% /
/dev/md0            21G    5,6G   14G  30% /var
/dev/md2           428G    261G  163G  62% /home
/dev/md3           106G     79G   28G  75% $HOME/.VirtualBox

Au niveau du SSD, je ne pense pas modifier l'ESP car il a une taille suffisante. Ou alors je vais peut-être l'agrandir un peu (j'ai des choses utiles mais grosses dedans).
Pour ma partition système, je pensais migrer de Ext4 à F2FS (on peut le considérer comme stable avec un noyau récent), car le F2FS est conçu pour les périphériques à mémoire NAND à la base.

Au niveau des mes HDD, je trouve mon partitionnement mal équilibré, c'est pour cela que je voulais repartir de zéro :
- pas assez de swap pour hiberner (j'ai foiré visiblement le jour où j'ai partitionné, vu qu'à l'époque j'avais 4Go de swap )
- une partition pour le /var trop grande, vu que nettoyer le cache de Pacman, ça aide facilement à libérer l'espace inutilement occupé
- une partition pour mes machines virtuelles (je suis obligé de les mettre sur mes HDD car ça ne rentrerait pas tout sur mon SSD) trop petite aussi, j'ai souvent besoin de nettoyer l'espace disque libre des VMs pour pouvoir compacter les disques virtuels après (ils ont tous une taille dynamique).


Alors, pour cette histoire de disques durs, j'avais au début pensé à me mettre au Btrfs, mais j'ai lu à beaucoup d'endroits différents qu'il arrive de perdre des données. Ne voulant pas perdre certaines données personnelles, le Btrfs m'effraye un peu, d'autant plus qu'il n'est toujours pas considéré comme stable, je préfère donc éviter cette solution.
Du coup, je pense plutôt me tourner vers le LVM, mais j'avoue que je ne connais rien au LVM. L'idée serait que mes deux disques durs utilisent LVM (enfin, est-ce vraiment utile pour la partition de swap ?), mais tout en conservant mes RAIDs (je désire vraiment que mes données personnelles soient sur un RAID 1).

Qu'en pensez-vous ? Est-ce réalisable ? Si oui, est-ce qu'une baisse de performance sera possible ? Et si oui, est-ce qu'en cas de défaillance d'un de mes disques durs je pourrai facilement récupérer mon RAID 1 ?

Merci d'avance.

EDIT : J'ai trouvé la page Software_RAID_and_LVM, mais est-ce que ça veut dire qu'il faut d'abord créer un RAID puis ensuite créer le LVM ? Je n'ai pas envie de mal m'y prendre.

[benjarobin]

Bonjour,
Je trouvais que ton ESP un peu gros, 300Mo c'est déjà très confortable, qu'est ce que tu met dedans pour qu'il soit plein si ce n'est pas indiscret ?
Si j'ai bien compris tu as fais 4 RAID 1 indépendant, c'est une façon de voir les choses, personnellement je préfère faire un unique RAID et le redécouper ensuite.
Si tu veux faire du LVM, ce qui te permettra de redimensionner les partitions à la volé, je te conseil de faire un RAID 1 sur l'intégralité du disque dur et de rajouter par dessus LVM.
Si tout est parfaitement aligné sur les secteurs de disque dur, alors tu n'aura aucune perte de performance sans LVM et avec on va dire que c'est négligeable.

Sinon comme tu donnes la sortie avec fdisk, c'est bien tout en GPT (je sais que fdisk supporte maintenant le GPT, mais c'est juste pour être sure) ?

[Xorg]

En effet, 100Mo pour un ESP c'est tout à fait raisonnable pour un usage basique. Mais en plus d'avoir ce qu'il me faut pour booter ma Arch en EFI, j'ai aussi de quoi me dépanner (rEFInd en tant que shellx64.efi à la racine de l'ESP, qui me permet par exemple de booter sur MemTest86, ou bien sur ArchBoot). ArchBoot a elle seule prend 406Mo, mais c'est une vieille version, sauf que ça me dépanne bien de l'avoir sous la main des fois.

Non, ce n'est pas 4 RAID 1 mais 3 RAID 0 et 1 RAID 1. J'ai juste besoin d'un RAID 1 pour les données sensibles, après vu que le reste je m'en fiche un peu, c'est pour cela que j'y mets sur un RAID 0.
Mais ça vaut dire que si je fais un RAID 1 (avec mes données dessus) et un RAID 0 (avec tout le reste dessus), il n'y aura qu'au niveau du RAID 0 où je pourrai découper de façon à avoir 3 partitions (une pour le Swap, une pour le /var et une pour mes VMs) ?
Parce que si je comprends bien, le LVM vient s'ajouter par dessus le RAID logiciel, et donc redimensionner à la volé mon RAID 1 ne sera pas possible, c'est ça ?

Oui, mes trois disques sont tous en GPT.

[benjarobin]

Je ne pense pas que ce soit possible de redimensionner un RAID à la volé. Quand j'ai voulu agrandir mon RAID (un gros RAID certes) il a fallu quelques heures...
Et surtout mettre le RAID au dessus d'un LVM, si c'est possible, tu perds toute la sécurité du RAID, car si un disque lâche, tu perds tout, car impossible de reconstruire le LVM, donc impossible de récupérer le RAID 1...
Bref, oui, tu as tout compris, tu sera bien obligé de figer la taille de la zone du RAID 1...

Sinon désolé, un peu HS, mais je serais curieux que tu détails comment tu fais pour démarrer MemTest86 ou ArchBoot depuis rEFInd, je ne savais pas que c’était possible pour MemTest86

[Xorg]

Ok, je comprends...

Admettons que je fasse quand même un RAID 1 (de taille fixée, sur lequel je mettrai directement mon Home comme c'est déjà le cas) et un RAID 0, le fait d'avoir du LVM sur mon RAID 0 me permettrait donc de redimensionner à la volé les volumes logiques présent dessus. Mais je ne comprends pas trop : les volumes logiques (LV), est-ce qu'ils ont une tout de même une taille définie ? Je suppose que oui, vu qu'on peut agrandir et réduire la taille de la partition à la volé. Dans ce cas là, ça veut dire qu'il faut laisser un espace non alloué dans le groupe (VG) ?

[benjarobin]

Si j'ai bien compris le principe de LVM oui... Il y a des personnes ici qui utilise LVM, ils t'en parlerons mieux que moi, personnellement je ne suis pas très fan de ce genre de solution (je n'ai jamais eu besoin de redimensionner à la volé quoi que ce soit)

[Xorg]

Encore faudrait-il qu'ils pointent le bout de leur nez.
J'ai renommé le topic, c'est vrai que l'ancien titre était peu parlant (il y aura bien une réinstallation de faite, mais c'est bon ça, je sais comment m'y prendre pour y faire proprement ).
Mais je suis d'accord, j'ai toujours pensé la même chose que toi pour le LVM, et que c'était une surcouche compliquée en plus. Mais finalement, là je vois les avantages que je pourrai en tirer, et tout à coup ça m'intéresse plus.

Bref, on farfouillant sur Internet, j'ai trouvé quelque chose d'intéressant, en particulier sur la documentation de Gentoo, ici (je ne pointe pas directement la page française car la traduction n'est que partielle). Alors comme ça LVM supporterait nativement le RAID... Ça ne m'étonne pas vraiment, je trouvais que les groupes de volumes (VG) ressemblaient fortement à un JBOD.

Si je pige bien tout, avec ça, je pourrai créer un gros groupe de volumes (avec /dev/sd[bc]1), puis sur ce groupe-là je pourrai créer mes 4 RAIDs (3 RAID 0, 1 RAID 1) ?

[benjarobin]

Je ne maîtrise pas du vraiment le sujet, donc je ne te serais pas d'une aide précieuse. Par contre si tu as du temps, après avoir sauvegardé tes données, tu peux faire des tests : débrancher un disque dur et voir comment le système se comporte et si tu peux récupérer tes données

[Xorg]

J'avais envisagé cette idée. Ça peut me prendre du temps, mais je suppose que ça en vaudra la chandelle.
Je vu qu'on pouvait tester avec des périphériques de type loop, mais tant qu'à essayer, autant tester dans de vraies conditions.

[oktoberfest]

Je vais parler un peu de LVM, vu que je n'utilise que ça (même si ce n'est pas forcément utile chez moi).
Dans un premier temps, oui il vaut mieux utiliser LVM par dessus le RAID 1, tu auras la sécurité du RAID1 pour la perte des disques, et la souplesse du LVM pour le partitionnement.
Ensuite le principe de base, une fois que tu as créé ton vg, est de ne pas l'allouer entièrement à tes différents LVs. Sinon tu te retrouves avec les mêmes problèmes qu'avec des partitions classiques.

De plus (benjarobin ne l'a pas dit ici, mais il l'a déjà maintes fois répété), les SSD ne sont pas en sucres, et tu ne risques pas de l'user prématurément même en mettant ton /var et ton /home dessus (cf : http://www.tomshardware.fr/articles/ssd ... 53682.html, la conclusion c'est que même en écrivant 20 Go par jour, les SSD testés aurait duré 100 ans...)

Pour conclure, je vais prendre un exemple qui te servira de base :
- tu crées un vg (sur ton SSD, donc 120 Go)
- tu créés les lvs pour tes points de montage (10 Go pour /, 4 Go pour /var, 20 Go pour /home, 4 Go pour le swap).
- il te reste donc 82 Go de dispo sur ton vg.

Une fois qu'un de tes filesystems est presque plein, tu augmentes le LV correspondant (+ le filesystem par après). Et si par hasard tu te trompes et que tu agrandis trop tu peux toujours réduire (cela se fait avec le filesystem démonté, il faut que le filesystem supporte la réduction et tu te dois pas te tromper dans les commandes). Tu peux aussi agrandir ton LV de swap si tu augmentes ta mémoire, pour être tranquille pour l'hibernation.

EDIT : Après avoir bien lu le topic je peux ajouter d'autre précisions :

Un volume LVM peut agréger plusieurs volumes physiques (i.e partitions ou disques entiers). Si tu as un VG contenant plusieurs PV, tu peux choisir comment tu crées ton LV :
- sans option particulière (le gestionnaire de LVM va allouer la place sur le premier PV, si ça ne suffit pas le reste ira sur le PV suivant, etc ) --> JBOD
- en miroir sur 2, 3, ... PV --> RAID 1
- en mode stripé sur 2, 3, ... PV --> RAID 0

Personnellement je n'utilise jamais cela si ce n'est dans un cas : pour déplacer un LV d'un PV vers un autre. Je fais un miroir d'un LV existant puis je casse le miroir. Mais je trouve plus simple d'avoir d'abord une couche RAID pour gérer la sécurité/performance des données (via un RAID x, avec le x de ton choix) et par dessus un LVM pour gérer la souplesse de gestion des tailles de LV.

Dans ton cas, si tu mets tes deux HD en RAID 1, tu auras donc deux PVs :
- un pour ton SSD
- un pour ton RAID 1

Tu as ensuite le choix entre faire un VG par PV, ou faire un VG avec les deux PVs dedans. Les différences seront :
- avec deux VGs : chaque LV sera soit sur le SSD, soit sur le RAID1. Tu sais donc parfaitement sur quels medium physique se trouve un filesystem. Par contre si tu remplis un PV, il te faut déplacer des données ou autre artifice pour gérer cela.
- avec un VG : tu ne te poses plus de question, par contre si tu perds ton SSD, tu perds ton VG. De plus lors de la création d'un LV, tu dois explicitement dire où le créer sinon c'est la gestionnaire de LVM qui va décider de l'allocation.
--> Je trouve le choix avec deux VG plus simple à gérer.

[Xorg]

Super oktoberfest, voilà le genre de réponse qu'on attendait.

J'avais lu effectivement le même test sur Tom's Hardware, et c'est vrai que je ne gagne pas grand chose à mettre mon /var sur mes disques durs. Je pense effectivement que je vais rapatrier mon /var sur mon SSD, inutile d'avoir une partition dédiée du coup pour lui. Mais c'est vrai que vu que j'avais lu ça à l'époque sur le wiki, c'est pour ça que je l'avais fait.
Par contre, que penses-tu du swap sur le SSD ? Parce que quand ça swap chez moi, ça se ressent vite.

Mais je ne suis pas intéressé par le LVM sur mon SSD car sur mon SSD je voulais juste avoir mon ESP et mon système, donc ça pour la taille des partitions ça sera vite vu.
Il n'y a que sur mes disques durs que le LVM m'intéresse en fin de compte.
Par rapport à ton exemple, bien que ça ne soit qu'un exemple, entre déjà ma partition système avec à peu près 60Go de données dessus et 250Go de données dans mon Home, ça ne peut déjà pas tout rentrer sur mon SSD de 120Go, d'où pourquoi j'ai deux disques durs à côté.

En tout cas merci beaucoup pour les explications sur les PV, les VG et les LV. Ça me paraît peu sécurisant d'avoir un unique VG qui serait étalé sur la totalité des disques.
Mais ça me donne des idées, par exemple ça m'intéresse bien d'avoir ceci :
- Pas de LVM sur le SSD : ESP et Root uniquement
- LVM total sur les deux HDD, avec un seul VG créé à partir de deux PV (/dev/sd[bc]1) : un LV en RAID 0 pour le swap, un autre LV aussi en RAID 0 pour mes VMs, et enfin un LV en RAID 1 pour le Home.

Par rapport à ce que tu dis sur le RAID et le LVM, visiblement les modes stripé et miroir de LVM ne valent pas un RAID, mais il y a bel et bien (c'est certainement plus récent comme implémentation) un vrai mode RAID :

Code : Tout sélectionner

lvcreate -m 1 --mirrorlog mirror -l 40%VG --nosync -n lvol1 vg0
lvcreate -m 1 --type raid1 -l 40%VG --nosync -n lvm_raid1 vg0

C'est ça que j'ai envie d'essayer, car si j'utilise directement un RAID logiciel, ça me ferra perde la souplesse du LVM (genre je ne pourrai pas redimensionner le LV qui sera sur mon RAID 1, vu qu'en théorie j'aurais qu'un seul PV (le RAID 1) avec un unique VG dessus qui contiendra qu'un seul LV).

Merci beaucoup pour ton aide.

[oktoberfest]

Après un peu de lecture, effectivement il existe de nouveaux types pour la création de LV, dont les fameux raidX. Il semble que cela soit une nouvelle implémentation (pour raid1) du mode miroir, plus efficace, plus simple à maintenir et à priori inspiré de (ou utilisant) md.

Pour le swap, je ne sais pas trop quoi dire. Je ne swappe quasiment jamais vu mon utilisation (pas de grosse utilisation mémoire). Ce sera de toute façon un compromis entre "user prématurément ton ssd" (je mets les guillemets car je ne sais toujours pas si c'est dangereux ou pas) et un swap moins réactif parce que sur un disque dur.

Bonne idée d'utiliser un seul vg et y mettant tes 2 disques. Ensuite c'est à la création des LV que tu spécifies soit le type raid1, soit le type striped. Maintenant un test intéressant (que je n'ai jamais fait, n'ayant qu'un seul PV), c'est de voir comment réagit ton VG si tu débranches un de tes deux PVs. En théorie, tes LV en raid1 devraient toujours être accesible, les LV en striped seront foutus. Si tu peux faire un essai et nous dire ce qu'il en est, ça m'intéresse (et d'autres aussi j'espère)

[Xorg]

Re.

Bon alors, j'ai opté pour cette configuration :
- SSD : 1Gio (FAT32) pour l'ESP, 107Gio (F2FS) pour le système et 4Gio pour le swap.
- HDDs (2 PV, avec un VG contenant 2 LV) : premier LV de 100Gio (Ext4) en LVM RAID 0 pour mes VMs, et second LV de 300Gio (Ext4) en LVM RAID 1 pour mes données.

Le fait de débrancher un HDD pour simuler une panne avant le boot donne ceci :

Code : Tout sélectionner

 LV Status              NOT available

Le VG est donc "cassé", les LV ne sont pas accessibles, y compris le RAID 1.
En revanche, la commande magique vgchange -ay --partial vg0 permet de marquer le VG en tant que dégradé, et après cela, il est possible de monter le RAID 1.
Les tests que j'ai fait consistaient, en mode dégradé, à créer des fichiers et répertoires sur le premier HDD. J'ai rebooté puis j'ai rebranché le second HDD, et j'ai vu au boot qu'après le scan des PVs, une synchronisation (très rapide) s'est faite, puis le VG fonctionnait normalement, et le fichier créé était toujours là.
Même expérience avec le second disque dur (en débranchant le premier, donc), et même résultat.

Bien que je n'aie pas fait le test sur un échantillon très représentatif de la réalité, je suis content de voir que je peux accéder à mes données même si un de mes HDD lâche.

Enfin, j'ai donc testé le swap sur le SSD. Pas très dur, j'ai lancé 4 VMs en même temps pour voir à quel point ça se ressentait ; verdict, on sent bien que la machine perd un peu en réactivité, mais c'est beaucoup plus réactif que de swapper sur un HDD (je pouvais passer d'une fenêtre à l'autre en environ une seconde).

J'ai une dernière question sur le LVM :

Code : Tout sélectionner

Disque /dev/mapper/vg0-Donnees_rmeta_0 : 4 MiB, 4194304 octets, 8192 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets


Disque /dev/mapper/vg0-Donnees_rimage_0 : 300 GiB, 322122547200 octets, 629145600 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets


Disque /dev/mapper/vg0-Donnees_rmeta_1 : 4 MiB, 4194304 octets, 8192 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets


Disque /dev/mapper/vg0-Donnees_rimage_1 : 300 GiB, 322122547200 octets, 629145600 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets


Disque /dev/mapper/vg0-Donnees : 300 GiB, 322122547200 octets, 629145600 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets

C'est quoi ces rmeta et rimage ? Pourquoi deux d'entre eux sont-ils de 4 MiB ?

[benjarobin]

De ce que je comprend c'est ton RAID 1 dans le LVM (les données meta du RAID sur 4 Mo et les données). Voir http://unix.stackexchange.com/a/182503
En tout cas tes tests sont très intéressant

[Xorg]

D'accord. C'est un peu plus farfelu qu'un simple RAID 1 avec mdadm mais du moment que ça fonctionne correctement, ça ira.

Intéressant pour ton lien. C'est pas très vieux (ça date de février) mais c'était sur une Debian Wheezy si j'ai bien compris (c'est déjà plus vieux en terme de version des logiciels ), donc je ne sais pas si les points qu'il a cité ont été corrigés depuis. Enfin, lvextend ça fonctionne avec une version assez récente d'après lui, ça me rassure.

Je viens de tester la commande lvs :

Code : Tout sélectionner

  LV      VG   Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  Donnees vg0  Rwi-aor--- 300,00g                                    100,00          
  VMs     vg0  -wi-ao---- 100,00g 

Sinon pour le F2FS, vu que je n'ai pas pensé à effectuer un benchmark quand j’utilisais encore de l'Ext4, je n'ai donc pas de point de comparaison, mais voici quelques résultats tirés de Gnome Disks :

• 521Mo/s en lecture avec 100 échantillons de 100Mio
• 436Mo/s en lecture avec 1000 échantillons de 10Mio
• 350Mo/s en lecture avec 1000 échantillons de 1Mio

Je suis un peu surpris par le fsck du F2FS, je vois beaucoup de lignes apparaître au démarrage juste pour lui, mais j'ai testé manuellement et c'est son comportement normal. J'ai suivi les insctructions sur la page Silent_boot, mais en contre-partie je ne vois pas au boot quand des fsck sont réellement exécutés.

Je pense que je peux mettre le sujet en résolu. Merci beaucoup pour votre aide.