Désactivation d'une matrice de fakeraid à deux disques
J'ai un système avec deux disques dans une matrice RAID-1 bi-configurée, actuellement à double amorçage Win7 et Ubuntu 10.10. J'ai opté pour le fakeraid plutôt que pour le logiciel, de sorte que le disque attaqué puisse être vu à la fois sur Win7 (jeux) et sur Ubuntu (tout le reste!). Pour diverses raisons, j'ai décidé de ne plus exécuter ce système avec un disque raid. Par conséquent, j'aimerais deux disques distincts: un pour les deux versions du système d'exploitation et un pour les données.
J'ai supprimé le paramètre RAID dans le BIOS et redémarré. Les deux systèmes d’exploitation démarrent correctement, mais je ne peux pas dire ce qui se passe avec la configuration du disque. Lorsque je liste la table de montage, je conserve les entrées /dev/mapper qui étaient familières avec fakeRAID:
$ Sudo mount | grep /dev
/dev/mapper/pdc_beidbcaig5 on / type ext4 (rw,errors=remount-ro,commit=0)
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)
/dev/dm-1 on /mnt/windows type fuseblk (rw,nosuid,nodev,allow_other,blksize=4096)
/dev/mapper/pdc_beidbcaig9 on /home type ext4 (rw,user_xattr,commit=0)
/dev/mapper/pdc_beidbcaig6 on /var type ext4 (rw,commit=0)
/dev/mapper/pdc_beidbcaig7 on /boot type ext3 (rw,commit=0)
Si je lance gparted, je peux voir les partitions des deux disques en miroir, répertoriées séparément pour /dev/sda et /dev/sdb. Cependant, lorsque je demande des informations sur les partitions affichées dans gparted, un avertissement s'affiche:
Warning: no such file or directory while trying to open /dev/sda5
Couldn't find valid system superblock
dumpe2fs 1.41.12 (17-May-2010)
dumpe2fs: No such file or directory while trying to open /dev/sda5
Unable to read the contents of this file system!
Il est clair que le système de fichiers peut être lu, sinon il ne pourrait pas démarrer. Mais tout aussi clairement, quelque chose ne va pas dans la configuration du disque. Malheureusement, je ne sais pas vraiment par où commencer.
J'ai lu la page de manuel de dmraid et je pensais que l'option -x était ce dont j'avais besoin. Pourtant:
$ Sudo dmraid -x
About to delete RAID set pdc_beidbcaig
WARNING: The metadata stored on the raidset(s) will not be
accessible after deletion
Do you want to continue ? [y/n] :y
ERROR: Raid set deletion is not supported in "pdc" format
En résumé, quelles mesures dois-je prendre pour que mes deux disques RAID-1 précédemment mis en miroir deviennent deux disques indépendants distincts, sur lesquels je peux reformater pour stocker davantage de données?
Merci!
OK, j'ai trouvé des informations utiles dans ce fil . En particulier, faire
Sudo dmraid -rE
était utile, bien que je devais patcher manuellement /etc/fstab après cela, assez raisonnablement. Je ne suis toujours pas sûr d'avoir tout couvert, et je serais heureux de pouvoir expliquer ce que fait dmraid. Les incantations magiques pour "tout améliorer" sont acceptables, mais je préférerais comprendre ce que je fais, du moins en termes généraux!
Intéressant, je pense avoir appris quelque chose de nouveau sur Dmraid aujourd'hui. Le RAID logiciel repose généralement sur le concept d'insérer des métadonnées sur le disque quelque part, puis de prendre en charge ces disques avec un pilote spécial et de les présenter comme un nouveau disque virtuel avec un sur-ensemble de nouvelles fonctionnalités.
Habituellement, si vous supprimez les métadonnées, les données réellement stockées sont perdues, ou du moins, la feuille de route qui l’accompagne. Considérons un RAID 5 où les données sont réparties sur plusieurs disques. En règle générale, vous ne pouvez monter qu'un seul disque, qui était le RAID5 que vous venez de détruire, par conséquent, aucun mappage n'existe pour accéder à vos données.
Je pense que vous abordez le cas trivial de la suppression du provisionnement, étant donné que RAID1 est en réalité un pur miroir de l'autre disque, la position de vos données et de vos tables de partition est logique. Maintenant que les métadonnées ont disparu grâce à dmraid -E, le pilote dmraid n'a plus de raison de réclamer les disques et d'assembler le RAID. Vous ne devriez donc plus jamais voir ces entrées/dev/mapper.
La reconfiguration de votre fstab était une partie nécessaire de la migration. De plus, si vous aviez utilisé des étiquettes de système de fichiers au lieu de points de montage, aucune modification de fstab n'aurait été nécessaire.
Je ne sais pas si cela fait ou non partie de la conception, mais je sais que I ne compterait jamais sur cette fonctionnalité avec mes données . Je ne m'attendrais pas à ce que MD agisse de cette façon. Je pense que vous avez eu beaucoup de chance et que la prochaine fois, vous devriez sauvegarder toutes vos données avant de reconfigurer vos disques de manière invasive.