[SOLVED] RAID will nicht synchronisieren

dma67 · 30 Okt. 2011

Hallo liebe Community,

ich bin mit meinem Latein am Ende.

Ich habe hier in meinem Server 8 Platten im RAID-Verbund.

Mit 2 Platten habe ich Probleme.
* sda3 + sde3
* sda4 + sde4

RAID-Situation

Code:

Phenom940:/home/dma # cat /proc/mdstat
Personalities : [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] 
md4 : active raid10 sdg1[0] sdh1[1]
      976760672 blocks super 1.0 2 near-copies [2/2] [UU]
      bitmap: 3/466 pages [12KB], 1024KB chunk

md3 : active raid10 sdc1[0] sdd1[1]
      976760672 blocks super 1.0 2 near-copies [2/2] [UU]
      bitmap: 1/466 pages [4KB], 1024KB chunk

md2 : active raid10 sdb1[3] sdf1[2]
      625130336 blocks super 1.0 2 near-copies [2/2] [UU]
      bitmap: 4/299 pages [16KB], 1024KB chunk

md1 : active raid10 sda4[0]
      576781536 blocks super 1.0 2 near-copies [2/1] [U_]
      bitmap: 5/5 pages [20KB], 65536KB chunk

md0 : active raid10 sde3[2](F) sda3[0]
      46138592 blocks super 1.0 2 near-copies [2/1] [U_]
      bitmap: 1/1 pages [4KB], 65536KB chunk

unused devices: <none>
Phenom940:/home/dma #

Von diesen 8 Platten habe ich von SAMSUNG, und 3 davon habe ich nach 3 Jahren austauschen lassen, was SAMSUNG ohne wenn und aber tat.

So, dh. die Platten Sind NEU, und die "sda" ist die einzige, die _nicht_ ausgetauscht wurde. Die "sda will mit der neuen "sde" nicht synchronisieren, was habe ich getan?
1.

Code:

dd if=/dev/sda of=/dev/sde count=1 bs=512

2.

Code:

sfdisk -R /dev/sde

3.

Code:

mdadm /dev/md0 -a /dev/sde3

4. Synchronisation läuft

Code:

md0 : active raid10 sde3[2] sda3[0]
      46138592 blocks super 1.0 2 near-copies [2/1] [U_]
      [>....................]  recovery =  3.5% (1656832/46138592) finish=12.5min speed=59172K/sec
      bitmap: 1/1 pages [4KB], 65536KB chunk

Doch kurz vor dem Synchrinisationsende (geht so bis 99.9%) fällt die Partition wieder raus

Code:

md0 : active raid10 sde3[2](F) sda3[0]
      46138592 blocks super 1.0 2 near-copies [2/1] [U_]
      bitmap: 1/1 pages [4KB], 65536KB chunk

Mit md1 die gleiche Geschichte.

Was soll ich sagen... HELP!

Anonymous · 30 Okt. 2011

zeig mal die genaue Partitionierung der beiden Platten,

Code:

fdisk -lu /dev/sd[ae]

wahrscheinlich sind da kleine Differenzen drin, und du bekommst die beiden Raids deshalb nicht online weil, sda3 und sde4 jeweils um ein paar Blöcke zu klein sind.

robi

dma67 · 30 Okt. 2011

Hallo robi, danke erstmal für Deine Antwort am Sonntag

Zu den Festplatten:
scheinen ok

Code:

Phenom940:/srv/smb/linux-tools # fdisk -lu /dev/sda

Disk /dev/sda: 640.1 GB, 640135028736 bytes
255 Köpfe, 63 Sektoren/Spur, 77825 Zylinder, zusammen 1250263728 Sektoren
Einheiten = Sektoren von 1 × 512 = 512 Bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000491ad

   Gerät  boot.     Anfang        Ende     Blöcke   Id  System
/dev/sda1   *          63      224909      112423+  83  Linux
/dev/sda2          224910     4417874     2096482+  82  Linux Swap / Solaris
/dev/sda3         4417875    96695234    46138680   fd  Linux raid autodetect
/dev/sda4        96695235  1250258624   576781695   fd  Linux raid autodetect
Phenom940:/srv/smb/linux-tools # fdisk -lu /dev/sde

Disk /dev/sde: 640.1 GB, 640135028736 bytes
255 Köpfe, 63 Sektoren/Spur, 77825 Zylinder, zusammen 1250263728 Sektoren
Einheiten = Sektoren von 1 × 512 = 512 Bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000491ad

   Gerät  boot.     Anfang        Ende     Blöcke   Id  System
