[LVM] Supprimer un volume physique (Résolu)

[aquemy]

Bonjour à tous,

Je souhaiterais entreprendre une petite opération de maintenance pour mon serveur et j'ai besoin de votre aide parce que je ne sais pas comment faire pour ne pas avoir de perte de données.
Après diagnostique, j'ai un disque dur de 1To qui ne va pas tarder à lacher, et avec dessus la partition de boot (mais ce n'est pas grave, je ferai une réinstallation du système).

Mon problème est que en plus de la partition de boot, se trouve une partition utilisée par un VG.
Voici quelques résultats pour comprendre l'architecture du bazar :

Code : Tout sélectionner

srv# pvs
  PV         VG     Fmt  Attr PSize   PFree
  /dev/md0   Save   lvm2 a--  186,18g    0   # Raid pour la sauvegarde (utilisé par le VG Save)
  /dev/sdb2  Server lvm2 a--  929,51g    0   # Disque 1To, utilisé par Server
  /dev/sdd1  Server lvm2 a--    1,82t    0   # 2To utilisé par Server
srv# vgs
  VG     #PV #LV #SN Attr   VSize   VFree
  Save     1   1   0 wz--n- 186,18g    0 
  Server   2   4   0 wz--n-   2,73t    0 
srv# lvs
  LV     VG     Attr      LSize   Pool Origin Data%  Move Log Copy%  Convert
  lvsave Save   -wi-ao--- 186,18g                                           
  lvhome Server -wi-ao---   2,70t                                           
  lvroot Server -wi-ao---  15,00g                                           
  lvswap Server -wc-ao---   2,00g                                           
  lvvar  Server -wi-ao---  15,00g

Ce qui m'importe serait de garder lvsave mais, là pas de soucis, tout est en raid sur des DD qui vont bien.
Il faudrait également que je garder lvhome qui monte sur /home.

lvhome occupe l'ensemble de la place restant sur le le VG Server après attribution de lvroot, lvswap et lvvar. Les données doivent donc se trouver à la fois sur le premier disque et le second. Mon objectif est de tout mettre sur le second de 2To pour pouvoir retirer /dev/sdb2.

Pour information, sur les 2.7To de lvhome, il n'y a que 26% utilisé donc assez pour tout mettre sur /dev/sdd1.

Jusqu'à présent j'ai tenté un pvmove /dev/sdb2 /dev/sdd1 mais j'obtiens ceci :

Code : Tout sélectionner

No free extents on physical volume "/dev/sdd1"
No specified PVs have space available

La question est peut-être bête et je n'ai pas tenté grand chose mais afin d'éviter de faire une fausse manip' et de perdre pas mal de données, j'ai préféré poster ici d'abord.

[oktoberfest]

Salut,

que lvhome soit vide ou plein n'a aucune importance. Il fait 2.7 To point. Donc tu ne peux pas sortir /dev/sdb2 car tu n'as pas de place libre pour déplacer les extents qui s'y trouvent.

