Raid 1 : quel % de marge de sécurité

Support Debian
#1

Bonsoir,

Je veux monter un RAID 1 logiciel + LVM et je me sert du tuto donné par le Linux Magazine France du mois de novembre 2008 (n°110). L’auteur (Yves Mettier) explique qu’il ne faut pas occuper tout l’espace disque afin de ne pas avoir de problème lors d’un changement de disque qui pourrait être légèrement plus petit que l’ancien. Il préconise de laisser 2% d’espace en fin de disque non partitionner.

Dans mon cas, je compte monter mon RAID logiciel avec 2 disques d’1 To chacun. Un déjà acheté et l’autre que j’achèterais plus tard pour être sûr qu’ils ne tomberont pas en panne en même temps. Donc, 2% de 1 To ça fait quand même 20Go de perdu.

Alors mes questions sont :

Est-ce que je peux me permettre de réduire cette marge de sécurité ?

Peut-être qu’elle n’est vraiment importante que pour un serveur en Haute Disponibilité, non ?

Et donc, au pire, pourquoi ne pas se contenter de réduire la partition du disque qui fonctionne toujours si le nouveau est trop petit, avec Gparted ?

Est-ce que le fait qu’il y est des volumes logiques LVM sur cette partition peut poser des problèmes lors du redimensionnement ?

#2

Bonjour Lox,

je ne suis pas expert LVM, d’après ce que je sais, laisser de l’espace disque sert de “sécurité” si tu veut modifier une ou plusieurs partitions.

Par exemple si tu à 1 Disque de 100go, avec 2 partitions, une de 30Go et l’autre de 50Go, et que tu te rends compte qu’il te manque un peut de place sur la Première partition et que la 2ieme est blindé, bas tu peut redimensionner la première avec l’espace que tu as laissé vide. sans cette espace tu aurais été obligé de changer les 2 disques !

Pourquoi changer les 2 disques ? parce que tu parle de RAID 1 Mirroring qui copie des fichiers simultanément sur les 2 disques, La capacité totale est égale à celle du plus petit disque de la grappe.
si tu as 2 disques, un de 100go et l’autre de 1to, la capacité total de ton raid ne sera que de 100go.

réponses :

Oui

Non, la marge de sécurité ne sert que si tu as besoin de modifier une partition, la Haute Disponibilité sera dans le choix du raid que tu fera, en l’occurrence le raid 1 te donne une bonne vitesse de lecture mais pas d’écriture.

[quote]Et donc, au pire, pourquoi ne pas se contenter de réduire la partition du disque qui fonctionne toujours si le nouveau est trop petit, avec Gparted ?
[/quote]
tu peut, si tu aime perdre de la place pour rien…

je ne comprends pas du tout la question, le LVM sert justement à modifier les partitions comme bon te semble avec presque aucun risque de perte de données.

Maintenant comme je l’ai dit plus haut je ne suis pas expert LVM. De plus j’ai l’impression que tu cherche à ne pas perdre de place ?, dans ce cas la le RAID0 est plus approprié, sauf que niveau tolérance de panne c’est nada… Le Raid 5 serais plus adapté a ton cas, dans le sens que si ta 3 disques de 1 to chaqu’un, ton raid 5 sera de 2 to, en raid1 tu n’as que 1to.

j’espère t’avoir un peut aider.

fabien493

#3

Merci Fabien493,

[quote=“fabien493”]
je ne suis pas expert LVM, d’après ce que je sais, laisser de l’espace disque sert de “sécurité” si tu veut modifier une ou plusieurs partitions.

Par exemple si tu à 1 Disque de 100go, avec 2 partitions, une de 30Go et l’autre de 50Go, et que tu te rends compte qu’il te manque un peut de place sur la Première partition et que la 2ieme est blindé, bas tu peut redimensionner la première avec l’espace que tu as laissé vide. sans cette espace tu aurais été obligé de changer les 2 disques !

Pourquoi changer les 2 disques ? parce que tu parle de RAID 1 Mirroring qui copie des fichiers simultanément sur les 2 disques, La capacité totale est égale à celle du plus petit disque de la grappe.
si tu as 2 disques, un de 100go et l’autre de 1to, la capacité total de ton raid ne sera que de 100go.[/quote]Je pense qu’il n’y pas que la modification des partitions qui entre en jeux… Dans l’article, l’auteur parles de deux disques dur de 1To qui sont vendu pour être de même taille mais pas exactement de la même taille : il se peux qu’à cause d’une différence de densité de plateau ou de nombre de plateau, tu ne tombes pas exactement sur le même nombre de cylindres. Et si le nouveau disque est légèrement plus petit de quelques cylindres, tu ne peut plus faire ton RAID 1. Il faut donc soit que tu prévois le coup en ne partitionnant que 98% du disque soit que tu réduises ton espace disque exploitable sur le disque qui fonctionne encore si c’est possible…

