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.

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.

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.

Donc il suffit d'écrire sur les disque une table de partition :

# fdisk /dev/sdb

Il faut ensuite procéder à la même opération sur le second disque qui va rejoindre le volume logique (/dev/sdc ici).

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.

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

vgextend vgdata /dev/sdc1

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

Puis il faut ensuite formater ce volume, par exemple :

mkfs.ext4 /dev/vgdata/lvdata

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) :
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

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 :

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 : 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

Et voici le résultat obtenu, cette fois après un long moment : 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.

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). 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 ).

Donc au premier reboot après la “réparation” tout semblait nickel, sauf que les erreurs sont revenues au reboot suivant .

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

Et il faut aussi connaître le nom du volume logique :

# lvm lvs

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 ).

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 :

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

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

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

Pas le choix, il faut utiliser le commutatuer –force pour retirer ce fichu disque:

# vgreduce --removemissing vgdata --force

Comment ça « Logical volume “lvdata” successfully removed » ?!

Bon ben voilà, ça c'est fait, y'a plus qu'à recréer un volume logique tout neuf et restaurer les données. <blockquote>Braves gens ! Notre enchanteur m’informe, que d’habitude il y arrive très bien mais que là, visiblement, ça marche pas ! <cite>Kaamelott (Livre II - L'Invincible)</cite> </blockquote>