/dev/sde1   *          63      224909      112423+  83  Linux
/dev/sde2          224910     4417874     2096482+  82  Linux Swap / Solaris
/dev/sde3         4417875    96695234    46138680   fd  Linux raid autodetect
/dev/sde4        96695235  1250258624   576781695   fd  Linux raid autodetect
Phenom940:/srv/smb/linux-tools #

Das war am Anfang auch meine Vermutung.

Die mögliche Ursache liegt vielleicht woanders. Ich habe hier noch so ein schönes graphisches Tool für Festplatten entdeckt (Festplattenwerkzeug). Und der zeigt mir, das sda einige fehlerhafte Sektoren hat. Was vielleicht eben dazu führt, dass die fehlerhaften Sektoren die Platte praktisch kleiner machen. sde dagegen ist 1A.
Ich habe gedacht, vielleicht könnte man die sda auf sde via z.B. Knoppix klonen, und die sda zu SAMSUNG schicken

sda:
http://dariuszmarek.da.funpic.de/image/raid2.png

sde:
http://dariuszmarek.da.funpic.de/image/raid2.png

Hm, was tun?

Anonymous · 30 Okt. 2011

Fehlerhafte Sektoren werden erst einmal Platten-intern verwaltet und sind nach außen überhaupt nicht sichtbar. Erst wenn die Platte keine Reserveblöcke mehr hat, merkt auch das Betriebssystem das es fehlerhafte Blöcke oder Sektoren gibt. Die Kapazität der Platte oder Partition wird damit aber nicht kleiner. SMART meldet sich schon vorher wenn die Reserveblöcke knapp werden mit einem SMART Fehler. Siehe dazu auch hier im Forum oder hier einen schönen Beitrag einer Recovery-Firma.

Wenn jetzt weitere Blöcke kaputt gehen sind es Blöcke die auf der Platte angesprochen werden können und die auch Bestandteil der Filesysteme ist, und die eventuell auch schon belegt sind. Beim Lesen oder Schreiben dieser Blöcke gibt es Schreib-Lesefehler und diese sollten auch in den Fehler Logs zB /var/log/messages aufschlagen. Ausschließen von der weiteren Verwendung könnte man diese Blöcke aber nur dann, wenn man "badblocks" darüber laufen lassen würde und dem Filesystem die Liste beim neu Erstellen des Filesystems mitgeben würde. Hierbei wird die nutzbare Kapazität des Filesystems dann kleiner, aber das Raid hätte die selben Probleme wie jetzt auch, da es auch diese im Filesystem als Bad Block bekannten Blöcke synchron halten müsste. bzw man könnte versuchen die Platte neu low-level zu formatieren und damit die Badblock Liste auf der Platte selbst neu zu erstellen, würde ich aber davon abraten. Ist also beides für dich keine Option, die Platte ist eventuell auch schon Schrott. Wenn es aber schon mal soweit gekommen ist, dann werden die nächsten defekte Blöcke wohl sowieso nicht mehr lange auf sich warten lassen, so das man sich schnellstens nach einer neuen Platte umsehen sollte.

Zuerst aber mal nach Fehlern in den Logs suchen. Kommen sie alle vom Laufwerk sda ? wann schlagen sie auf, nur während des Rebuilds der Raids oder auch im normalen Betrieb? Sind dort immer wieder kehrende Blocknummern oder Blockbereiche dabei?

Anhand des Vorkommens solcher Fehler solltest du Klarheit bekommen ob die Platte sda kaputt ist, ob sie im normalen Betrieb auch schon Schreib/Lesefehler produziert, oder es eventuell einen anderen Grund haben könnte, warum der Rebuild nicht durchläuft.

Eine physiklische Kopie (zB dd) wie du oben angedacht hast, wird oftmals an genau den selben Lesefehler abbrechen wie der Recover des Raids auch. Mit einigen Recovertools könnte man versuchen zu erzwingen solche defekten Blöcke solange zu lesen bis man ganz sicher ist, sie nicht mehr lesbar sind und auch dabei eventuell in Kauf nehmen, dass die Platte während der ewig wiederholten Versuche des Auslesens von defekten Bereichen dann plötzlich und unerwartet den Geist komplett aufgibt.