Non, la marge de sécurité ne sert que si tu as besoin de modifier une partition, la Haute Disponibilité sera dans le choix du raid que tu fera, en l’occurrence le raid 1 te donne une bonne vitesse de lecture mais pas d’écriture.[/quote]Désolé… Je me suis mal expliqué… Je veux dire dans le sens où l’intervention sur le serveur demandera beaucoup moins de temps d’indisponibilité. Puis que le changement de disque sera plus rapide.

tu peut, si tu aime perdre de la place pour rien…[/quote]Voir plus haut…

je ne comprends pas du tout la question, le LVM sert justement à modifier les partitions comme bon te semble avec presque aucun risque de perte de données.[/quote]Je ne connais pas bien LVM moi non plus. Mais je me dit que LVM c’est bien pratique pour facilité la modification des volumes logique sur une même partition mais si la partition elle même doit être réduite, je me dis que ça doit avoir une incidence sur l’organisation des volumes logiques de celle-ci.

[quote]Maintenant comme je l’ai dit plus haut je ne suis pas expert LVM. De plus j’ai l’impression que tu cherche à ne pas perdre de place ?, dans ce cas la le RAID0 est plus approprié, sauf que niveau tolérance de panne c’est nada… Le Raid 5 serais plus adapté a ton cas, dans le sens que si ta 3 disques de 1 to chaqu’un, ton raid 5 sera de 2 to, en raid1 tu n’as que 1to.
[/quote]Je cherche à ne pas perdre de place dans le sens que cela me fait mal au cœur de “gaspiller” 20Go même si ça ne représente que 2% de mon espace de stockage. Mais un RAID 0 serait une très mauvaise idée dans mon cas : un disque foutu = toutes les données de perdu. Et comme cela vas être plus ou moins un serveur de fichiers domestique et que je sais que je ne vais pas être aussi rigoureux qu’il le faudrait pour les sauvegardes, je préfère prendre quelques précautions. Je ne peux pas faire un RAID 5, ma carte mère est limité à 2 ports SATA. De plus, je n’ai pas un budget illimité.

#4

Ok, je m’excuse je n’avais pas bien compris, je n’ai jamais acheté le Linux Magazine France.

si j’ai bien compris, les disques vendu de la même taille dans le commerce n’aurais pas le même nombre de cylindres. effectivement, je pense que oui, si la marque des disques dur est différente.

voici le résultat de 2 disques dur de 500 go de la même marque :

Disk /dev/sdb: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x092e500e

Device Boot Start End Blocks Id System
/dev/sdb1 1 60801 488384001

Disk /dev/sdc: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00000000

Device Boot Start End Blocks Id System
/dev/sdc1 1 60801 488384001

pour moi il n’y a pas de différence au niveau des cylindres, et mon raid marche nikel avec c’est disque la et je ne laisse pas d’éspace. Avec 2 disques de différente marque il se peut que le nombre de Cylindre ne sois pas le même, et dans ce cas la, le raid prendra en compte que le plus petit disque et ce avec le risque de perdre des données. Personnellement, je n’ai jamais entendu dire qu’il fallait laisser de la place sur les disques de raid, sur mon raid j’ai un disque qui a claqué récemment, j’ai racheté un autres disques de même capacité et de même marque, refait la partition et tout fonctionne avec le même nombre de cylindre.

il n’y à pas de temps d’indisponibilité en raid, justement c’est le but, si un des 2 disques crame, l’accès ce fait sur l’autre, et tu as pris du sata, (hot swap) tu peut débrancher et rebrancher les disques à chaud, sans éteindre le pc, c’est le but principale du sata, et si tu n’éteint pas le serveur alors il n’y a pas de temps d’indisponibilité.

je ne pense pas que la modification des partitions à une reel incidence sur “l’organisation” des volumes.

ha oui ça c’est vraiment dommage, mais aujourd’hui toute les cartes mère sont vendu avec presque 4 ports sata, personnellement, moi j’avais prévu de faire du raid quand j’ai acheté ma carte mère avec 6 port sata. Au pire achète une carte pci sata en plus, comme ça tu garde ta carte mère, et tu dépense moins que de racheter une autres carte mére.

