linux raid1 software:ça s'en va et ça revient

**johnclaude** · 05/05/2010, 18h53

C'est possible, moi j'y connais rien je suis ce qu'on me donne.

**AtomicBondage** · 05/05/2010, 19h01

Envoyé par olih

Donc /dev/md0 n'existe plus

. Cool.

On avait un RAID avec deux disques, on en a retiré un du RAID, ledit RAID n'existe plus, non ?

**xheyther** · 05/05/2010, 19h02

Je comprend plus rien... Je sais plus ou on est en c'est un peu chiant. Ça s'étale sur 3 threads je suis tout perdu

Donc is on pouvais reprendre calmement...

**olih** · 05/05/2010, 19h02

Je viens d'avoir une idée complètement folle

.
A essayer d'abord sur le disque fautif histoire de.
(donc ici avec /dev/sdb1)

Code:

sudo mdadm --create /dev/md1 --force --level=raid1 --raid-devices=1 /dev/sdb1
sudo mount /dev/md1 /mnt.

En gros recréer une array avec 1 seul disque et monter l'ensemble. Vu qu'on est en raid1...
C'est un peu débile mais bon je comprends pas vraiment où est passé /dev/md0.

**johnclaude** · 05/05/2010, 19h04

Envoyé par xheyther

Je comprend plus rien... Je sais plus ou on est en c'est un peu chiant. Ça s'étale sur 3 threads je suis tout perdu

Donc is on pouvais reprendre calmement...

Oui, si on pouvait résumer un peu, tranquillement, gentiment avec des flèches et des couleurs pour qu'on sache où on en est, on pourrait peut être reprendre demain. Je jette l'éponge pour ce soir.

**AtomicBondage** · 05/05/2010, 19h05

Donc, reprenons : maintenant, si tu essaie de monter sda1, est-ce que ça marche ?

Je rappelle : "mount /dev/sda1 /lechemindudossiertest -o ro", "-o ro force" si ça ne marche pas le premier coup.

Edit : oui, ok, on reprend demain.

**AtomicBondage** · 05/05/2010, 19h37

Un petit topo:

Dans linux, les données ne sont pas accessibles automatiquement quand on branche le disque (sauf dans les distributions modernes qui ont des scripts pour ça).

Les disques apparaissent dans le dossier /dev/ ("device" en anglais), avec des noms standardisés qui correspondent à leur ordre de détection : sda, sdb, sdc, etc...

Sur chaque disque, il y a des partitions. Les Unix (et donc linux) en font un usage important, alors que sous windows, on n'en entend jamais parler sauf chez les power users. ce sont des subdivisions du disque. On les note sda1, sda2, etc., sdb1, sdb2,etc. Parce que logiquement, on peut avoir plusieurs partitions par disques, mais pas plusieurs disques pour une partition.

Ces partitions sont détectées automatiquement avec fstab ou fdisk ; il faut ensuite les "monter", c'est à dire leur donner une place dans l'arborescence des fichiers. Cette distinction vient de la volonté de faire la différence entre ce qui est accessible au kernel et à l'administrateur seuls (/dev/), et ce qui est accessible à des applications tierces, ou aux utilisateurs courants. On doit donc taper "mount /dev/[nom standardisé de la partition] /[chemin"pratique"par lequel on souhaite accéder au disque, par exemple /mnt/disqueSamsung, ou /home/John/mesVideos, créé auparavant]. C'est plus compliqué mais plus flexible et pratique.

Sauf.... Qu'il y a le RAID, qui est justement une partition dispersée sur plusieurs disques (plus exactement, dispersée sur les partitions de plusieurs disques ^^). Donc pour ça, on marque les disques qui font partie d'un RAID, et se crée un volume "virtuel" (/dev/md0) qui apparait unique alors qu'il comprend plusieurs disques (qui eux-même continuent à apparaître à fstab...). Comme ça, c'est plus simple pour tout le monde d'écrire et de lire les données du RAID : on monte md0, et tout ce qui est duplication/étalement des données est géré par le RAID, bien plus bas.

Là, un des deux disques du RAID a lâché. Le RAID 1 refuse de fonctionner. C'est bien, ça permet de ne pas continuer de s'en servir alors que la sécurité des données n'est pas assurée ; c'est mal, parce que tant qu'il est dans le RAID, on ne peut pas accéder au disque encore sain. C'est du moins ce dont on s'est rendu compte ici, puisque toutes nos tentatives pour y accéder directement ont échoué. Donc il faut qu'on arrive :