Besser jedoch hier ist eine logische Kopie erstellen, also über ein normales Backupverfahren (zB rsync oder irgend so was) und damit die einzelnen Dateien 1zu1 in ein vorher auf der Zielplatte neu angelegtes Filesystem zu kopieren. Sollten die defekten Blöcke zur Zeit nicht benutzte Blöcke sein, dann treten die Lesefehler eventuell gar nicht erst oder nicht ganz so häufig auf. Sind die defekten Blöcke derzeit von Dateien benutzt, dann können die defekten Dateien eben nicht kopiert werden. Sind die defekten Blöcke Bestandteil der Filesystemmetadaten, dann hast du eventuell so oder so Pech und musst dich eventuell wohl oder Übel von ein paar mehr nicht mehr auffindbaren Dateien trennen, unter "/" ist das aber sowieso kein Problem, die Dateien dort gibt's im fertigen Paket auf der DVD oder sie sind absolut bis relativ unwichtig.

robi

dma67 · 30 Okt. 2011

robi schrieb:
Zuerst aber mal nach Fehlern in den Logs suchen. Kommen sie alle vom Laufwerk sda ? wann schlagen sie auf, nur während des Rebuilds der Raids oder auch im normalen Betrieb? Sind dort immer wieder kehrende Blocknummern oder Blockbereiche dabei?

Genau das passiert

Code:

Oct 30 11:35:37 Phenom940 smartd[6953]: Device: /dev/sda [SAT], 5 Currently unreadable (pending) sectors
Oct 30 12:05:37 Phenom940 smartd[6953]: Device: /dev/sda [SAT], 5 Currently unreadable (pending) sectors
Oct 30 12:35:37 Phenom940 smartd[6953]: Device: /dev/sda [SAT], 5 Currently unreadable (pending) sectors
Oct 30 13:05:37 Phenom940 smartd[6953]: Device: /dev/sda [SAT], 5 Currently unreadable (pending) sectors
Oct 30 13:35:37 Phenom940 smartd[6953]: Device: /dev/sda [SAT], 5 Currently unreadable (pending) sectors
Oct 30 14:05:37 Phenom940 smartd[6953]: Device: /dev/sda [SAT], 5 Currently unreadable (pending) sectors
Oct 30 14:35:37 Phenom940 smartd[6953]: Device: /dev/sda [SAT], 5 Currently unreadable (pending) sectors
Oct 30 15:05:37 Phenom940 smartd[6953]: Device: /dev/sda [SAT], 5 Currently unreadable (pending) sectors
Oct 30 15:35:37 Phenom940 smartd[6953]: Device: /dev/sda [SAT], 5 Currently unreadable (pending) sectors
Oct 30 16:05:37 Phenom940 smartd[6953]: Device: /dev/sda [SAT], 5 Currently unreadable (pending) sectors

Also halten wir mal fest:
1. Es handelt sim um / und /home Partition
2. sda ist dabei sich zu verabschieden
3. sde scheint OK /ist OK

Wie wäre es Deiner Meinung der bessere Weg?

Meine Überlegung:
1. Kann ich die sda aus dem RAID irgendwie auf die sde drauf bekommen? sde wäre dann nicht im RAID, sondern 'standalone'

also erstmal irgendwie per Knoppix und dd von sda auf die gesunde sde?

2. sda ausbauen, zu SAMSUNG schicken, in 2 Wochen habe ich eine neue Platte

3. aus dem RAID md3 eine Festplatte ausspannen

4. die Partitionen von sde auf diese ausgespannte Platte drauf tun

5. neue sda und sde mit RAID10 verbinden

6. von der ausgespannten Platte auf den RAID (sda+sde) die Partitionen übertragen

7. Die ausgespannte Platte wieder zurück zu md3

ODER

1. Eine neue Festplatte kaufen
2. RAID10 mit sde machen
3. Partitionen von md0 auf mdX
4. sda zu SAMSUNG, neue zurücke als 'Reserve' einspannen

wie würdest Du das machen?

josef-wien · 30 Okt. 2011

Wir robi schon schrieb, sollstest Du zumindest hier dd vergessen (ich befasse mich immer mit Daten und nicht mit Behältern). Da durch die bisherigen Aktionen die Partitionen von sde schon weitgehend mit den richtigen Daten gefüllt sind, führst Du jeweils

Code:

rsync -AHPSXavx --delete --ignore-errors /einhängepunkt/quellpartition/ /einhängepunkt/zielpartition/

(der Schrägstrich am Schluß des jeweiligen Verzeichnisses ist wichtig) aus. Alternativ kannst Du die Partitionen frisch formatieren, dann kannst Du --delete --ignore-errors weglassen. Sicherheitshalber solltest Du auch GRUB neu installieren.

Welche Platte Du derzeit "solo" betreibst, mußt Du entscheiden.

Ergänzung (RAID-Spuren auf sde tilgen):
mdadm --zero-superblock /dev/sdeX
auf /dev/sdeX UUID ändern (bei Ext3/Ext4 mit tune2fs)

