Linux - Augmentation d'un Logical Volume

Linux - Augmentation d'un Logical Volume - Infrastructures serveurs - Systèmes & Réseaux Pro

Marsh Posté le 02-02-2010 à 15:42:16    

Bonjour,
 
J'ai un serveur Linux Red Hat 9 avec un logiciel de sauvegarde dessus. Le serveur contient 2 DD en raid mirror de 72 Go chacun. La répartition du disque a été faite de la façon suivante:
un volume groupe (VG00) répartit en 3 LV
1er LV "/" --> 35% d'utilisé
2ième LV "/Sav" --> 96% d'utilisé (Application de sauvegarde)
3ième LV "/tmp" --> 2% d'utilisé
 
Du faite de l'augmentation de taille du catalogue de sauvegarde, je suis dans l'obligation d'augmenter la taille de l'espace disque pour pouvoir augmenter la taille du /Sav. Pour cela, j’ai commandé 2 disques  146Go et j’ai procédé de la manière suivante :  J’ai enlevé le disque de 72Go de l’emplacement n°1 et je l’ai remplacé par un disque de 146Go. Le raid mirror s’est reconstruit. J’ai ensuite fait la même manipulation avec le 2ième disque de 72Go.  J’ai désormais 2 disques de 146Go en raid mirror. La deuxième partie  (la plus délicate) concerne l’augmentation de la taille du 3ième LV. Avant de faire cette manipulation, j’ai fait une sauvegarde de l’application, arrêté le service de l’application et j’ai voulu testé la manipulation sur le 2ième LV (/tmp) pour m’assuré que c’était bien opérationnel.  
J’ai donc suivi la procédure ci-dessous (trouvé sur le net) :
« umount /essai
e2fsck -f /dev/mvg/toto
lvresize -L 2g /dev/mvg/toto
resize2fs /dev/mvg/toto
mount /dev/mvg/toto /essai »
 
Je l’applique donc dans mon contexte :
umount /tmp
« umount :  /tmp : périphérique occupé »
1er étape ne passe pas…Je teste un umount –l (démontage « paresseux »)
Umount  –l  /tmp, à priori ça passe.
En tapant la commande mount, je vois que ça passe.
« e2fsck -f /dev/VolGroup00/LogVol03 »
Voici le résultat
e2fsck 1.35 (28-Feb-2004)
/dev/VolGroup00/LogVol03: recovering journal
Clearing orphaned inode 146672 (uid=0, gid=0, mode=010666, size=0)
Clearing orphaned inode 146671 (uid=0, gid=0, mode=010666, size=0)
Clearing orphaned inode 407201 (uid=0, gid=0, mode=040700, size=4096)
Clearing orphaned inode 407202 (uid=0, gid=0, mode=040700, size=4096)
Clearing orphaned inode 407203 (uid=0, gid=0, mode=0100700, size=609)
Clearing orphaned inode 12 (uid=0, gid=0, mode=0100644, size=7095392)
Clearing orphaned inode 15 (uid=0, gid=0, mode=0100600, size=1635)
Clearing orphaned inode 146599 (uid=0, gid=0, mode=010666, size=0)
Clearing orphaned inode 146597 (uid=0, gid=0, mode=010666, size=0)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/VolGroup00/LogVol03: ***** FILE SYSTEM WAS MODIFIED *****
/dev/VolGroup00/LogVol03: 141/521216 files (2.1% non-contiguous), 29823/1024000 blocks
 
Je lance ensuite un Lvresize :
lvresize -L 5g /dev/VolGroup00/LogVol03
  Extending logical volume LogVol03 to 5,00 GB
  « Insufficient suitable allocatable extents for logical volume LogVol03: 35 more required »
Et là, je ne comprends pas le pourquoi du comment sur cette commande.
J’essaye avec la commande lvextend :
 lvextend -L+1024M /dev/VolGroup00/LogVol03
J’obtiens :
«   Extending logical volume LogVol03 to 4,91 GB
  Insufficient suitable allocatable extents for logical volume LogVol03: 32 more required –L »  
 
Quelqu'un aurait une piste, svp?

Reply

Marsh Posté le 02-02-2010 à 15:42:16   

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed