{{tag>debian système_de_fichiers archive}}
== Système de fichier LVM ==
Raison de l'abandon\\
J'ai plusiers fois rencontré des problèmes à l'occasion du remplacement d'un disque (pour finir par devoir recommencer à zéro et restaurer les données). Le système LVM me semble toutefois mature et efficace mais réservé à ceux qui passent leur vie sur Linux alors que ma vie professionnelle est orientée sur un autre système d'exploitation... Si l'on maîtrise LVM, même les groupes de volumes ou les volumes logiques peuvent être restaurés ce qui permet de limiter au maximum le risque d'y laisser des plumes ;-).
====== Késako ? ======
//Logical Volume Manager// (ou //LVM// pour les intimes) permet de regrouper des partitions ou //volumes physiques// (qui peuvent ou non être sur le même disque) dans un //volume logique// ou //groupe de volumes//.
====== Mise en place ======
===== Préparation du système =====
# aptitude install lvm2
Pffft... Purée c'est compliqué... LOL
===== Préparation des disques =====
Le nouveau volume logique dont l'installation est décrite ici va utiliser 2 disques de 3To Western Digital Red « NAS Hard Drive » SATA III WD30EFRX utilisant des secteurs de 4Ko ce qui obligeait à une époque à aligner manuellement le premier secteur logique de chaque partition sur un secteur physique ce qui était loin d'être simple.
==== Partitionnement ====
Sous Debian 7 //« Wheezy »//, LVM n'a pas besoin que les partitions possèdent un système de fichier (c'était peut être possible avant mais c'était méconnu et je suis passé à côté). La seule contrainte dans ce cas étant que les disques ne peuvent être attribués à un volume logique qu'en entier et pas être partagés entre plusieurs volumes logiques. Comme c'est l'objectif ici pas de soucis.
L'avantage de ne pas attribuer de système de fichier aux partitions est de ne pas avoir à prendre le moindre risque quand au choix du type de partition (GPT indispensable pour les disques de plus de 2To alors que LVM requiert théoriquement des partitions au format éponyme dédié).
Donc il suffit d'écrire sur les disque une table de partition :
# fdisk /dev/sdb
{{ archives:info:os:debian:fdisk_3to.jpg |}}
{{ archives:info:os:debian:fdisk_partition_primaire.jpg |}}
Il faut ensuite procéder à la même opération sur le second disque qui va rejoindre le volume logique (///dev/sdc// ici).
==== Initialisation des volumes physiques ====
Pour que LVM puisse utiliser une partition, il faut l'initialiser en tant que volume physique LVM. Puisque qu'ici il n'y a qu'une partition par disque :
# pvcreate /dev/sdb1
Opération a répéter là aussi sur le second disque.
===== Groupe de volumes =====
L'opération est très simple et consiste donc a créer un groupe de volumes en lui attribuant un nom (ici //vgdata//) et en y intégrant un volume physique précédemment initialisé :
# vgcreate vgdata /dev/sdb1
{{ archives:info:os:debian:lvm_vgcreate.jpg |}}
===== Ajout d'espace =====
vgextend vgdata /dev/sdc1
===== Volume logique =====
Il faut commencer par créer le volume logique (//lvdata//) et lui attribuer une partie plus ou moins importante de l'espace disponible dans le groupe de volumes (//vgdata//) :
lvcreate --name lvdata -l 100%FREE vgdata
{{ archives:info:os:debian:lvm_lvcreate.jpg |}}
//lvcreate// propose de nombreuses syntaxes différentes en ce qui concerne la portion de l'espace à allouer...
Puis il faut ensuite formater ce volume, par exemple :
mkfs.ext4 /dev/vgdata/lvdata
====== En cas de corruption ======
===== Symptômes =====
Dans mon cas, le premier symptôme a été un problème d'accès aux partages Samba après un reboot qui cachait tout simplement un problème d'accès au volume logique contenant les données.
J'ai évidement commencé par chercher du côté de Samba puis à force de chercher dans les logs, j'ai trouvé un paquets d'erreurs au niveau du système de fichiers de l'un des disques du volume logique (dans ///var/log/kern.log//) :\\
{{ archives:info:os:debian:lvm_verification_log_kern.jpg |}}
L'étape suivante a été de tenter de forcer une vérification au démarrage avec les commandes suivantes :
# touch /forcefsck
# reboot
N'ayant pas d'écran sur cette machine j'ignore si un éventuel message a donné des indications sur le déroulement (ou plutôt le non-déroulement de l'opération) et la marche à suivre, mais, après le démarrage, le volume logique était à nouveau monté et les partages étaient à nouveau accessibles au bout de 3 ou 4 minutes (curieuse aussi cette latence mais je n'ai pas eu le temps sur le coup de chercher l'explication et je ne l'ai pas trouvée par la suite). Avec le recul, le temps très court du redémarrage aurait dû me mettre la puce à l'oreille ;-)
===== Forcer une vérification complète =====
Il faut d'abord retrouver le nom du (ou des) groupes de volumes (//VG//) et du (ou des) volumes logiques (//LV//) :
# lvm lvs
Ce qui va renvoyer quelque chose comme ceci :
{{ archives:info:os:debian:lvm_verification_lvs.jpg |}}
Comme il va falloir démonter le volume en question, il est préférable d'arrêter les service correspondants (uniquement Samba dans mon cas) :
# /etc/init.d/samba stop
On peut ensuite démonter le volume et lancer la vérification complète (le paramètre de chacune des commandes dépends évidement de ce qu'a retourné la commande //lvm lvs// précédemment) :
umount /dev/vgdata/lvdata
e2fsck -y /dev/vgdata/lvdata
Et le retour très rapide a été le suivant :
{{ archives:info:os:debian:lvm_verification_propre.jpg |}}
Mouais... Mon œil! :-\\\
Donc même si le commutateur //-y// est supposé tenter de détecter et réparer automatiquement toute corruption du système de fichier, il est manifestement insuffisant (et c'est probablement le même genre de vérification que la commande //touch /forcefsck// déclenche). Donc on insiste :\\
e2fsck -yfv /dev/vgdata/lvdata
Les commutateurs utilisés :
* y : est donc supposé tenter de détecter et réparer automatiquement toute corruption du système de fichier
* f : force une vérification approfondie même si le système semble propre
* v : force le mode verbeux afin d'obtenir un maximum d'infos en retour
On peut aussi ajouter le commutateur //c// pour forcer une vérification de chaque secteur mais c'est extrêmement long.
Et voici le résultat obtenu, cette fois après un long moment :
{{ archives:info:os:debian:lvm_verification_resultat_e2fsck.jpg |}}
Le mode verbeux n'est pas si causant que çà, il y avait vraiment un paquet d'erreurs dans le log. Qu'a cela ne tienne...\\
reboot
Bingo ! Les partages Samba sont instantanément dispos et surtout, plus aucune erreur dans le log. 8-)
Seule chose qui me chagrine : rien dans //lost+found// et à priori pas de données perdues si je compare aux sauvegardes (ou aux dossiers d'origine selon les cas). 8-O
Voir ci-dessous pour la suite des aventures de ce disque (bon ça ne fait jamais plaisir mais au moins il y a une certaine logique :-\).
===== Et paf ! le disque =====
Donc au premier reboot après la "réparation" tout semblait nickel, sauf que les erreurs sont revenues au reboot suivant m(.
Il faut donc vite passer au remplacement du disque tant qu'il marche encore sur 3 pattes...
Donc pour faire fonctionner le disque (même partiellement) donc j'ai réutilisé ces commandes:
# touch /forcefsck
# reboot
Quand on a plusieurs disques identiques et qu'il faut en identifier un, il faut récupérer son numéro de série :
# smartctl -i /dev/sdb
{{ archives:info:os:debian:smartctl_serial.jpg |}}
Pour avoir accès à la commande //smartctl//, il faudra que le paquet //smartmontools// soit installé.
Et il faut aussi connaître le nom du volume logique :
# lvm lvs
{{ archives:info:os:debian:lvm_verification_lvs_vg.jpg |}}
J'ai donc ensuite ajouté mon disque (à chaud dans mon cas) et vérifié qu'il était bien détecté par le système en jetant simplement un œil au contenu de ///dev// (il faut évidement avoir une idée de son contenu ou avoir pensé à regarder avant :-P).
Il ne reste plus qu'à préparer le disque pour l'utilisation avec LVM, à l'ajouter au volume logique et y déplacer les données contenues sur le disque défectueux et voici le scénario :
# pvcreate /dev/sdd
# vgextend vgdata /dev/sdd
# pvmove /dev/sdb /dev/sdd
# vgreduce vgdata /dev/sdb
# pvremove /dev/sdb
Sauf que ça coince dès la commande //vgextend// :
{{ archives:info:os:debian:lvm_vgextend_missing.jpg |}}
Le but étant de récupérer ce qui est à récupérer sur le disque en question, il faut creuser la question en regardant l'état des volumes physiques :
# pvs
{{ archives:info:os:debian:lvm_verification_pvs.jpg |}}
C'est l'attribut //m// (pour //missing// qui coince)...
Il est théoriquement possible de réinitialiser cet attribut avec cette commande :
# vgextend --restoremissing vgdata /dev/sdb1
{{ archives:info:os:debian:lvm_vgextend_restoremissing.jpg |}}
Bon ben voilà... La messe est dite pour ce disque :-(. Malgré mes recherches, je n'ai pas trouvé comment passer outre donc il est temps de retirer le disque du volume logique :
# vgreduce --removemissing vgdata
{{ archives:info:os:debian:lvm_vgreduce_removemissing.jpg |}}
Pas le choix, il faut utiliser le commutatuer //--force// pour retirer ce fichu disque:
# vgreduce --removemissing vgdata --force
{{ archives:info:os:debian:lvm_vgreduce_removemissing_force.jpg |}}
Comment ça « //Logical volume "lvdata" successfully removed// » ?! :-X
Bon ben voilà, ça c'est fait, y'a plus qu'à recréer un volume logique tout neuf et restaurer les données. :-(
Braves gens ! Notre enchanteur m’informe, que d’habitude il y arrive très bien mais que là, visiblement, ça marche pas !
Kaamelott ([[http://kaamelott.co/livre-2/linvincible/|Livre II - L'Invincible]])
Ce fameux volume logique dont la fin funeste est décrite [[archives:info:os:debian:lvm#En cas de corruption|ci-dessus]] utilisait 2 disques de 3To chacun, or, pour utiliser une partition de plus de 2To, il faut une partition de type GPT qui n'est pas géré par l'outil intégré à Debian //fdisk//. Par ailleurs l'alignement des partitions sur ces disques utilisant des secteurs de 4Ko était très délicat et j'ai fait le choix de passer outre. Il est possible que la combinaison GPT/LVM ou le mauvais alignement des partition soit responsable de la suppression non désirée du volume logique... Espérons en tout cas...