Möglicherweise hat der Hündchen gerade versucht, Anweisungen in einem anderen Thread zu befolgen, um mein RAID zu verkleinern

456
Klober

Ich habe @Paul ( https://superuser.com/users/89018/paul ) Anweisungen in seiner Antwort auf Shrink RAID verwendet, indem ich eine Festplatte entfernte? aber ich glaube, ich habe einen schrecklichen Fehler gemacht. Hier ist der Knaller ...

Ich habe die 4-TB-Laufwerke in meinem DS1813 + einzeln mit Seagate-Ironwolf-10-TB-Laufwerken aktualisiert. Ich hatte nur noch ein Laufwerk zum Upgrade, überlegte mir jedoch, anstatt den Tag + den Wiederherstellungsprozess des Arrays nach dem Upgrade des Laufwerks und dann durch Pauls Prozess zu durchlaufen. Stattdessen würde ich das 4-TB-Laufwerk während des Verkleinerns einfach aus dem Array entfernen. Ich könnte es versagen. Leider war das nicht der Fall und ich fürchte, es ist jetzt zu spät für meine 22 TB Daten. Hier ist meine PuTTY-Sitzung:

ash-4.3# pvdisplay -C PV VG Fmt Attr PSize PFree /dev/md2 vg1 lvm2 a-- 25.44t 50.62g ash-4.3# cat /proc/mdstat Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] md2 : active raid5 sdf3[13] sdh3[7] sdb3[9] sdg3[6] sde3[12] sdd3[11] sdc3[10] sda3[8] 27316073792 blocks super 1.2 level 5, 64k chunk, algorithm 2 [8/8] [UUUUUUUU]  md1 : active raid1 sdf2[5] sda2[1] sdb2[7] sdc2[2] sdd2[3] sde2[4] sdg2[6] sdh2[0] 2097088 blocks [8/8] [UUUUUUUU]  md0 : active raid1 sdf1[5] sda1[1] sdb1[7] sdc1[2] sdd1[3] sde1[4] sdg1[6] sdh1[0] 2490176 blocks [8/8] [UUUUUUUU]  unused devices: <none> ash-4.3# exit exit Rob@Apophos-DS:~$ df -h Filesystem Size Used Avail Use% Mounted on /dev/md0 2.3G 940M 1.3G 43% / none 2.0G 4.0K 2.0G 1% /dev /tmp 2.0G 656K 2.0G 1% /tmp /run 2.0G 9.8M 2.0G 1% /run /dev/shm 2.0G 4.0K 2.0G 1% /dev/shm none 4.0K 0 4.0K 0% /sys/fs/cgroup cgmfs 100K 0 100K 0% /run/cgmanager/fs /dev/vg1/volume_3 493G 749M 492G 1% /volume3 /dev/vg1/volume_1 3.4T 2.3T 1.1T 69% /volume1 /dev/vg1/volume_2 22T 19T 2.4T 89% /volume2 Rob@Apophos-DS:~$ pvdisplay -C WARNING: Running as a non-root user. Functionality may be unavailable. /var/lock/lvm/P_global:aux: open failed: Permission denied Unable to obtain global lock. Rob@Apophos-DS:~$ sudo su Password: ash-4.3# pvdisplay -C PV VG Fmt Attr PSize PFree /dev/md2 vg1 lvm2 a-- 25.44t 50.62g ash-4.3# mdadm --grow -n5 /dev/md2 mdadm: max_devs [384] of [/dev/md2] mdadm: this change will reduce the size of the array. use --grow --array-size first to truncate array. e.g. mdadm --grow /dev/md2 --array-size 15609185024 ash-4.3# mdadm --grow /dev/md2 --array-size 15609185024 ash-4.3# pvdisplay -C PV VG Fmt Attr PSize PFree /dev/md2 vg1 lvm2 a-- 25.44t 50.62g ash-4.3# mdadm --grow -n6 /dev/md2 mdadm: max_devs [384] of [/dev/md2] mdadm: Need to backup 2240K of critical section.. mdadm: /dev/md2: Cannot grow - need backup-file ash-4.3# mdadm --grow -n5 /dev/md2 mdadm: max_devs [384] of [/dev/md2] mdadm: Need to backup 1792K of critical section.. mdadm: /dev/md2: Cannot grow - need backup-file ash-4.3# mdadm --grow -n5 /dev/md2 --backup-file /root/mdadm.md0.backup mdadm: max_devs [384] of [/dev/md2] mdadm: Need to backup 1792K of critical section.. ash-4.3# cat /proc/mdstat Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] md2 : active raid5 sdf3[13] sdh3[7] sdb3[9] sdg3[6] sde3[12] sdd3[11] sdc3[10] sda3[8] 15609185024 blocks super 1.2 level 5, 64k chunk, algorithm 2 [5/5] [UUUUU] [>....................] reshape = 0.0% (216708/3902296256) finish=3000.8min speed=21670K/sec  md1 : active raid1 sdf2[5] sda2[1] sdb2[7] sdc2[2] sdd2[3] sde2[4] sdg2[6] sdh2[0] 2097088 blocks [8/8] [UUUUUUUU]  md0 : active raid1 sdf1[5] sda1[1] sdb1[7] sdc1[2] sdd1[3] sde1[4] sdg1[6] sdh1[0] 2490176 blocks [8/8] [UUUUUUUU]  unused devices: <none> ash-4.3# cat /proc/mdstat Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] md2 : active raid5 sdf3[13] sdh3[7] sdb3[9] sdg3[6] sde3[12] sdd3[11] sdc3[10] sda3[8] 15609185024 blocks super 1.2 level 5, 64k chunk, algorithm 2 [5/5] [UUUUU] [>....................] reshape = 0.0% (693820/3902296256) finish=3230.3min speed=20129K/sec  md1 : active raid1 sdf2[5] sda2[1] sdb2[7] sdc2[2] sdd2[3] sde2[4] sdg2[6] sdh2[0] 2097088 blocks [8/8] [UUUUUUUU]  md0 : active raid1 sdf1[5] sda1[1] sdb1[7] sdc1[2] sdd1[3] sde1[4] sdg1[6] sdh1[0] 2490176 blocks [8/8] [UUUUUUUU]  unused devices: <none> ash-4.3# cat /proc/mdstat Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] md2 : active raid5 sdf3[13] sdh3[7] sdb3[9] sdg3[6] sde3[12] sdd3[11] sdc3[10] sda3[8] 15609185024 blocks super 1.2 level 5, 64k chunk, algorithm 2 [5/5] [UUUUU] [>....................] reshape = 0.0% (1130368/3902296256) finish=6500.6min speed=10001K/sec  md1 : active raid1 sdf2[5] sda2[1] sdb2[7] sdc2[2] sdd2[3] sde2[4] sdg2[6] sdh2[0] 2097088 blocks [8/8] [UUUUUUUU]  md0 : active raid1 sdf1[5] sda1[1] sdb1[7] sdc1[2] sdd1[3] sde1[4] sdg1[6] sdh1[0] 2490176 blocks [8/8] [UUUUUUUU]  unused devices: <none> ash-4.3# cat /proc/mdstat Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] md2 : active raid5 sdf3[13] sdh3[7] sdb3[9] sdg3[6] sde3[12] sdd3[11] sdc3[10] sda3[8] 15609185024 blocks super 1.2 level 5, 64k chunk, algorithm 2 [5/5] [UUUUU] [>....................] reshape = 0.0% (1442368/3902296256) finish=6667.7min speed=9750K/sec  md1 : active raid1 sdf2[5] sda2[1] sdb2[7] sdc2[2] sdd2[3] sde2[4] sdg2[6] sdh2[0] 2097088 blocks [8/8] [UUUUUUUU]  md0 : active raid1 sdf1[5] sda1[1] sdb1[7] sdc1[2] sdd1[3] sde1[4] sdg1[6] sdh1[0] 2490176 blocks [8/8] [UUUUUUUU]  unused devices: <none> ash-4.3# cat /proc/mdstat Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] md2 : active raid5 sdf3[13] sdh3[7] sdb3[9] sdg3[6] sde3[12] sdd3[11] sdc3[10] sda3[8] 15609185024 blocks super 1.2 level 5, 64k chunk, algorithm 2 [5/5] [UUUUU] [>....................] reshape = 0.4% (18826624/3902296256) finish=6706.8min speed=9650K/sec  md1 : active raid1 sdf2[5] sda2[1] sdb2[7] sdc2[2] sdd2[3] sde2[4] sdg2[6] sdh2[0] 2097088 blocks [8/8] [UUUUUUUU]  md0 : active raid1 sdf1[5] sda1[1] sdb1[7] sdc1[2] sdd1[3] sde1[4] sdg1[6] sdh1[0] 2490176 blocks [8/8] [UUUUUUUU]  unused devices: <none> ash-4.3# Broadcast message from root@Apophos-DS (unknown) at 22:16 ...  The system is going down for reboot NOW! login as: Rob Rob@192.168.81.181's password: Could not chdir to home directory /var/services/homes/Rob: No such file or directory Rob@Apophos-DS:/$ sudo su Password: ash-4.3# cat /proc/mdstat Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] md1 : active raid1 sdh2[7] sdg2[6] sdf2[5] sde2[4] sdd2[3] sdc2[2] sdb2[1] sda2[0] 2097088 blocks [8/8] [UUUUUUUU] [=====>...............] resync = 26.8% (563584/2097088) finish=2.4min speed=10314K/sec  md2 : active raid5 sdh3[7] sdb3[9] sdf3[13] sdg3[6] sde3[12] sdd3[11] sdc3[10] sda3[8] 15609185024 blocks super 1.2 level 5, 64k chunk, algorithm 2 [5/5] [UUUUU] [>....................] reshape = 0.5% (19578240/3902296256) finish=10384.2min speed=6231K/sec  md0 : active raid1 sda1[1] sdb1[7] sdc1[2] sdd1[3] sde1[4] sdf1[5] sdg1[6] sdh1[0] 2490176 blocks [8/8] [UUUUUUUU]  unused devices: <none> 

Nun, mit der Hintergrundgeschichte und der Anzeige aus meinem PuTTY hoffe ich, dass mir jemand sagen kann, wie ich mich abschrauben kann. Ich glaube, dass mein Problem - nachdem ich den Prozess ohne ausreichende Voraussicht, Rücksichtnahme und Verständnis des Prozesses selbst gestartet habe - zweierlei ist: Ich habe das letzte verbleibende 4-TB-Laufwerk nicht vorher versagt, sodass die Berechnungen auf dem kleinsten 4-TB-Laufwerk basieren (Wahrscheinlich nicht berücksichtigt die 70 TB Speicherplatz zwischen den anderen 7 Laufwerken) und möglicherweise meine mdadm --grow Befehle von verschiedenen -n #.

 ash-4.3# mdadm --grow -n5 /dev/md2 mdadm: max_devs [384] of [/dev/md2] mdadm: this change will reduce the size of the array. use --grow --array-size first to truncate array. e.g. mdadm --grow /dev/md2 --array-size 15609185024 ash-4.3# mdadm --grow /dev/md2 --array-size 15609185024 ash-4.3# pvdisplay -C PV VG Fmt Attr PSize PFree /dev/md2 vg1 lvm2 a-- 25.44t 50.62g ash-4.3# mdadm --grow -n6 /dev/md2 mdadm: max_devs [384] of [/dev/md2] mdadm: Need to backup 2240K of critical section.. mdadm: /dev/md2: Cannot grow - need backup-file ash-4.3# mdadm --grow -n5 /dev/md2 mdadm: max_devs [384] of [/dev/md2] mdadm: Need to backup 1792K of critical section.. mdadm: /dev/md2: Cannot grow - need backup-file ash-4.3# mdadm --grow -n5 /dev/md2 --backup-file /root/mdadm.md0.backup mdadm: max_devs [384] of [/dev/md2] mdadm: Need to backup 1792K of critical section.. 

Hier ist die aktuelle Ausgabe von cat / proc / mdstat. Ich habe festgestellt, dass / dev / md2 im Vergleich zu den 8Us der anderen mds nur 5 Us zeigt. Das macht mir Angst, da sich alle auf derselben RAID-Gruppe von 8 Festplatten befinden:

ash-4.3# cat /proc/mdstat Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] md1 : active raid1 sdh2[7] sdg2[6] sdf2[5] sde2[4] sdd2[3] sdc2[2] sdb2[1] sda2[0] 2097088 blocks [8/8] [UUUUUUUU]  md2 : active raid5 sdh3[7] sdb3[9] sdf3[13] sdg3[6] sde3[12] sdd3[11] sdc3[10] sda3[8] 15609185024 blocks super 1.2 level 5, 64k chunk, algorithm 2 [5/5] [UUUUU] [>....................] reshape = 1.2% (48599680/3902296256) finish=6495.2min speed=9888K/sec  md0 : active raid1 sda1[1] sdb1[7] sdc1[2] sdd1[3] sde1[4] sdf1[5] sdg1[6] sdh1[0] 2490176 blocks [8/8] [UUUUUUUU]  unused devices: <none> 

Zumindest muss ich / dev / vg1 / volume_1 speichern können. Ich hoffe, da ich dieses Volume nicht angefasst habe, ist es möglich, aber zu diesem Zeitpunkt weiß ich nicht, da alle drei Volumes in DSM als "Crashed" aufgeführt sind. Ich hoffe (aber nicht hoffnungsvoll), dass nach Abschluss der Konsistenzprüfung alles in Ordnung sein wird.

Jeder, der mdadm kennt, brauche dringend Ihre Hilfe! Paul, wenn du da draußen bist, brauche ich deine Hilfe! Ich weiß, dass ich es vermasselt habe, und es besteht eine gute Chance, dass ich alles verloren habe, aber wenn Sie irgendetwas vermuten, dass es eine Chance gibt, meinen Speck zu retten, helfen Sie bitte!

Update (05.12.17): Keine Änderung, außer die Umformung schreitet fort - bis zu 17,77%. DSM zeigt weiterhin alle Volumes als "Crashed (Überprüfen der Paritätskonsistenz 17,77%)" an, während die Festplattengruppe "Festplatten im Hintergrund überprüfen (Überprüfung der Paritätskonsistenz 17,77%)" angibt. Hier ist ein Bild der Plattengruppe:

Image of the disk group

Ich glaube, der entscheidende Schritt, den ich verpasst habe, war entweder das Ausführen mdadm /dev/md2 --fail /dev/sdf3 --remove /dev/sdf3oder das manuelle Entfernen des Laufwerks - dies hätte das verbleibende 4-TB-Laufwerk ausfallen lassen und es aus dem Array entfernt, so dass mir ein 7 x 10 TB schlechtes RAID 5-Array übrig blieb. Meine Frage ist nun - sollte ich warten, bis das Array fertig konfiguriert ist, um das 4-TB-Laufwerk zu entfernen? Oder sollte ich jetzt weitermachen und es jetzt versagen / entfernen? Mein schwachsinniges Gefühl sagt, dass das Entfernen eines Laufwerks während eines Umbaus / einer Umgestaltung schlecht ausfallen wird, da ich das immer gelehrt habe, aber ich weiß nicht, ob dies in dieser Situation unbedingt der Fall ist, in der mdadm versucht, 7 Laufwerke zu stopfen Platz für 5 Laufwerke, die ausschließlich auf der Größe des verbleibenden 4-TB-Laufwerks basieren.

Falls es hilfreich ist, ist hier die Ausgabe von mdadm -D /dev/md2:

/dev/md2: Version : 1.2 Creation Time : Wed Mar 5 22:45:07 2014 Raid Level : raid5 Array Size : 15609185024 (14886.08 GiB 15983.81 GB) Used Dev Size : 3902296256 (3721.52 GiB 3995.95 GB) Raid Devices : 5 Total Devices : 8 Persistence : Superblock is persistent  Update Time : Tue Dec 5 17:46:27 2017 State : clean, recovering Active Devices : 8 Working Devices : 8 Failed Devices : 0 Spare Devices : 0  Layout : left-symmetric Chunk Size : 64K  Reshape Status : 18% complete Delta Devices : -3, (5->2)  Name : DS:2 (local to host DS) UUID : UUID Events : 153828  Number Major Minor RaidDevice State 7 8 115 0 active sync /dev/sdh3 8 8 3 1 active sync /dev/sda3 10 8 35 2 active sync /dev/sdc3 11 8 51 3 active sync /dev/sdd3 12 8 67 4 active sync /dev/sde3  6 8 99 5 active sync /dev/sdg3 9 8 19 7 active sync /dev/sdb3 13 8 83 6 active sync /dev/sdf3 

Was mir Sorgen macht, ist, dass die Array-Größe mit 16 TB angegeben wird, wenn die Gesamtgröße der Daten im Array über 20 TB lag. Ich bin mir nicht sicher, was ich jetzt tun soll. Jeder Gedanken oder Erfahrung wäre sehr dankbar!

3
Ja, du hast es vermasselt. Wenn Sie noch über die Originaldisketten verfügen, können Sie den Vorgang möglicherweise wiederholen, indem Sie das Original-Raid (dh mit Ihrer Originaldiskette) neu erstellen. Sie sollten jedoch jedes Laufwerk klonen, bevor Sie das tun. Sie sollten niemals eine Festplatte entfernen, während ein RAID neu erstellt wird Ramhound vor 6 Jahren 0
Glücklicherweise habe ich den Prozess mit dem RAID 5 im Normalbetrieb mit 7 10-TB-Laufwerken und 1 4-TB-Laufwerk gestartet (Konfiguration ist 10/10/10/10/10/10/4/10), und ich habe noch keine Laufwerke entfernt Weg (sogar herausspringen und direkt wieder rein), seit ich den Prozess begann. Leider weiß ich nicht genug über das Umformen, um genau zu wissen, was es tut. Wie gehe ich vor, um die von mir ausgeführten Befehle rückgängig zu machen (natürlich nachdem der Prozess abgeschlossen ist)? Klober vor 6 Jahren 0
Du solltest es in Ruhe lassen. Warten Sie, bis alles erledigt ist. Wenn Sie an dieser Stelle ein Laufwerk entfernen, bleibt nichts übrig. Ramhound vor 6 Jahren 0
Vielen Dank für die Bestätigung, @Ramhound. Ich werde nichts anfassen, bis der Umformungsprozess abgeschlossen ist. Zu diesem Zeitpunkt befinde ich mich im Modus zum Sammeln von Informationen. Ich möchte so viel wie möglich über das, was ich getan habe, herausfinden, einschließlich der Schritte, die ich machen muss, wenn der Prozess abgeschlossen ist, damit ich sie gründlich recherchieren und verstehen kann, bevor ich andere möglicherweise katastrophale Schritte unternehme. Jede Hilfe zu diesem Zweck wird sehr geschätzt! Klober vor 6 Jahren 0
Gute RAID 5-Regel, um durch blinkende Blinky (rot oder gelb) zu leben, ohne anfällig zu wirken. Ramhound vor 6 Jahren 0
Aufgrund meiner Recherchen bin ich leider SOL. Laut der mdadm-Manpage war alles bis zum Befehl `mdadm --grow -n5 / dev / md2 --backup-file / root / mdadm.md0.backup` reversibel. Wenn jemand etwas weiß, das dieser Schlussfolgerung widerspricht, lassen Sie es mich wissen! Klober vor 6 Jahren 0

0 Antworten auf die Frage