à le sortir de la partition RAID virtuelle pour y accéder en tant que disque seul ;
ou a réparer le RAID 1 en lui redonnant un second disque.

Le tout en évitant d'effacer toutes les données. Ce qui peut arriver pour trois raisons :

bug
on recrée une table de partition, ce qui fait perdre l'ancienne, donc l'adresse de toutes les données (récupérables ensuite par des outils ou par un labo spécialisé, mais ça douille)
en réparant le RAID 1, il recopie le disque vide sur le disque plein au lieu de faire l'inverse (c'est pour ça qu'il faut flaguer lequel des deux est mauvais, cf. le post d'olih à 18h07)

**AtomicBondage** · 05/05/2010, 19h53

Les commandes utiles :

sudo, ou su pour rester super-user

fdisk ou fstab, pour lister les disques et les partitions et retrouver leurs noms standardisés

mount, pour accéder au contenu des partitions (réelles (sda1) ou virtuelles (md0)) en les montant dans un dossier créé auparavant (avec mkdir)

mdadm, pour manipuler le RAID : ajouter, retirer des ~~disques~~ partitions et autres manips de gestion comme marquer quel disque est mort :

Déclarer le mauvais disque comme fail (mdadm /dev/md0 -f /dev/mauvaisepartition)
Retirer le mauvais disque du raid (mdadm /dev/md0 -r /dev/mauvaisepartition)
Remettre le "mauvais disque" dans le raid (mdadm /dev/md0 -a /dev/mauvaisepartition)

où la mauvaise partition c'est celle du disque dur WD.

Il y a toujours des surprises : quand on supprime un des deux disques du RAID nommé md0, est-ce que le RAID md0 existe toujours ou est-ce qu'il disparaît logiquement ? L'avis d'un pro est demandé.

