Encore de la casse (fin)

Finalement mon array s'est rebâti comme prévu. J'ai immédiatement entrepris d'en faire le backup mais je me suis rendu compte que je manquais cruellement d'espace disque. J'ai du remplacer un 180G et une paire de 200G par un 400G et une paire de 500G SATA. Avertissement: Si votre carte mère est une A8V Deluxe, le contrôleur SATA ne prend pas en charge les disques SATA II à 3Gb/s. Vous devez les forcer à 1.5Gb/s avec un jumper. Le remplacement des disques et l'agrandissement des volumes LVM2 s'est fait sans encombre. Seul commentaire: un pvmove sur un disque de 200G, c'est lent. La prochaine étape sera de prendre un backup complet de mon array.

Encore de la casse (suite et fin?)

Ce matin, j'enlève le Seagate et je remets le WD1200JB que je crois brisé.
Après avoir passé pas mal de temps sur Google pour trouver ce qu'est le problème ou quelqu'un avec un problème similaire, j'ai trouvé le cas d'un gars dont la SX6000 a indiqué 2 drives "? : ? failed or disconnected" sans aucune raison. La solution à son problème a été de détruire l'array puis de le recontituer sans l'initialiser. Et pour lui ça a marché. Je me proposais de faire la même chose même si je n'ai perdu "qu'un" disque. C'est pour cette raison que j'ai rebranché ce matin le disque original. Comble de chance pour moi, le manuel de Promise sur la récupération d'array est très clair (pages 23 à 28).
En rebootant la machine qu'elle ne fut pas ma surprise de voir que mon array n'était plus "Offline" mais "Critical". En allant dans le BIOS de la SX6000, j'ai pu voir que la SX6000 était en train de rebâtir l'array et que le disque 1 est fautif alors que le disque qui était initialement indiqué comme fautif était le 6. SI la carte finit par tout rebâtir et que je ne perds pas de données, je n'aurai pas à suivre la procédure risquée du manuel de Promise. Je vais faire un backup complet de l'array (je fait un rsync des 2/3 de l'array à tout les 3 heures sur un JBOD qui ensuite est transféré sur des tapes DLT une fois par semaine). Sur le JBOD auquel j'ajouterai 1TB de capacité. Je metterai aussi ce qui est hyper-critique, mais ne change pas souvent, sur des DVDs. Ma stratégie de backup est correcte mais ne couvre pas tout. Mais avec le coût des disques qui tombe sans cesse, je peux me permettre de passer de RAID 5 à "pseudo-RAID50" (i.e. faire un backup d'un RAID5 sur un autre RAID5). Aussi, je vais générer une image pour VMWare de la machine qui héberge la carte. On est jamais trop prudent...
Je ne devrais pas me plaindre de mon array. Ça fait 5 ans qu'il roule 24/7 et je n'ai eu qu'à remplacer qu'un disque. La SX6000 n'est pas la meilleure carte du monde, elle m'a donné pas mal de toubles au début mais elle a remplit sa mission. Il faut que je commence a penser à la remplacer...

Voilà un petit "Howto" (en anglais) que j'ai écrit expliquant comment changer un disque qui fait partie d'un volume LVM. Le formattage est pas super, je vais essayé de travailler là-dessus un de ces quatre...
Dernière mise à jour: 27 février 2007

---

HOWTO replace/upgrade a disk part of a LVM2 volume

This is a quick HOWTO about how to replace/upgrade a hard disk which is part of an LVM2 volume. It is an enhanced version of this document.

This document lists all the steps you needed.

In my situation:

• the physical drive to remove is /dev/hdd and it had one partition (/dev/hdd1) that was 46G big
• the logical volume is: /dev/mapper/backup-vol1, in my /etc/fstab it is mounted as /backup
• the volume group is named backup
• the file system is reiserfs

I’ll put the specific of my situation in italic in the text to ease their change for your real values.

You can’t start this procedure unless you have more free space on your volume than the size of the disk you want to replace.

Before starting, back up your volume! One never knows when Murphy will strike…

Let’s begin. Unmount the logical volume for which you want to replace a disk as most operations can’t be performed with the volume mounted.

umount /backup

If you can't unmount the logical volume, comment its line in /etc/fstab then reboot.

See if a physical volume has free extent by typing:

pvdisplay | grep “Free PE”

If the number following “Free PE” is greater than 0, you have free physical extent.

Typically, the output of the previous command will be like:

--- Physical volume ---
PV Name /dev/hdb
VG Name vg_store1
PV Size 57.23 GB / not usable 0
Allocatable yes (but full)
PE Size (KByte) 4096
Total PE 14651
Free PE 0
Allocated PE 14651
PV UUID 7cryMN-plCs-YuF2-fpxn-BcIJ-OKpG-t3yRQf

If you have more free extent than the number of extent on the drive you want to replace, you can skip the next two steps.

If you don’t you will need to resize the partition to reduce it by the size of the disk you are replacing (see next two steps).

We first want to make sure the volume is error-free.

Check the file system of the logical volume. This is a two steps operation if you use reiserfs. If you use ext2/ext3, there is only one step.

If you use reiserfs as your file system: reiserfsck --check --logfile /tmp/check.log /dev/mapper/backup-vol1 Then, if the first step revealed errors: reiserfsck --fix-fixable –logfile /tmp/fixable.log /dev/mapper/backup-vol1

If you use ext2 or ext3 as your file system, there is only one step: fsck.ext2 –p /dev/mapper/backup-vol1

Then we need to resize the partition. The partition size has to be reduced so we can remove the disk without damaging the data still on the partition. Once again the instructions differs depending on your file system

If you use reiserfs: resize_reiserfs -s -47G /dev/mapper/backup-vol1

If you use ext2 or ext3 (this link may be of interest here.): Resize2fs /dev/mapper/backup-vol1 newsizeofvolume where newsizeofvolume is the size of the initial volume minus the size of the hard drive you are removing/replacing. Note that the volume MUST be offline for this to work.

We can now start the operations to remove the data from the disk we will physically replace. Once the file system size has been reduced, we can reduce the size of the logical volume:

lvreduce -L-47G /dev/backup/vol1

We now move the data out of the physical disk we want to remove:

pvmove /dev/hdd1

Now, as the volume doesn’t have any data on the disk we want to remove, we remove the disk from the volume group:

vgreduce backup /dev/hdd1

Now power down the computer, take your tools and replace the disk we moved the data out of.

Restart the computer.

Create a partition taking the whole disk on the disk you just installed. Set the type of partition to "Linux LVM":

fdisk /dev/hdd

Prepare the physical volume:

pvcreate /dev/hdd1

Add the new physical volume to the volume group:

vgextend backup /dev/hdd1

Expand the logical volume by the capacity just added:
lvextend -L +40G /dev/backup/vol1 /dev/hdd1

Resize the partition to add the capacity just added (I added a 40G hard
disk):

If you use reiserfs: resize_reiserfs -s +40G /dev/mapper/backup-vol1

If you use ext2/ext3: Resize2fs /dev/mapper/backup-vol1 newsizeofvolume where newsizeofvolume is the size of the initial volume plus the size of the hard drive you are adding/replacing. Note that the volume MUST be offline for this to work.

Mount the partition:

mount /dev/mapper/backup-vol1

Since this mount point should be in your /etc/fstab, you do not need to specify the file system type

Done! You have successfully replaced/upgraded a disk in your LVM2 volume.

Last updated on February 27th 2007.