dans ce cas la, le raid 1 n’est pas du tout adapté à ton cas, le Raid1 est parmis ceux les plus couteux de tout les raids.

attend qu’un expert passe dans le coin il pourras peut être te donner plus d’explications que moi sur le sujet.

amicalement,
fab

#5

Pas forcement uniquement la marque… Certain disques dur peuvent durer plus de 10 ans. Entre temps, le modèle à évolué : moins de plateau, plus de densité pour une même capacité.

il n’y à pas de temps d’indisponibilité en raid, justement c’est le but, si un des 2 disques crame, l’accès ce fait sur l’autre, et tu as pris du sata, (hot swap) tu peut débrancher et rebrancher les disques à chaud, sans éteindre le pc, c’est le but principale du sata, et si tu n’éteint pas le serveur alors il n’y a pas de temps d’indisponibilité.[/quote]Je suis au courant de tout ça et c’est entre autre pour ça que je me prend la tête à faire un RAID. Mais si tu dois modifier la taille d’une partition, il est fortement probable que tu doivent redémarrer car le noyau ne prendra la modification en compte qu’une fois le système relancé. Ce qui n’est pas le cas si tes deux partitions font la même taille.

je ne pense pas que la modification des partitions à une reel incidence sur “l’organisation” des volumes.[/quote]Comment LVM vas-t’il gérer la chose ? Réduire le dernier volume logique ? Réduire tous les volumes logiques ?

dans ce cas la, le raid 1 n’est pas du tout adapté à ton cas, le Raid1 est parmi ceux les plus couteux de tout les raids.[/quote]D’une ce n’est pas le sujet et de deux oui, il est tout à fait adapté.
Je n’achète que deux disques de 100€ au lieux de 3 disques + 1 carte “contrôleur”. Je n’ai pas prévu de dépenser plus.

#6

Personnellement j’ai plusieurs Raid1 avec des LVM dessus et j’en suis très content.

Bon pour le Hot Swap ça marche plus ou moins bien mais je m’en cogne.

#7

Lox,

je m’excuse si tu as mal pris ce que j’ai dit.

j’ai fait pas mal de recherche pour essayer de répondre au mieux à tes questions :

effectivement les disques dur évolues avec le temps, mais la description des disques que je t’ai donner, ont 5 ans d’écart, et ont les mêmes nombre de cylindres, et de plateaux. je pense que ce n’est qu’un point de vue. faudra qu’on regarde ensemble sur les différences des disques de 1To dans 10 ans si tu veut. donc concernant cette marge, “mon avis” c’est que aujourd’hui elle n’a d’intérêt que au niveau des redimensionnement des partitions. Dans 10ans tes 1to seront probablement devenu obsolète et tu voudra surement augmenter la capacité.

d’après ce que j’ai lu, et vu, seul lvm doit être redémarré, sauf si tu te sert du disque en tant que disque système.
ça répond à la question d’indisponibilité.

ce n’est pas LVM qui gère le redimensionnement des partitions des disques, c’est toi qui te sert de LVM pour faire ce que tu veut sur tes disques. Maintenant je ne peut pas te dire comment LVM gere les disques une fois modifiés.

Raid1 :

[quote]D’une ce n’est pas le sujet et de deux oui, il est tout à fait adapté.
Je n’achète que deux disques de 100€ au lieux de 3 disques + 1 carte “contrôleur”. Je n’ai pas prévu de dépenser plus.[/quote]

Effectivement, ce n’es pas le sujet, je tenais simplement à te donner mon point de vu.
au début moi aussi j’étais en raid1, puis je me suis rendu compte que je ne pouvais pas augmenter la taille au cas ou mon serveur de fichier serais blindé. et un jour c’est arrivé, et j’ai du virer mes 2 disques de 360go, et en racheter 2 de 500, j’avais un peut les boules…Depuis j’ai opté pour le raid 5, et ce matin je suis passé de 1tera, à 1,5 téra en achetant qu’un seul disques et non 3 lol.
Bref,

sur ceux j’éspere que tu n’a pas trops mal pris ce que j’ai dit, et j’éspère que mes réponses te permettront d’avancer dans le monde du RAID Linux.

amicalement,
Fab

#8

Merci pour ta recherche :slightly_smiling:

On n’est pas tout a fait dans le même cas de figure : les constructeurs sortent actuellement des plateaux à 500 Go, donc les 333Go vont vite disparaitre et ils vont rapidement sortir des DD de 1To en 2X500 Go plutôt que 3X333 Go.
Mais je comprend mieux ton avis :slightly_smiling: Peut-être que je vais tout de même garder cette marge en y mettant un raid0 en attendant sachant que de toute façon, je perdrait ces données en cas de problème… Même si ce n’est pas une solution qui me convienne dans l’absolu… :confused:

[quote]

d’après ce que j’ai lu, et vu, seul lvm doit être redémarré, sauf si tu te sert du disque en tant que disque système.
ça répond à la question d’indisponibilité.[/quote]
C’est mon cas : j’utilise le RAID et les LVM en tant que disque système mis à part la partition /boot
Donc si je voulais faire proprement les choses il vaudrait mieux que je mettent le système sur un disque dur à part du raid1 de stockage. C’est aussi ce que je me suis dit mais je suis limité par le nombre de port SATA.
De toute façon, dans mon cas la HT n’est pas si importante. C’est aussi un moyen de ne pas trop se prendre la tête lors d’une “urgence”. Parce que d’ici là, j’aurais peut-être oublié mon partitionnement (j’espère en tous cas sinon ça voudra dire que mes DD était de mauvaises séries :/) et il faudra que je relise mes notes.

ce n’est pas LVM qui gère le redimensionnement des partitions des disques, c’est toi qui te sert de LVM pour faire ce que tu veut sur tes disques. Maintenant je ne peut pas te dire comment LVM gere les disques une fois modifiés. [/quote]Je crois que l’on s’est une nouvelle fois pas compris…

Si je réduit ma partition, LVM va forcement devoir adapter les volumes physique et logique. Ma question était de savoir comment et si je devrais intervenir.

D’après ce que tu me disais, il s’adapte tout seul simplement en redémarrant le service… Mais là, si je comprend bien, tu me dis qu’il faut que ce soit moi qui intervienne pour le redimensionnement des volumes logiques ?

Je reconnais que je pinaille un peu… Mais il me semble que ce sont des questions qui sont importante car lors de l’intervention, il sera un peu tard pour se les poser.

De mon côté, j’ai choisi de prendre des DD d’ 1To à cause de la densité des plateaux qui permet de meilleurs débit. Peut-être qu’en effet, j’aurais du prendre 3 DD de 500Go + une carte “contôleur” et faire du raid5 comme toi. Mais dès le départ j’étais limité par le nombre de port PCI et de connecteur SATA :confused: Sans compter que les cartes “contrôleur” sont parfois une source de problème supplémentaire ( disponibilité des pilotes + pièce supplémentaire dans la machine qui peut tomber en panne) De plus, il me semble qu’un RAID 5 prend un peu plus de ressources système qu’un RAID 1…

Mon serveur actuel n’a qu’un disque de 20Go et je m’en contente largement même s’il ne fait pas serveur de fichier. Donc 1To d’espace disque, je devrait pouvoir m’y adapter pendant pas mal de temps je pense :wink:

On fait ce qu’on peut avec ce qu’on a :wink:

[quote]sur ceux j’éspere que tu n’a pas trops mal pris ce que j’ai dit, et j’éspère que mes réponses te permettront d’avancer dans le monde du RAID Linux.[/quote]Si, sur le coup, je l’ai mal pris… Mais je pense que c’est le temps nécessaire pour savoir s’ajuster aux connaissances de l’autre… Puis c’est parfois délicat la communication sur les forums : 60% du message passe par les gestes et les mimiques lorsqu’on à la personne devant soi et compenser ces 60% manquant n’est pas évidant :slightly_smiling:

#9

Salut Lox,

oui tu as raison pour la communication.

Je suis en train de faire une archi Raid1 + LVM chez moi, pour voir comment ça se passe, augmenter mes compétences, et te donner des vrais réponses, et pas des “je crois”.

par-contre c’est sur que tu doit redémarrer le kernel si un des disques est utilisé en disque de système. de plus j’ai vue que grub pourrait être capricieux avec les lvm.

je post dès que c’est prêt.

amicalement,
Fab

#10

Je t’apporte un début de réponse : Grub ne peut pas lire ce qui se trouve sur un volume logique.
Il faut créer une partition /boot à part. Mettre cette partition en RAID ne pose aucun problème.

Pour ma part, voila comme j’ai fait grossièrement et de tête d’apres l’article du GLMF n°110 :