A noter que ces manips échouent dès qu'il y a le moindre message d'erreur, sauf si on utilise des options comme "force" (par exemple, pour mount, on ajoute "-o force" après la commande ; "-o" sert à intiquer que ce qui suit est une option que mount doit appliquer (ça peut être "force", ça peut être "ro" pour read-only, etc.). Ce façon de l'écrire est spécifique à mount ; d'autres commandes peuvent avoir d'autres syntaxes).

**sphax.wd** · 05/05/2010, 20h38

AtomicBondage a bien détaillé l'histoire, mais je rajoute une chose:
au démarrage d'un Linux, les volumes logiques d'un raid (donc /dev/md0) ne sont PAS disponibles tout de suite, ils sont activés par les initscripts.
Si vous regardez bien, vous avez soit un script d'init nommé mdraid, ou mdadm. Ces scripts tout ce qu'ils font c'est lancer mdadm pour qu'il crée le périphérique /dev/md0.
C'est donc pour ça que /dev/md0 n'existe pas, il faut simplement l'activer.
Mais apparemment la commande mdadm pour le faire elle marche pas chez johnclaude, c'est bien le problème.
Bon je vais tester ça dans une vm.

**AtomicBondage** · 05/05/2010, 21h17

Justement, je pensais : si le disque dur WD a lâché au démarrage, il n'est plus apparu sous le nom de "sdb". C'est la carte flash qui s'est vu attribuer ce nom. Donc le script a essayé de créer un RAID 1 entre le disque Samsung et la carte flash... Ça se tient comme théorie ? Et ça aurait pu endommager les données du disque Samsung ?

**sphax.wd** · 05/05/2010, 21h25

Le script aurait pu essayer ouais mais mdadm lui aurait balancé une erreur à mon avis, rien que parce la CF n'est pas une partition de type raid. C'est peu probable qu'il ait endommagé les données.

**olih** · 05/05/2010, 21h28

Envoyé par AtomicBondage

Justement, je pensais : si le disque dur WD a lâché au démarrage, il n'est plus apparu sous le nom de "sdb". C'est la carte flash qui s'est vu attribuer ce nom. Donc le script a essayé de créer un RAID 1 entre le disque Samsung et la carte flash... Ça se tient comme théorie ? Et ça aurait pu endommager les données du disque Samsung ?

Je ne pense pas (différence des tailles des partitions + partition non flagguer soft raid). Pour lui il n'y avait qu'un disque dans l'array (cf. photo de JC).
C'est sympa en tout cas de tout remettre à plat comme ça

.
Edit: grilled en plus

.

@sphax.wd, tant que tu es sur ta vm, tu peux tester la création d'un array raid1 d'un seul disque avec celui sorti d'un autre array (donc avec des données dessus). Chez moi ça à l'air de fonctionner mais voila quoi, c'est un peu barbare cf le post au dessus.

Edit bis: Je ne suis même pas sur que le 2e disque est pris tant ça que ça.

**AtomicBondage** · 05/05/2010, 21h44

Il reste un truc que je n'ai plus la force de trier, c'est faire le topo de toutes les commandes tapées par JohnClaude jusqu'ici.

**sphax.wd** · 05/05/2010, 22h12

Bon, voilà ce que j'ai testé sur ma vm:
- deux disques 10G, deux partitions /dev/sda1 et /dev/sdb1
- création du raid: mdadm --create --level=1 --raid-devices=2 /dev/md0 /dev/sda1 /dev/sdb1
- création du fs: mkfs.ext3 /dev/md0
- création de deux fichiers de 100mo: dd if=/dev/urandom of=fichier bs=10M count=10
A ce moment les deux disques étaient synchronisés d'après mdadm --detail.
Bon, je quitte la vm, sur mon pc je wipe la table de partition avec fdisk:
- fdisk ledisque.img, o, w

Je boot la vm, j'assemble l'array à la main:
- mdadm --assemble /dev/md0 /dev/sdb1 (le sda a la table de partition supprimée je rappelle)
- il rale parce qu'un disque manque donc il va pas démarrer l'array
- je fais donc: mdadm --assemble /dev/md0 /dev/sdb1 --run

/dev/md0 est là, ok, je le monte, ça marche, sans même faire de fsck.
Et je retrouve les fichiers de données, évidemment.

Bref, tout ça me fait dire que si un seul des disque est parti en couille, c'est obligé que ça soit récupérable. En plus d'après les fdisk plus haut, la table de partition du disque est encore intacte.

Maintenant, je comprends pas pourquoi jc a eu un "device or resource busy" avec mdadm.

@olih, je suis pas sûr d'avoir compris ce que tu demandais mais je pense que je l'ai fait là.

**olih** · 05/05/2010, 22h21

Envoyé par sphax.wd

Bon, voilà ce que j'ai testé sur ma vm:
- deux disques 10G, deux partitions /dev/sda1 et /dev/sdb1
- création du raid: mdadm --create --level=1 --raid-devices=2 /dev/md0 /dev/sda1 /dev/sdb1
- création du fs: mkfs.ext3 /dev/md0
- création de deux fichiers de 100mo: dd if=/dev/urandom of=fichier bs=10M count=10
A ce moment les deux disques étaient synchronisés d'après mdadm --detail.
Bon, je quitte la vm, sur mon pc je wipe la table de partition avec fdisk:
- fdisk ledisque.img, o, w

Je boot la vm, j'assemble l'array à la main:
- mdadm --assemble /dev/md0 /dev/sdb1 (le sda a la table de partition supprimée je rappelle)
- il rale parce qu'un disque manque donc il va pas démarrer l'array
- je fais donc: mdadm --assemble /dev/md0 /dev/sdb1 --run

/dev/md0 est là, ok, je le monte, ça marche, sans même faire de fsck.
Et je retrouve les fichiers de données, évidemment.

Bref, tout ça me fait dire que si un seul des disque est parti en couille, c'est obligé que ça soit récupérable. En plus d'après les fdisk plus haut, la table de partition du disque est encore intacte.

Maintenant, je comprends pas pourquoi jc a eu un "device or resource busy" avec mdadm.

@olih, je suis pas sûr d'avoir compris ce que tu demandais mais je pense que je l'ai fait là.

Ce que j'ai testé chez moi (et qui est un peu debile)
-deux disques (sdb,sdc) avec chacun une partition raidsoft -> sdb1 et sdc1
-mdadm --create --level=1 --raid-devices=2 /dev/md0 /dev/sdb1 /dev/sdc1
-montage + ecriture de fichier quelconques.
-mdadm /dev/md0 -f /dev/sdc1 (on considere sdc1 fautif)
-mdadm /dev/md0 -r /dev/sdc1 (on le vire du raid)

Attention aux yeux :
-mdadm /dev/md1 --create --level=1 --force --raid-devices=1 /dev/sdc1
(création d'un array de 1 disque avec une partition sortie d'un autre raid, obliger de forcer vu l'idiotie de la manip)
-montage de /dev/md1 -> on retrouve les fichiers.
Bref, c'était pour m'amuser.
"L'avantage" tu dois pouvoir démarrer un array pourvu que d'un seul disque. Bon ça à l'air de marcher car on a du raid1.

**sphax.wd** · 05/05/2010, 22h32

Ok, ben si l'assembler ne fonctionne pas ça serait à tester je pense.

**johnclaude** · 06/05/2010, 15h15

Envoyé par AtomicBondage

Donc, reprenons : maintenant, si tu essaie de monter sda1, est-ce que ça marche ?

Je rappelle : "mount /dev/sda1 /lechemindudossiertest -o ro", "-o ro force" si ça ne marche pas le premier coup.

Edit : oui, ok, on reprend demain.

"sudo mount /dev/sda1 /home/jc/test -o ro force" donne ceci
Utilisation : mount -V : afficher la version
mount -h : afficher cette aide
mount : lister les systèmes de fichiers montés
mount -l : idem, incluant les étiquettes de volumes
Cela pour la partie informative. Suit ce qui porte sur le montage.
La commande est « mount [-t type-sys-fichier] quoi où ».
Les détails se trouvant dans /etc/fstab peuvent être omis.
mount -a [-t|-O] ... : monter tout ce qui est listé dans /etc/fstab
mount périphérique : monter le périphérique à l'endroit connu
mount répertoire : monter le périphérique connu ici
mount -t type périph rép : commande de montage ordinaire
Noter que celle-ci ne monte pas réellement un périphérique, elle monte
un système de fichiers (de type donné) trouvé sur le périphérique.
Elle peut aussi monter une arborescence de rép. déjà visible ailleurs :
mount --bind ancien-rép nouveau-rép
ou déplacer une sous-arborescence:
mount --move ancien-rép nouveau-rép
Elle peut changer le type de montage d'un rép. :
mount --make-shared rép.
mount --make-slave rép.
mount --make-private rép.
mount --make-unbindable rép.
Elle peut changer le type de tous les points de montage d'une
sous-arborecence contenue dans le rép.:
mount --make-rshared rép.
mount --make-rslave rép.
mount --make-rprivate rép.
mount --make-runbindable rép.
Un périph. peut être nommé, comme /dev/hda1 ou /dev/cdrom, ou
repéré par l'étiquette, avec -L étiqu. ou par UUID, avec -U uuid .
Autres options: [-nfFrsvw] [-o options] [-p descr_fic_mots_passe].
Pour plus de détails, tapez "man 8 mount".

**johnclaude** · 06/05/2010, 15h35

Dans le soft "utilitaire de disque" j'ai remarqué un truc.
Quand mes disques sont branchés comme d'habitude, quand je clique sur "modifier les composants" de l'ensemble raid, je n'ai rien de spécial comme option

Tandis que quand je branche le WD (alias le foireux) sur l'autre contrôleur, là par contre il m'apparait un autre truc, qui m'amène à penser que de cette façon là je devrais pouvoir récupérer ce qu'il y a sur le samsung. Je rebranche ça et je vous poste une capture.

Edit: voilà de quoi je voulais parler

**sphax.wd** · 06/05/2010, 15h58

Oui en fait le raid est bon là. Dégradé ça veut juste dire que les deux disques ne sont pas synchronisés.
Moi c'est le "Non partitionné" qui me dérange. Tu peux faire un "mount" ? Et un "cat /proc/mdstat" pour voir si je disais pas de conneries.

**johnclaude** · 06/05/2010, 16h03

Oui pas de soucis, mais je préfère que tu me donnes les commandes complètes à taper, comme j'ai l'impression que c'est récupérable je m'en voudrais de tout flinguer.
Le disque samsung (le bon) est le sda et le western digital (le foireux) est le sdb.

**johnclaude** · 06/05/2010, 16h20

"cat /proc/mdstat" me donne ceci:

Code:

Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md_d0 : active raid1 sdb1[2] sda1[0]
      1953511936 blocks [2/1] [U_]
      [=>...................]  recovery =  7.5% (146773248/1953511936) finish=609.7min speed=49382K/sec
      
unused devices: <none>

Donc le raid se répare là non? (à peine 10 heures à attendre, une broutille)

mount donne

Code:

mount
/dev/sdc6 on / type ext4 (rw,noatime,nodiratime,errors=remount-ro)
proc on /proc type proc (rw,noexec,nosuid,nodev)
none on /sys type sysfs (rw,noexec,nosuid,nodev)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
none on /dev type devtmpfs (rw,mode=0755)
none on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
none on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /tmp type tmpfs (rw)
none on /var/run type tmpfs (rw,nosuid,mode=0755)
none on /var/lock type tmpfs (rw,noexec,nosuid,nodev)
none on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
tmpfs on /var/tmp type tmpfs (rw)
/dev/sdc1 on /boot type ext2 (rw,noatime,nodiratime)

edit: dans mon soft de gestion de disque, à côté de réparation c'est bien une barre de progression, qui a en effet un peu progressé. On dirait que ça marche, réponse dans 10 heures...soit environ quand je me lève.

**sphax.wd** · 06/05/2010, 17h10

Exact, le raid se répare. Et le temps d'attente est normal vu la taille des disques. Une fois qu'il aura fini on verra pour monter l'array.

**johnclaude** · 06/05/2010, 17h28

Envoyé par sphax.wd

Exact, le raid se répare. Et le temps d'attente est normal vu la taille des disques. Une fois qu'il aura fini on verra pour monter l'array.

Crotte moi qui croyais que ça allait tout bien aller tout seul.
Bonne nouvelle, ça semble aller plus vite que prévu (bon j'avais pas non plus rempli les disques, il devait y avoir plus de 100Go quand même)
[===>.................] recovery = 19.6% (384342016/1953511936) finish=360.0min speed=72630K/sec

**AtomicBondage** · 06/05/2010, 17h44

Bien, bonne nouvelle, déjà.

"sudo mount /dev/sda1 /home/jc/test -o ro force" donne ceci
Utilisation : mount -V : afficher la version
mount -h : afficher cette aide
[bla bla bla bla]

My bad, c'est que ma commande était mal rédigée (quand ça arrive, l'ordi redonne le mode d'emploi de la commande, comme c'est le cas ici). Un simple erreur de virgule, d'espace ou de casse (minuscule/majuscule).

~~J'ai relu le man(uel) de mount, il faut écrire "-o ro,force" : une virgule plutôt qu'une espace.~~

Edit: encore raté : en fait, il n'y a pas d'option "force" pour mount. Il intervient en fait seulement avec ntfs-3g d'installé, qui modifie "mount" pour monter des partitions windows (en NTFS, donc). Donc c'est seulement "-o ro" au mieux.

**johnclaude** · 07/05/2010, 03h27

Envoyé par sphax.wd

Exact, le raid se répare. Et le temps d'attente est normal vu la taille des disques. Une fois qu'il aura fini on verra pour monter l'array.

cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md_d0 : active raid1 sdb1[1] sda1[0]
1953511936 blocks [2/2] [UU]

Je c rois qu'on y est.

edit: j'ai fait ça "sudo mount /dev/md_d0 /data"

Spoiler Alert!

**olih** · 07/05/2010, 09h29

Envoyé par johnclaude

cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md_d0 : active raid1 sdb1[1] sda1[0]
1953511936 blocks [2/2] [UU]

Je c rois qu'on y est.

edit: j'ai fait ça "sudo mount /dev/md_d0 /data"

Spoiler Alert!

Oh Joie.
Comme quoi, il était pas vraiment cassé, juste dégradé et la fonction raid1 à fonctionnée

.

Spoiler Alert!

.

**sphax.wd** · 07/05/2010, 09h29

Bon bah si t'as accès aux données c'est cool

**johnclaude** · 07/05/2010, 13h46

Oui le nom /dev/md_d0 a changé par rapport à ce que j'avais avant, en même temps le nom je m'en tamponne.
Ce qui me tue c'est que ça aie marché parce que j'ai branché un disque sur chaque contrôleur,alors que les deux disques étaient bien reconnus avant.

Bref je vais pas essayer de comprendre, tant que ça marche je crois que je vais toucher à rien.

**johnclaude** · 07/05/2010, 15h07

Ce matin ça marchait, mais le NAS était démonté, les disques étaient hors du boitier. J'avais donc éteint ce matin en partant pour remonter le tout en rentrant.
Et là c'est le drame, j'en suis revenu à la première capture du topic: raid non actif partiellement assemblé. Youpi banane, en cas de reboot du nas je devrai me taper la reconstruction à chaque fois on dirait.

**johnclaude** · 07/05/2010, 15h18

Je crois qu'il veut pas réparer (ouai au moins 10 putains d'heures de merde à reconstruire ce putain de raid qui tiendra pas le weekend puisque je devrai encore arrêter le nas pour le déplacer et par la suite pour y rajouter des ventilos que je dois commander) parce qu'il dit que le raid est encore en fonction ou un truc du genre "device /dev/md_d0 is not idle" j'ai essayé de faire "sudo unmount /dev/md_d0 /data" mais il connait pas la commande unmount.

Discussion: linux raid1 software:ça s'en va et ça revient

Outils de la discussion

Règles de messages