Je pense que tu as eu (comme d'autres ici) le mauvais réflexe de créer des lvs pour remplir dès le début ton vg. Tout l'intérêt de LVM est de construire des LV petits et de les agrandir au fur et à mesure des besoins.

Tu vas donc devoir faire l'inverse : réduire lvhome.
1 - tu montes lvhome et tu fais un 'df -h' pour regarder l'espace utilisé.
2 - tu démontes lvhome et tu réduis le filesystem (pour ext3 : resize2fs <nouvelle taille>). Ici tu ne risques rien la commande t'empêchera de trop réduire le filesystem.
3 - tu réduis lvhome. Tu dois indiquer une taille légèrement supérieure à la taille du filesystem (si tu mets trop petit, tu tronques ton filesystem.... et adieu les données !)
4 - tu agrandis le filesytem dans lvhome pour qu'il occupe toute la place de lvhome.

A partir de là tu devrais avoir de la place pour faire le pvmove.

Donc :
- quel est le filesystem de lvhome ?
- que donne un 'df -h', qu'on sache la taille utilisée ?

[aquemy]

Merci de ta réponse rapide.

Pour le filesystem :

Code : Tout sélectionner

srv# file -s -L /dev/mapper/Server-lvhome 
/dev/mapper/Server-lvhome: Linux rev 1.0 ext4 filesystem data

Et pour la taille :

Code : Tout sélectionner

srv# df -h /dev/mapper/Server-lvhome 
Sys. de fichiers          Taille Utilisé Dispo Uti% Monté sur
/dev/mapper/Server-lvhome   2,7T    654G  1,9T  26% /home

Je teste de suite la manip' et je reviens au rapport.

[oktoberfest]

Fais bien gaffe quand tu redimensionnes le pv !
Un truc est de faire (dans ton cas) :
- redimensionner le filesystem à 670 Go
- redimensionner lvhome à 700 Go
- redimensionner le filesystem

[aquemy]

En fait j'ai un petit soucis.
Je peux bien démonter lvhome mais si je ne fais que ça j'obtiens :

Code : Tout sélectionner

srv#  resize2fs /dev/sdd1 670Go
resize2fs 1.42.7 (21-Jan-2013)
resize2fs: Périphérique ou ressource occupé lors de la tentative d'ouverture de /dev/sdd1
Impossible de trouver un superbloc de système de fichiers valide.

Surement à cause des autres volumes sauf qu'en essayant de démonter lvvar :

Code : Tout sélectionner

srv# umount /dev/mapper/Server-lvvar 
umount: /var : cible occupée.
       (Dans certains cas, des renseignements sur les processus utilisant
        le périphérique sont accessibles avec lsof(8) ou fuser(1))
rlmsrv# lsof /dev/mapper/Server-lvvar 
COMMAND   PID USER   FD   TYPE DEVICE   SIZE/OFF   NODE NAME
systemd-j 190 root  mem    REG  253,1   31080448 524291 /var/log/journal/3252b1687f5f42d4b185f124dd12829d/system.journal
systemd-j 190 root   13u   REG  253,1   31080448 524291 /var/log/journal/3252b1687f5f42d4b185f124dd12829d/system.journal
wicd      405 root    3w   REG  253,1       9308 262199 /var/log/wicd/wicd.log
syslog-ng 406 root  mem    REG  253,1      16384 131086 /var/lib/syslog-ng/syslog-ng.persist
syslog-ng 406 root    5u   REG  253,1      16384 131086 /var/lib/syslog-ng/syslog-ng.persist
syslog-ng 406 root   13w   REG  253,1 2019523429 262191 /var/log/kernel.log
syslog-ng 406 root   14w   REG  253,1 1255198985 262169 /var/log/messages.log
syslog-ng 406 root   15w   REG  253,1 2164065475 262195 /var/log/everything.log

[oktoberfest]

ce n'est pas /dev/sdd1 qu'il faut redimensionner mais /dev/Server/lvhome. /dev/sdd1 est ton PV, /dev/Server/lvhome est ton LV.

/var n'a rien à voir dans l'histoire, laisse-le tranquille

[aquemy]

Effectivement. Mékejchuikon.

Impeccable pour le filesystem.

Code : Tout sélectionner

srv# resize2fs /dev/mapper/Server-lvhome 670G
resize2fs 1.42.7 (21-Jan-2013)
En train de redimensionner le système de fichiers sur /dev/mapper/Server-lvhome à 175636480 (4k) blocs.
Le système de fichiers /dev/mapper/Server-lvhome a maintenant une taille de 175636480 blocs.

Par contre pour le LV :

Code : Tout sélectionner

srv# lvreduce -L 700G /dev/mapper/Server-lvhome 
  WARNING: Reducing active logical volume to 700,00 GiB
  THIS MAY DESTROY YOUR DATA (filesystem etc.)
Do you really want to reduce lvhome? [y/n]: y
  Command failed with status code 5.

Une idée ?

[oktoberfest]

Est-ce que ta racine est en lecture seule ? Cela pourrait expliquer le message.

[aquemy]

La racine du système ? C'est lvroot et je ne pense pas non.
La racine de lvhome ? Je ne pense pas non plus. Comment puis-je le savoir ?

[oktoberfest]

La racine = /

$ grep ' / ' /proc/mounts

[aquemy]

Code : Tout sélectionner

srv# grep ' / ' /proc/mounts 
rootfs / rootfs rw 0 0
/dev/mapper/Server-lvroot / ext4 ro,relatime,data=ordered 0 0

[oktoberfest]

/dev/mapper/Server-lvroot / ext4 ro,relatime,data=ordered 0 0

Elle est bien montée en lecture seule. Donc :

Code : Tout sélectionner

# mount -o rw,remount /
# Et maintenant tu  peux redimensionner

Elle est en lecture seule car, au choix :
- tu l'as remonté avec l'option ro
- tu as l'option ro dans /etc/fstab

EDIT : je n'ai pas dit que c'était mal d'avoir la racine en lecture seule (c'est ce que j'ai chez moi). Il faut simplement penser à la mettre en rw quand tu modifies le système (LVM, mise à jour de fichier de config dans /etc, mis à jour du système via pacman...)

[aquemy]

Parfait !
Juste pour être sur, pour l'étape " tu agrandis le filesytem dans lvhome pour qu'il occupe toute la place de lvhome ", je fais un bête resize2fs /dev/mapper/Server-lvhome 700G ?

(Et pour la culture, quel est l'avantage / désavantage d'une racine montée en lecture seule ?)

[oktoberfest]

Oui tu fais un bête resize, sans spécifier la taille.

L'avantage du montage en lecture seule, c'est :
- si ton pc plante brutalement, tu n'auras pas de problème de partition (éventuellement) corrompue au prochain démarrage.
- il n'y a pas de risque d'une modification intempestive du système.

Inconvénients :
- comme moi, tu vas modifier un jour un fichier dans /etc et à la sauvegarde on va te répondre "impossible d'écrire le fichier" Tu devras alors penser à mettre la partition en rw pour la modifier.

[aquemy]

C'est assez étrange alors parce qu'habituellement je n'ai pas de soucis à modifier mes fichiers dans /etc.

En tout cas la manipulatio à marché.
Je vais pouvoir réinstaller le système et supprimer définitivement ce disque dur.
Ceci dit, je suis un peu sceptique parce que le disque est maintenant détecté comme sain (magré 1021 secteur endommagé).

Bon, pour l'occasion j'irai bien acheter un SSD histoire de mettre le système dessus.
Tu sais s'il y a un problème particulier avec LVM avec un SSD et quelle serait la meilleure configuration à faire ?
Le top serait que /boot soit sur le SSD, la racine et var sur le SSD mais que toutes les données soit sur l'autre DD.
On peut avoir un unique volume incluant le SSD et le 2To, en disant spécifiquement que les données de /Server-lvhome doivent-être sur le second DD ?

En tout cas, merci beaucoup pour ton aide !

[oktoberfest]

Pas de souci particulier à ma connaissance (je n'ai pas de SSD, je m'en soucierai le moment venu), il faut veiller à aligner les partitions et à priori utiliser l'option --dataalignment à la création du PV (cf http://unix.stackexchange.com/questions ... age-of-ssd).

Quand tu crées/étend un LV, tu peux spécifier quel PV utiliser (voir le man de lvcreate et lvextend) :

Code : Tout sélectionner

# lvcreate --name=toto --size=4G monvg /dev/sdd1

Autre solution : tu fais deux volumes. Mais si tu fais un LVM sur ton disque dur pour créer un unique LV qui va faire la taille du disque, cela ne sert à rien de faire du LVM...

[aquemy]

En fait si je veux profiter du SSD il faut absolument que mon système soit dessus non ? Après les données c'est plus secondaire.
Effectivement, je me suis mal exprimé. Je voulais dire que les données sur Server-var et Server-root soient prioritaires sur Server-home dans les sens où les données de Server-home vont être mises sur le SSD tant qu'il y a de la place (eventuellement bougées si on doit rajouter des trucs sur root ou var) et ensuite mises sur le second DD qui lui est réservé aux données.

Les motivations d'une telle installation serait de profiter au maximum du SSD, d'une part en terme de performance (tout les programmes sont dessus) et d'autre part en terme de stockage (j'ai un 128Go, ce qui serait dommage de ne l'utiliser qu'à 30%...).