Partitionnement : fdisk
1 partition primaire pour /boot
1 partition primaire pour le swap
1 partition primaire pour LVM

Création du raid : mdadm

mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sda1 missing (missing pour le fait que je n’ai pas encore le second disque : je compte tournée sur un seul disque pendant un temps)
La partition swap, j’ai prévu de la mettre en raid 0, donc pour l’instant je la laisse tel qu’elle… avec 2Go de mémoire vive, je ne pense pas qu’il soit très utilisé pour le moment de toute façon…
mdadm --create /dev/md2 --level=1 --raid-devices=2 /dev/sda3 missing

Création des volumes physique et logiques LVM
/, /tmp, /usr, /var, /home, /home/partage

Formatage avec les FS qui vont bien

La réplication RAID 1 se fait par la suite assez facilement…

Si ça peut t’avancer…

(très bon cet article :wink: Je n’ai pas trouver d’équivalent aussi bon sur le net)

#11

re lox,

je n’est pas mis en place le raid1+LVM pour qu’il soit utilisé en point de montage système, trop dangereux pour moi. je vais me contenter de mettre en place un raid 1 + lvm, en tant que partages.

Aller on se lance…

En premier lieu, je n’ai pas 2 disques de même capacités, donc les blocs ne seront pas les mêmes,(160 sur /dev/sdc1 et 2000 sur /dev/sdd1 à peut peut de chose prêt 2go.

Mise en place du raid 1:

j’ai construit une partition sur chaques disques de 2go, en FD (linux raid autodetecte),
une fois les partitions sur les 2 disques opérationnelles, on construit le raid :

Première erreur:

mdadm: /dev/sdc1 appears to contain an ext2fs file system size=2088416K mtime=Sat Apr 4 22:27:25 2009 mdadm: /dev/sdd1 appears to contain an ext2fs file system size=2047984K mtime=Sat Apr 4 22:26:01 2009 mdadm: largest drive (/dev/sdc1) exceed size (2047872K) by more than 1% Continue creating array? yes mdadm: array /dev/md0 started.

Normal, on accepte.

ensuite on vérifie:

Fabien493:# mdadm --detail /dev/md0
/dev/md0:
        Version : 0.90
  Creation Time : Sat Apr  4 22:32:55 2009
     Raid Level : raid1
     Array Size : 2047872 (2000.21 MiB 2097.02 MB)
  Used Dev Size : 2047872 (2000.21 MiB 2097.02 MB)
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 0
    Persistence : Superblock is persistent

    Update Time : Sat Apr  4 22:34:46 2009
          State : clean
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

           UUID : a7b8be94:98ed0c43:09c9ca7c:8a381c8b (local to host Fabien493)
         Events : 0.4

    Number   Major   Minor   RaidDevice State
       0       8       33        0      active sync   /dev/sdc1
       1       8       49        1      active sync   /dev/sdd1

et on format en EXT3 :

Fabien493:/# mkfs.ext3 /dev/md0
mke2fs 1.41.3 (12-Oct-2008)
Étiquette de système de fichiers=
Type de système d'exploitation : Linux
Taille de bloc=4096 (log=2)
Taille de fragment=4096 (log=2)
128000 i-noeuds, 511968 blocs
25598 blocs (5.00%) réservés pour le super utilisateur
Premier bloc de données=0
Nombre maximum de blocs du système de fichiers=524288000
16 groupes de blocs
32768 blocs par groupe, 32768 fragments par groupe
8000 i-noeuds par groupe
Superblocs de secours stockés sur les blocs :
        32768, 98304, 163840, 229376, 294912

Écriture des tables d'i-noeuds : complété
Création du journal (8192 blocs) : complété
Écriture des superblocs et de l'information de comptabilité du système de
fichiers :
complété

jusque la tout vas bien !

[size=150]Mise en place du LVM :[/size]

Création un Volume Physique :

Fabien493:/# pvcreate /dev/md0
  Physical volume "/dev/md0" successfully created

Création du Groupe de Volumes (ici “group1”) :

Fabien493:# vgcreate group1 /dev/md0 Volume group "group1" successfully created

Création de 2 Volumes Logiques (ici « volume1 de 512Mo et volume2 de 1450Mo » ) dans le groupe “group1”

Fabien493:/# lvcreate -n vol1 -L 512mo group1 Logical volume "vol1" created Fabien493:/# lvcreate -n vol2 -L 1450mo group1 Rounding up size to full physical extent 1,42 GB Logical volume "vol2" created

Création du système de fichiers EXT3 sur vol1 et vol2 :

mkfs.ext3 /dev/group1/vol1
et

mkfs.ext3 /dev/group1/vol2

et pour le fun on monte /dev/group1/vol1 dans /mnt/vol1
et /dev/group1/vol2 dans mnt/vol2, en ayant au préalable créer les répertoires vol1 et vol2 dans /mnt

Fabien493:/mnt# mount /dev/group1/vol1 /mnt/vol1/
Fabien493:/mnt# mount /dev/group1/vol2 /mnt/vol2/

maintenant ont vérifie :

Fabien493:/mnt# df -h Sys. de fich. Tail. Occ. Disp. %Occ. Monté sur /dev/mapper/group1-vol1 504M 17M 462M 4% /mnt/vol1 /dev/mapper/group1-vol2 1,4G 35M 1,3G 3% /mnt/vol2

on peut constater un défaut, quand j’ai crée le Volume logique lv1 et lv2, j’ai définit lv1 à 512Mo et lv2 à 1450mo, et effectivement ce n’est pas le cas, je ne peut l’expliquer !, peut être que lvm calcul la taille total, et modifie les partitions au mieux. vraiment bizarre.

Donc voila, le Raid1 est opérationnel, avec 2 volume logique monté dans /mnt/vol1 et /mnt/vol2.
on vas mettre quelque donnée dedans (juste pour le fun !)

Fabien493:/mnt# mdadm --detail /dev/md0 > /mnt/vol1/mdadm_result Fabien493:/mnt# mdadm --detail /dev/md0 > /mnt/vol2/mdadm_result Fabien493:/mnt# cat /proc/mdstat > /mnt/vol2/proc_mdadm

avant de tout péter un peut plus tard, on vas agrandir le volume logique “vol1” et voir comment LVM réagis :

en premier ont démonte vol1 et vol2:

Fabien493:/mnt# umount vol1/
Fabien493:/mnt# umount vol2/

Ensuite ont augmente le volume logique “lv1” de 950Mo :

Fabien493:/mnt# lvextend -L 950mo /dev/group1/vol1 
Rounding up size to full physical extent 952,00 MB
  Extending logical volume vol1 to 952,00 MB
  Insufficient free space: 110 extents needed, but only 8 available

Voila, une réponse à une question, lvm ne peut pas augmenter le volume logique “vol1” parce qu’il n’y a plus de place sur le disque /dev/md0, donc maintenant on peut répondre oui à la question de laisser de la taille ou non.

maintenant comme moi je n’ai pas laissé de “place libre” je suis un peut dans la M… .

je vais essayer de réduire la partition vol2 pour augmenter après vol1. Le problème dans ce cas la c’est que réduire un volume logique détruit le système de fichier.

Pour éviter tout risque, parce que je veut pas perdre mes données, je vais réduire la taille du système de fichier à 900Mo, réduire la taille du volume logique vol2 à 1000Mo, et agrandir le vol1 à 1000mo. vaut mieux réduire un peut plus le système de fichier pour pas avoir de surprise :

Fabien493:/mnt# resize2fs -f /dev/group1/vol2 900M
resize2fs 1.41.3 (12-Oct-2008)
Resizing the filesystem on /dev/group1/vol2 to 230400 (4k) blocks.
Le système de fichiers /dev/group1/vol2 a maintenant une taille de 230400 blocs.

NOTE: pour redimensionner un système de fichier EXT3 j’ai utilisé resize2fs, pour les autres systèmes de fichier c’est un peut plus compliqué.

ont monte vol2 et ont vérifie :

Fabien493:/mnt# mount /dev/group1/vol2 /mnt/vol2/
Fabien493:/mnt# df -h
Sys. de fich.         Tail. Occ. Disp. %Occ. Monté sur
/dev/mapper/group1-vol2
                      885M   34M  806M   5% /mnt/vol2

peut-ont dire encore Bizarre ??? lol à sacré lvm…

ont re-démonte vol2, et on rétrécie le volume logique :

Fabien493:/mnt# lvresize -L 1000M /dev/group1/vol2
  WARNING: Reducing active and open logical volume to 1000,00 MB
  THIS MAY DESTROY YOUR DATA (filesystem etc.)
Do you really want to reduce vol2? [y/n]: y
  Reducing logical volume vol2 to 1000,00 MB
  Logical volume vol2 successfully resized

comme j’ai réduit mon système de fichier à 900Mo et le volume logique à 1000M, normalement je n’est rien perdu. Pour pas perdre de place je vais maintenant ré-agrandir mon système de fichier pour qu’il prenne toute la place du volume logique :

Fabien493:/mnt# resize2fs /dev/group1/vol2
resize2fs 1.41.3 (12-Oct-2008)
Le système de fichiers de /dev/group1/vol2 est monté sur /mnt/vol2 ; le changement de taille doit être effectué en ligne
old desc_blocks = 1, new_desc_blocks = 1
En train d'effectuer un changement de taille en ligne de /dev/group1/vol2 vers 256000 (4k) blocs.
Le système de fichiers /dev/group1/vol2 a maintenant une taille de 256000 blocs.

ont remonte pour vérifier la taille, et les données :

Fabien493:/mnt# df -h
Sys. de fich.         Tail. Occ. Disp. %Occ. Monté sur
/dev/mapper/group1-vol2
                      985M   34M  906M   4% /mnt/vol2

Fabien493:/mnt# ls /mnt/vol2/
lost+found  mdadm_result  proc_mdadm
Fabien493:/mnt# vim /mnt/vol2/proc_mdadm
Personalities : [raid1]
md0 : active raid1 sdd1[1] sdc1[0]
      2047872 blocks [2/2] [UU]

unused devices: <none>

Donc voila, mon système de fichier à été rétrécie puis agrandie, le volume logique vol2 à été rétrécie, et sans perte de données !!! Géniale !!
Maintenant passons à l’agrandissement du volume logique vol1 :

Fabien493:/mnt# lvextend -L 1000M /dev/group1/vol1 Extending logical volume vol1 to 1000,00 MB Insufficient free space: 122 extents needed, but only 121 available

Ha, j’ai pas assez de place :

Fabien493:/mnt# lvextend -L 950M /dev/group1/vol1 Rounding up size to full physical extent 952,00 MB Extending logical volume vol1 to 952,00 MB Logical volume vol1 successfully resized Fabien493:/mnt#

Le volume logique /dev/group1/vol1 à été augmenté à 952,00MB.
maintenant faut agrandir le système de fichier :

Fabien493:/mnt# resize2fs /dev/group1/vol1
resize2fs 1.41.3 (12-Oct-2008)
SVP exécutez « e2fsck -f /dev/group1/vol1 » d'abord.

Fabien493:/mnt# e2fsck -f /dev/group1/vol1
e2fsck 1.41.3 (12-Oct-2008)
Passe 1 : vérification des i-noeuds, des blocs et des tailles
Passe 2 : vérification de la structure des répertoires
Passe 3 : vérification de la connectivité des répertoires
Passe 4 : vérification des compteurs de référence
Passe 5 : vérification de l'information du sommaire de groupe
/dev/group1/vol1 : 12/32768 fichiers (0.0% non contigus), 6263/131072 blocs
Fabien493:/mnt# resize2fs /dev/group1/vol1
resize2fs 1.41.3 (12-Oct-2008)
Resizing the filesystem on /dev/group1/vol1 to 243712 (4k) blocks.
Le système de fichiers /dev/group1/vol1 a maintenant une taille de 243712 blocs.

quelques erreurs mais rien de grave, la partition à été augmenté.
Ont vérifie :

Fabien493:/mnt# mount /dev/group1/vol1 /mnt/vol1/
Fabien493:/mnt# mount /dev/group1/vol2 /mnt/vol2/
Fabien493:/mnt# df -h
Sys. de fich.         Tail. Occ. Disp. %Occ. Monté sur
/dev/sda1              90G   17G   68G  20% /
tmpfs                 506M     0  506M   0% /lib/init/rw
udev                   10M  120K  9,9M   2% /dev
tmpfs                 506M     0  506M   0% /dev/shm
/dev/mapper/group1-vol1
                      936M   17M  872M   2% /mnt/vol1
/dev/mapper/group1-vol2
                      985M   34M  906M   4% /mnt/vol2[/code]
résultat, le volume logique vol1 a été augmenté, et le volume logique vol2 à été diminué.
Vérification des fichiers :
[code]
Fabien493:/mnt# ls /mnt/vol1/
lost+found  mdadm_result
Fabien493:/mnt# ls /mnt/vol2/
lost+found  mdadm_result  proc_mdadm
[/code]

Voila donc on peut constater que le LVM, permet effectivement de modifier les volumes logiques comme bon nous sembles, par-contre, sans espace supplémentaire sur le disque cela oblige à modifier tout les volumes logiques et toutes les partions. Et comme je le pensais, c'est bien l'utilisateur qui utilise les outils de LVM pour les modifiers.

Maintenant nous pouvons passer à la phase [size=150]"DESTRUCTION DU RAID"[/size].........a vos marteaux !!!

nan nan je rigole, comme le raid 1 est constitué de 2 disques Sata (hotswap) ont vas simplement débrancher un disque à chaud et voir ce qui ce passe :

Donc je viens de débrancher un disque, ont regarde ce que mdadm nous dit :
[code]Fabien493:/mnt# mdadm --detail /dev/md0
/dev/md0:
        Version : 0.90
  Creation Time : Sat Apr  4 22:32:55 2009
     Raid Level : raid1
     Array Size : 2047872 (2000.21 MiB 2097.02 MB)
  Used Dev Size : 2047872 (2000.21 MiB 2097.02 MB)
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 0
    Persistence : Superblock is persistent

    Update Time : Sun Apr  5 00:41:17 2009
          State : clean
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

           UUID : a7b8be94:98ed0c43:09c9ca7c:8a381c8b (local to host Fabien493)
         Events : 0.4

    Number   Major   Minor   RaidDevice State
       0       8       33        0      active sync   /dev/sdc1
       1       0        0        1      removed

       2       8       49        -      faulty spare[/code]
Alors ça faut m'expliquer ??? State : CLEAN  MDRRR
le disque /dev/sdd1 n'éxiste plus, ont regarde si on n'a quand meme accès au donnée du raid + lvm :
[code]Fabien493:/mnt# ls /mnt/vol1/
lost+found  mdadm_result
Fabien493:/mnt# ls /mnt/vol2/
lost+found  mdadm_result  proc_mdadm

ça marche encore, cool le raid hein !!

bon maintenant pour répondre à la question sur le fait que les disques change avec le temps, différence de densité de plateaux ou de nombre de plateaux, ou de cylindres, ont vas carrément remplacer le disque /dev/sdd qui était un disque samsung de 40Go (un peut moins de 10ans lol) par un SAMSUNG 320GB acheté ce matin à montgallet !!

le nouveau disque de 320Go est /dev/sde
après le fdisk :

[code]Disk /dev/sde: 320.0 GB, 320072933376 bytes
255 heads, 63 sectors/track, 38913 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0xb544c1f6

Device Boot Start End Blocks Id System
/dev/sde1 1 250 2008093+ fd Linux raid autodetect[/code]

maintenant on l’intègre dans le raid :

Fabien493:/mnt# mdadm --manage /dev/md0 --add /dev/sde1
mdadm: added /dev/sde1

après la reconstruction du disque voici ce que nous dit mdadm :

Fabien493:/mnt# mdadm --detail /dev/md0
/dev/md0:
        Version : 0.90
  Creation Time : Sat Apr  4 22:32:55 2009
     Raid Level : raid1
     Array Size : 2047872 (2000.21 MiB 2097.02 MB)
  Used Dev Size : 2047872 (2000.21 MiB 2097.02 MB)
   Raid Devices : 2
  Total Devices : 3
Preferred Minor : 0
    Persistence : Superblock is persistent

    Update Time : Sun Apr  5 01:23:00 2009
          State : clean
 Active Devices : 2
Working Devices : 2
 Failed Devices : 1
  Spare Devices : 0

           UUID : a7b8be94:98ed0c43:09c9ca7c:8a381c8b (local to host Fabien493)
         Events : 0.36

    Number   Major   Minor   RaidDevice State
       0       8       33        0      active sync   /dev/sdc1
       1       8       65        1      active sync   /dev/sde1

       2       8       49        -      faulty spare

le raid est clean, sauf que voila, maintenant ont n’a un spare, qui n’existe pas, et je n’ai pas trouvé le moyen de le supprimer.
mais à partir du moment ou le raid est clean bas c’est clean ou presque…

voila, la petite histoire du RAID 1 + LVM, Sachez que je n’avais aucune connaissance dans le LVM avant de rediriger ceci.

je suis assez content de moi, et j’espère que ceci pourras t’aider Lox. Si j’ai le temps je regarderais le moyen de mettre tout ça en place pour un point de montage système.

p.s: je m’excuse pour les fautes d’orthographe.

Amicalement,
Fabien493.