RAID0 en cours: Formatage funeste ?

Bonjour à tous,

Depuis la première installation (Squeeze ou peut-être même la version précédente), je n’ai jamais eu à toucher au RAID initial (sur 2 grosses partitions /dev/sdc4 et /dev/sdf4 de 2 disques d’1 To chacun)

En dehors de / et /boot (ext4), tout est monté sur ce raid0, en LVM:
/usr
/usr/local
/var
/home
(en XFS)

j’ai fait une manoeuvre maladroite:

j’ai lancé - sous gparted - la création d’une table de partitions DOS sur mon RAID (/dev/md0).

Le système tourne encore sans problème, mais je n’ose pas l’arréter !

L’utilitaire de disque de gnome2 montre que le raid est dans l’état «actif» et son Action « au repos»

L’utilitaire de test (en lecture seule) comme celui de vérification indiquent une erreur: «le service a été inhibé» ( Daemon is inhibited)

Que dois-je craindre ?
Y-a-t il un risque à arréter le système ?
Peut-on simplement réactiver le système, (et comment) ?

Dans les «services» listés par gnome, je trouve, comme habituellement, je crois:
mdadm activé
et
mdadm-raid désactivé

Merci à tous

SUITE

gparted annonce maintenant: non alloué !

(mdadm est documenté en anglais et me dépasse donc doublement.)

/proc/mdstat indique:

Personalities : raid0
md0 : active raid0 sdc4[0] sdf4[1]
1913469824 blocks 64k chunks

unused devices: <none>

D’après ce que j’ai lu, il devrait y avoir «UU» en fin de l’avant dernière ligne (à la place de 64k chunks)

Suite de l’enquète:
#mdadm --detail /dev/md0.txt