EDIT : En fait je pense faire comme suit :

SSD
- 1 partition pour le boot (2G)
- 1 volume avec var et root (~10+15G)

SSD + autre DD
- 1 volume sur la place restante du SSD et tout le volume de l'autre DD

[oktoberfest]

2G pour le boot c'est un peu démesuré, 100 Mo sont largement suffisant.
Effectivement mieux vaut mettre le système sur le SSD, sinon il ne sert pas à grand chose

Idéalement ne fait qu'un seul volume regroupant la partition du SDD + ton disque dur. Après c'est à toi de créer/étendre les LVs en spécifiant les PV à utiliser. Ainsi tu créés / + /var sur le PV du SSD et /home et swap sur le PV du disqur dur.

Il existe Flashcache (par ici) pour utiliser une partie de ton SSD comme cache pour ton disque dur. Ce n'est pas encore intégré à AUR et je ne sais pas ce que ça vaut, mais ça peut être à tester.

[aquemy]

Dans un premier temps je vais tout mettre sur le SSD. J'ajouterais les autres DD au fur et à mesure.
Il n'y aura pas a de soucis à rajouter un DD à un PV par la suite avec vgextend non ?

En tout cas, merci encore. Je passe en résolu.

[oktoberfest]

Aucun souci. Par contre laisse-toi de la place sur ton SSD. Si tu étends /home et que satures ton SSD, tu te pourras plus étendre / ou /var (du moins sur le SSD).