Anonymous · 30 Okt. 2011

dariuszmarek schrieb:
Meine Überlegung:
1. Kann ich die sda aus dem RAID irgendwie auf die sde drauf bekommen? sde wäre dann nicht im RAID, sondern 'standalone'

ja aber nicht ganz einfach da viel Handarbeit.

dariuszmarek schrieb:
also erstmal irgendwie per Knoppix und dd von sda auf die gesunde sde?

falsch, das warum habe ich oben schon beschrieben.

1. sde3 und sde4 aus allen Raids rausschmeißen soweit sie dort noch zu sehen sind.
2. auf sde3 und sde4 alle alten Raidsuperblöcke löschen
3. auf beiden Partitionen neue Raids anlegen mit einer "Missing"

Übrigens was willst du immer mit Raid10 und 2 Slices ? Raid10 mit nur 2 Bestandteilen wird immer wie ein Raid1 , Raid 10 ist weiter nichts als ein Raid0 aus mehreren Raid1, für ein vernünftiges Raid 10 würde man mindestens 4 Platten brauchen.

4. auf den neuen Raids Filesysteme anlegen
5. die Daten von sda3 und sda4 mittels rsync auf sde3 und sde4 kopieren.
6. Mountpoints und Konfigurationen sowie die initrd anpassen, damit die Kiste wieder bootet, und zwar komplett von sde
7. sda1 und sda2 aus allen Raidkonfigurationen löschen. und die alten Kennungen von md0 und md1 aus /etc/mdadm löschen, falls sie dort stehen.
8. wenn die Kiste dann sauber bootet und sda überhaupt nicht mehr benutzt wird, dann kannst du sie ausbauen.

....
und das war erst der Anfang, aber das zusammenbauen geht schneller.

Alles in Allem, nicht ganz einfach, hatte ich dir ja versprochen.

dariuszmarek schrieb:
wie würdest Du das machen?

Ich bin faul, also ganz einfach:
ein vernünftiges Backup vom jetztigen /home anlegen , dann Platte sda austauschen und System neu installieren und dabei die 3 anderen Raids (jetzt md2 , md3 ,md4) dabei nicht kaputt machen,
danach home wieder zurückspielen.

robi

Anonymous · 30 Okt. 2011

josef-wien schrieb:
Da durch die bisherigen Aktionen die Partitionen von sde schon weitgehend mit den richtigen Daten gefüllt sind, führst Du jeweils

Code:

rsync -AHPSXavx --delete --ignore-errors /einhängepunkt/quellpartition/ /einhängepunkt/zielpartition/

(der Schrägstrich am Schluß des jeweiligen Verzeichnisses ist wichtig) aus. Alternativ kannst Du die Partitionen frisch formatieren, dann kannst Du --delete --ignore-errors weglassen. Sicherheitshalber solltest Du auch GRUB neu installieren.

Kamikaze Aktion? warum nicht, halte ich aber für riskant, aber warum nicht. Müsste man nach rsync nur von einem Hilfsystem aus die Raids von sda deaktivieren und die von sde forciert auf online setzten, Dann den Grub dazu bringen die Kiste zu booten, je nachdem ob das vorher schon ging oder nicht wird es mehr oder weniger kompliziert, und dann nur noch hoffen und beten das fsck das Filesystem das nicht 100% synchroniersiert war auch wirklich 100% akzeptiert. Ist natürlich erstmal nur die Halbe Arbeit, vorrausgesetzt man weiß genau was man macht.

robi

josef-wien · 30 Okt. 2011

robi schrieb:
Kamikaze Aktion?

Aus meiner Sicht ist es das nicht, aber Deine Variante

robi schrieb:
Ich bin faul, also ganz einfach: ...

ist natürlich der sicherere Weg.

dma67 · 30 Okt. 2011

Ich danke Euch für die Unterstützung.

De facto ist der RAID-Verbund kaputt.
Es führt wohl kein Weg daran vorbei, eine Platte anzuschaffen, mit sde verbinden und das System neu aufzusetzen. Erst dann die sda reklamieren. Die Daten habe ich gesichert.

In 3 Wochen haben wir Suse 12.1, da mischt sich der Schmerz mit der Freude - also es wird verkraftbar sein ;-) und ich werde diesen Weg gehen.

[SOLVED] RAID will nicht synchronisieren

dma67

Hacker

Anonymous

Gast

dma67

Hacker

Anonymous

Gast

dma67

Hacker

josef-wien

Ultimate Guru

Anonymous

Gast

Anonymous

Gast

josef-wien

Ultimate Guru

dma67

Hacker