[code]/dev/md0:
Version : 0.90
Creation Time : Sat Oct 23 16:22:00 2010
Raid Level : raid0
Array Size : 1913469824 (1824.83 GiB 1959.39 GB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 0
Persistence : Superblock is persistent

Update Time : Sat Oct 23 16:23:48 2010
      State : clean

Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0

 Chunk Size : 64K

       UUID : f9ac3b5b:3475787b:38243c98:72e267ba
     Events : 0.3

Number   Major   Minor   RaidDevice State
   0       8       36        0      active sync   /dev/sdc4
   1       8       84        1      active sync   /dev/sdf4[/code]

Il dit être «clean».

Suite:
#mdadm --examine --scan

qui correspond à la dernière ligne du fichier /etc/mdadm/mdadm.conf

Mais:
#mdadm --examine /dev/md0

Ne serait-ce pas ce superblock qui aurait été détruit par le formatage inopiné ?

Existe-t-il une commande pour le récréer ? (surement ! mais laquelle: mdadm Assemble ?)

En attendant votre aide…
j’angoisse… :102

[quote=“josephtux”]#mdadm --examine /dev/md0
mdadm: No md superblock detected on /dev/md0[/quote]
Normal. L’option --examine ou -E s’applique à une partition membre comme /dev/sdc4 ou /dev/sdf4, pas à un ensemble comme /dev/md0. Les superblocs RAID sont dans les membres, pas dans l’ensemble résultant. Tout ce que tu écris dans /dev/md0 n’a aucun impact sur sa santé.

Par contre cela peut en avoir sur la santé de ce qu’il contient, à savoir le PV LVM.

L’en-tête (label) d’un PV LVM est située par défaut dans le second secteur du volume, ce qui laisse le premier secteur libre pour y installer une amorce par exemple. Donc la création d’une table de partition MSDOS dans le premier secteur du volume pourrait laisser le reste intact. Hélas, je viens de tester que parted efface aussi au moins le second secteur lorsqu’il crée une table de partition MSDOS, probablement pour effacer un éventuel en-tête GPT primaire qui est situé aussi dans ce second secteur (et peut-être aussi le dernier secteur pouvant contenir un en-tête GPT secondaire). Si gparted fait de même, ce que je crains, alors l’en-tête LVM du volume a été effacé. Tu peux utiliser les commandes suivantes pour le vérifier :

pvscan pvck /dev/md0
Si le PV n’est pas trouvé, tu peux essayer de le restaurer, voir la page de manuel de [mono]vgcfgrestore[/mono]. Je n’ai jamais utilisé cet outil.

Grand merci PascalHambourg pour ces précisions techniques claires et précises. :038

En plus de la pédagogie, cela me rassure, car le LVM dispose d’un miroir sur un disque indépendant du raid.

Je vais voir du coté du LVM avant d’éteindre.

À bientôt

Suite:
#pvck /dev/md0
Could not find LVM label on /dev/md0

#pvscan VG_tout
Couldn’t find device with uuid 4ilENG-Ikcs-uxjV-U8QN-olPL-jmfj-qmv0yi.
PV /dev/sdg1 VG VG_USB3 lvm2 [931,51 GiB / 31,51 GiB free]
PV unknown device VG VG_tout lvm2 [1,78 TiB / 302,96 GiB free]
PV /dev/sdd1 VG VG_tout lvm2 [1,81 TiB / 331,39 GiB free]
PV /dev/sdd2 VG VG_tout lvm2 [9,76 GiB / 9,75 GiB free]
PV /dev/sde1 VG VG_BKP_data lvm2 [1,82 TiB / 0 free]
PV /dev/sdb3 VG VG_BKP_data lvm2 [193,36 GiB / 3,36 GiB free]
PV /dev/sda1 VG VG_system lvm2 [100,00 GiB / 73,00 GiB free]
PV /dev/sdb2 lvm2 [48,83 GiB]
PV /dev/sdb5 lvm2 [195,32 GiB]
PV /dev/sdb6 lvm2 [122,07 GiB]
PV /dev/sdb7 lvm2 [122,07 GiB]
PV /dev/sdb8 lvm2 [97,65 GiB]
PV /dev/sdb9 lvm2 [103,39 GiB]
Total: 13 [7,29 TiB] / in use: 7 [6,62 TiB] / in no VG: 6 [689,33 GiB]

Il y manque effectivement les 2 composants du raid md0:
/dev/sdc4 et /dev/sdf4

En cherchant la commande qui permet d’isoler le mirroir (sur /dev/sdd1 ou /dev/sdd2), avant de risquer un vgcfgrestore j’ai retrouvé la commande:
lvconvert --repair.

Je ne suis pas encore sûr de la commande pour isoler le miroir, et j’hésite entre l’usage de ces 2 commandes: vgcfgrestore, sans doute plus simple (mais par prudence je préfèrerais isoler d’abord le miroir) ou lvconvert --repair , dont je ne suis pas sûr qu’elle fasse ce que je souhaite.

Je continue à chercher.

Échec de la restauration par vgcfgrestore

#vgcfgrestore -f /etc/lvm/backup/VG_tout VG_tout Couldn't find device with uuid 4ilENG-Ikcs-uxjV-U8QN-olPL-jmfj-qmv0yi. Cannot restore Volume Group VG_tout with 1 PVs marked as missing. Restore failed.

[quote=“josephtux”]Il y manque effectivement les 2 composants du raid md0:
/dev/sdc4 et /dev/sdf4[/quote]
Non, c’est normal qu’ils ne soient pas mentionnés. Ces partitions servent de support au volume RAID /dev/md0 et c’est ce dernier qui sert de support au PV LVM. Il n’y a aucun lien direct entre les partitions et le PV.

[quote=“PascalHambourg”][quote=“josephtux”]Il y manque effectivement les 2 composants du raid md0:
/dev/sdc4 et /dev/sdf4[/quote]
Non, c’est normal qu’ils ne soient pas mentionnés. Ces partitions servent de support au volume RAID /dev/md0 et c’est ce dernier qui sert de support au PV LVM. Il n’y a aucun lien direct entre les partitions et le PV.[/quote]

ça, je crois l’avoir bien compris.

Mais le lien entre le RAID et le VG ne me paraît plus si clair: :017

(1) Réparer le LVM suffirait-il à restaurer le RAID sur lequel il repose ? (ce que j’avais cru comprendre).

Dans ce cas la restauration «automatique» à partir du miroir est-elle envisageable sans risque ? (lvconvert --repair)

Un restauration après avoir détaché le miroir est-elle possible ? plus sûre ?

pour mémoire:#vgcfgrestore -f /etc/lvm/backup/VG_tout VG_tout Couldn't find device with uuid 4ilENG-Ikcs-uxjV-U8QN-olPL-jmfj-qmv0yi. Cannot restore Volume Group VG_tout with 1 PVs marked as missing. Restore failed.

(2) Pourquoi le RAID0 lui-même (md0) n’apparaît-il pas, indépendamment de son contenu (Une partie du VG_tout)

Ne faut-il pas réparer le RAID avant le LVM ? (si oui comment ?)

#pvscan VG_tout
PV unknown device VG VG_tout lvm2 [1,78 TiB / 302,96 GiB free] = le VG sur le RAID

PV /dev/sdd1 VG VG_tout lvm2 [1,81 TiB / 331,39 GiB free] = le miroir (qui semble heureusement sain)
PV /dev/sdd2 VG VG_tout lvm2 [9,76 GiB / 9,75 GiB free] = le log du miroir

J’ai encore du chemin à faire… :think:

[EDIT]:

$cat /proc/mdstat Personalities : [raid0] md0 : active raid0 sdc4[0] sdf4[1] 1913469824 blocks 64k chunks

unused devices:

Dans cette situation, que ferait la commande:

trouvée ici:
superuser.com/questions/589206/r … cover-data

et là:
linuxpedia.fr/doku.php/expert/mdadm

Une autre idée ( farfelue ? casse-cou ?)

[size=120]Si je reboote, est-ce que le miroir LVM prendra automatiquement le relai du système cassé?[/size] ou dois-je d’abord modifier quelquechose (/etc/fstab …)

[size=85]Pour mémoire la racine / et /boot/ ne sont pas affectées: ils sont sur 2 partitions séparées, pas en LVM, et en ext4
Par contre /usr, /usr/local et /var sont montées sur des LV du même groupe que /home : VG_tout
[/size]

Car si c’est la cas, je pourrai alors recréer le RAID0, puis en faire à son tour le miroir, voire me passer de RAID0 et recréer directement un miroir LVM, peut-être plus rapide que le système actuel.
(Le RAID0 doublait la vitesse d’accès, ce qui était très appréciable. Mais avec le miroir LVM, ce bénéfice a disparu.)

Est-ce que de renoncer au RAID0 me ferait encore perdre en vitesse d’accès ?

Pour le moment, je cherche, je conjecture, j’hypothèse… et n’ose toujours pas rebooter !

merci pour votre intérêt.

Je répète : ne te préoccupe pas de ton RAID 0. Il marche très bien et n’a pas été altéré. C’est le PV qui est dedans, et donc le VG qui emploie ce PV, et donc les LV contenus dans ce VG qui ont été potentiellement altérés.

Concernant le miroir LVM, c’est une fonctionnalité que je n’ai jamais utilisée.

En tout cas, redémarrer ne me semble pas une bonne idée.

OK
merci PascalHambourg, je continue à chercher dans cette voie

La commande

n’est pas la solution:

Couldn't find device with uuid 4ilENG-Ikcs-uxjV-U8QN-olPL-jmfj-qmv0yi. Mirror status: 1 of 2 images failed. Attempt to replace failed mirror images (requires full device resync)? [y/n]: y The link /dev/VG_tout/home_mimage_1 should had been created by udev but it was not found. Falling back to direct link creation. The link /dev/VG_tout/home_mimage_1 should have been removed by udev but it is still present. Falling back to direct link removal. Trying to up-convert to 2 images, 1 logs. Insufficient free space: 384000 extents needed, but only 87332 available Unable to allocate extents for mirror(s). Trying to up-convert to 2 images, 0 logs. Insufficient free space: 384000 extents needed, but only 87332 available Unable to allocate extents for mirror(s). WARNING: Failed to replace 1 of 1 logs in volume home

Si j’ai bien compris:
Apparemment cette commande reconnaît que l’une des images du miroir est cassée, mais cherche un 3e espace pour le réparer (L’originale occupe un LVM de 1.78 TiB, le miroir 1.81 TiB)

D’autre part, le message:

est obscur pour moi, car d’une part, la commande convert --repair prétend réparer un miroir cassé en rétablissant si possible le même nombre d’image (si j’ai bien traduit le man en anglais), d’autre part je crois comprendre que ce message demande de démonter «by udev» l’image 1 (syntaxe:le miroir = m1 , l’original = m0), c’est-à-dire l’mage intacte.

J’ai bien trouvé de nombreuses citations de lvconvert --repair, mais rien de plus que le man

Ma question reste donc jusqu’ ici: comment réparer le LVM… (avant la première coupure d’électricité !)

Après réflexion: peut-être l’espace manquant est justement celui supporté par le RAID, c’est à dire les partitions physiques devenues introuvables,
Donc: la question devient alors, en premier: comment remettre /dev/sdc4 et /dev/sdf4 dans le VG_tout (sans mettre en panne)

Ce que je ne comprends pas, c’est que… malgré tout, ça marche.
( Dans /proc/ , tout [ce que j’ai vu] semble normal ).
C’est peut-être aussi ce que la commande «ne comprend pas»:

Ce vgcfgrestore a dit:

#vgcfgrestore -f /etc/lvm/backup/VG_tout VG_tout Couldn't find device with uuid 4ilENG-Ikcs-uxjV-U8QN-olPL-jmfj-qmv0yi. Cannot restore Volume Group VG_tout with 1 PVs marked as missing. Restore failed.
C’est qu’il ne trouve pas un PV du groupe, avec l’ uuid 4ilENG-…
(et moi non plus) [EDIT: il est dans /etc/lvm/backup/VG_tout et correspond au RAIDO]
Celui du RAID (md0) devenu invisible est:

Bref je continue à patauger dans la semoule (de bits).

Encore merci

EDIT
ça marche probablement déja sur l’image md1

en effet:

[size=75]#lvs -a -o +devices | egrep VG_tout Couldn't find device with uuid 4ilENG-Ikcs-uxjV-U8QN-olPL-jmfj-qmv0yi. home VG_tout -wi-ao 1,46t /dev/sdd1(0) usr VG_tout mwi-ao 10,00g usr_mlog 100,00 usr_mimage_0(0),usr_mimage_1(0) usr_local VG_tout mwi-ao 1,86g usr_local_mlog 100,00 usr_local_mimage_0(0),usr_local_mimage_1(0) [usr_local_mimage_0] VG_tout iwi-ao 1,86g unknown device(145435) [usr_local_mimage_1] VG_tout iwi-ao 1,86g /dev/sdd1(386560) [usr_local_mlog] VG_tout lwi-ao 4,00m /dev/sdd2(2) [usr_mimage_0] VG_tout iwi-ao 10,00g unknown device(144243) [usr_mimage_0] VG_tout iwi-ao 10,00g unknown device(145911) [usr_mimage_1] VG_tout iwi-ao 10,00g /dev/sdd1(384000) [usr_mlog] VG_tout lwi-ao 4,00m /dev/sdd2(1) var VG_tout mwi-ao 10,00g var_mlog 100,00 var_mimage_0(0),var_mimage_1(0) [var_mimage_0] VG_tout iwi-ao 10,00g unknown device(143051) [var_mimage_0] VG_tout iwi-ao 10,00g unknown device(147279) [var_mimage_1] VG_tout iwi-ao 10,00g /dev/sdd1(387036) [var_mlog] VG_tout lwi-ao 4,00m /dev/sdd2(3)[/size]

sdd1 sdd2 supportent les «image_1», et tout ce qui est « image_0 » est unknown device

Ça ne m’avance guère, mais vous, peut-être ?

Suite

Je relance la même commande, dans l’intention de répondre «n» au lieu de «y» , pour transformer le miroir en «lvm linéaire»

#lvconvert --repair VG_tout/home Couldn't find device with uuid 4ilENG-Ikcs-uxjV-U8QN-olPL-jmfj-qmv0yi. Can't repair non-mirrored LV "home".

Ce qui semble être déjà fait ! (sans doute par la même commande lors de l’échec précédent)
(sinon le niveau de la semoule monte dangereusement !)

J’ai donc fait la même chose sur les autre lv , et retrouve ainsi un système sans miroir (et toujours sans les PV du raid):

[code]#lvs -a
Couldn’t find device with uuid 4ilENG-Ikcs-uxjV-U8QN-olPL-jmfj-qmv0yi.
LV VG Attr LSize Origin Snap% Move Log Copy% Convert

home VG_tout -wi-ao 1,46t
usr VG_tout -wi-ao 10,00g
usr_local VG_tout -wi-ao 1,86g
var VG_tout -wi-ao 10,00g[/code]

Si j’ai bien compris:
Reste à réparer les PV de /sdc4 et /sdf4 pour que le raid md0 refasse surface, et puisse devenir le prochain miroir.

1 donner le drapeau PV à chaque partition:

2 en faire chacun un PV:
pvcreate

3 les inclure au VG_tout:

4 recréer les miroirs pour les LV de /home /var /usr /usr_local:

Résultat:

[code]#gparted set /dev/sdc4 lvm on

libparted : 2.3

Could not stat device set - Aucun fichier ou dossier de ce type.
Unable to open /etc/lvm read-write (est un dossier). /etc/lvm has been opened read-only.
Unable to open /etc/lvm read-write (est un dossier). /etc/lvm has been opened read-only.
/etc/lvm: unrecognised disk label
Could not stat device on - Aucun fichier ou dossier de ce type.

#pvcreate /dev/sdc4
Can’t open /dev/sdc4 exclusively. Mounted filesystem?[/code]

ça se complique !

EDIT

vgdisplay trouve:
#vgdisplay
Couldn’t find device with uuid 4ilENG-Ikcs-uxjV-U8QN-olPL-jmfj-qmv0yi.
— Volume group —
VG Name VG_tout
[size=65] System ID
Format lvm2
Metadata Areas 2
Metadata Sequence No 43
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 4
Open LV 4
Max PV 0
Cur PV 3
Act PV 2[/size]
VG Size 3,60 TiB qui prend donc en compte: /sdc4 + /sdf4 = md0 = 1.8 TiB (environ)
[size=65]PE Size 4,00 MiB
Total PE 944086
Alloc PE / Size 389596 / 1,49 TiB
Free PE / Size 554490 / 2,12 TiB
VG UUID WNch0K-2tKi-u36w-ZosX-Q3ck-vKtQ-Brzm0w[/size]

AUTRE INFO:
j’ai retrouvé une vielle sauvegarde de /etc/lvm/backup/VG_tout
La différence avec le même fichier actuel, [size=85](après toutes les manoeuvres décrites ici précédemment)[/size] c’est la ligne

qui est remplacée par:
device = "unknown device" # Hint only

Dans le paragraphe suivant, où on voit que l’id disparu est celui du physical volume représentant le RAID.

[code]physical_volumes {

            pv0 {
                    id = "4ilENG-Ikcs-uxjV-U8QN-olPL-jmfj-qmv0yi"
                    device = "unknown device"	# Hint only
                    

                    status = ["ALLOCATABLE"]
                    flags = []
                    dev_size = 3826939648   # 1,78206 Terabytes
                    pe_start = 384
                    pe_count = 467155       # 1,78205 Terabytes
            }

[/code]

La question reste entière.

Je ne sais plus comment te le dire, tu mélanges encore les couches entre les membres de l’ensemble RAID et les PV membres du VG.
Les partitions /dev/sdc4 et /dev/sdf4 ne sont que les membre du volume RAID /dev/md0, il ne faut pas y toucher. Le PV manquant était dans le volume RAID /dev/md0.

Oui Pascal, je crois l’avoir compris. mais j’ai l’impression de me trouver dans la situation du serpent qui se mord la queue:
Je ne parviens pas à réparer le LVM car il ignore le raid0 (md0)

Avec lvconvert --repair, j’espère avoir rétabli un lvm linéaire basé sur la 2e image (celle qui n’était pas sur le RAID), mais des incohérences subsistent dans le LVM, comme le vgdisplay qui affiche un espace du VG prenant en compte la partie «perdue» du VG, c’est à dire celle du «PV /RAID0».

La commande de réparation du miroir n’a pas fonctionné parceque le raid est invisible(je crois), et n’a pas trouvé la place suffisante (pourtant encore mesurée par vgdisplay)

Je ne vois plus comment m’y prendre.

Une idée, peut-être hasardeuse, faire vgreduce --removemissing pour rétablir les partitions (sur le RAID0) dans un état brut, sans LVM ? (si j’ai bien compris, commande pour supprimer du VG proprement les PV manquants)

Encore merci pour ton aide précieuse.

EDIT
si j’ai bien compris, l’uuid manquant est celui du PV correspondant au RAID complet. Et mon problème c’est de réparer ou recréer ce PV.

/dev/md0 est ignoré par LVM parce qu’en créant une table de partition dedans tu as effacé l’en-tête LVM, donc il n’est plus reconnu comme un PV.

D’une façon ou d’une autre, il faut redéfinir /dev/md0 comme un PV. Mais je ne connais pas la méthode appropriée.

pvcreate avec un nouvel UUID, puis l’ajouter au VG et reconstruire le miroir ?
pvcreate avec le même UUID qu’avant, mais comment va-t-il être traité ensuite ?

Encore merci

j’essaie et je reviens.

[EDIT
d’après man pvcreate, avec l’option -uuid, seuls les secteurs nécessaires seront remplacés, sinon, par défaut 4 secteurs =2048 Octets seront “nettoyés”, de même avec l’option --restorefile (quel fichier ?) ou avec -Z.

je vais donc commencer par la tentative la moins destructrice, celle avec --uuid et l’uuid perdu., puis si nécessaire avec un nouvel uuid, et enfin sans cette option]

La ligne suivante va être tentée:

La réponse:

#pvcreate -uuid 4ilENG-Ikcs-uxjV-U8QN-olPL-jmfj-qmv0yi /dev/md0 Can only set uuid on one volume at once Run `pvcreate --help' for more information.

donc:

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

Mais, jusqu’ici rien de neuf avec pvdisplay:

[code]#pvdisplay
Couldn’t find device with uuid 4ilENG-Ikcs-uxjV-U8QN-olPL-jmfj-qmv0yi.
— Physical volume —
PV Name unknown device
VG Name VG_tout
PV Size 1,78 TiB / not usable 2,88 MiB
Allocatable yes
PE Size 4,00 MiB
Total PE 467155
Free PE 467155
Allocated PE 0
PV UUID 4ilENG-Ikcs-uxjV-U8QN-olPL-jmfj-qmv0yi

— Physical volume —
PV Name /dev/sdd1
…[/code]

D’après la page de manuel de pvcreate, l’option --uuid doit être accompagnée de l’option --norestorefile ou --restorefile , selon ce qu’on veut faire. Le fichier est celui du VG correspondant dans /etc/lvm/backup/ ou /etc/lvm/archive/, listé par [mono]vgcfgrestore -l [/mono]. Ensuite il est indiqué d’exécuter [mono]vgcfgrestore -f [/mono] avec ce même fichier. Mais je ne ne sais pas du tout ce que ça va donner après tes précédentes manipulations, d’autant que c’est censé restaurer les méta-données lors du remplacement d’un PV manquant, mais tu voudrais juste que le PV soit à nouveau reconnu comme tel. Est-ce que le PV sera réintégré tel quel, est-ce qu’une reconstruction du miroir va avoir lieu dessus, je n’en sais rien.

Tu as une sauvegarde des données de ce VG ?