Raid zerschießt sich



K

Kato

Registered User
Ich dreh noch durch. Ich habe hier ständig Probleme mit dem SW Raid. Das ist doch nicht normal, dass mir fdisk -l nur die sda anzeigt. Nach mehrmaligen Rebooten zeigt er mir dann wieder sda und sdb an aber natürlich sync lost.
Wieder 3 Stunden resyncen, zum 2. Mal heute. vor 5 Stunden hatte er mir nur die sdb angezeigt und die sda war weg..... das kann es doch echt nicht sein :mad::mad::mad::mad::mad:
 
Und schon wieder: Raid gerade neu gesynct. 1x Reboot und die sdb ist weg.

In den logs sehe ich im Moment nichts da stimmt noch etwas anderes nicht.
 
Blind geraten... Hardwareproblem. Ich würde mal anfangen bei einem Badblockscan der SDB und deren Kabel.
Da aber auch die SDA ja schonmal weg war, könnte es dabei auch ein erstes Zeichen vom Ende sein oder aber im Gesamten ein Zeichen, dass dein Controller/Board nen Schaden hat. Werden die Platten im Bios jederzeit problemlos erkannt?
 
Ich glaube das ganze System hat einen Schaden. Wenn ich das syslog aufrufen will zeigt er mir nur Einträge bis 18 Uhr. Obwohl ich anhand der Zeitstempel sehen kann, dass die Datei aktualisiert wird. Letzter Eintrag: 18:00.
Einen Badblockscan aus dem Rescue System mache ich ohne das Raid gemounted? Also nur über sda und sdb oder?
 
Badblockscan auf SDA und SDB. Kannst die auch parallel laufen lassen. Ob gemountet oder nicht ist dabei relativ egal.
 
Ich hatte hier auch mal ähnliche Probleme gepostet. Verschwunde Platten aus dem SW Raid nach dem Reboot oder nach nur wenigen Minuten Betrieb und einem anschließenden fsck über die Rescue Console hatte ich dann gleich wieder defekte Daten. Ein "badblock" hatte damals keine Probleme gefunden. Die endgültige Lösung war ein kompletter Hardwaretausch (nachdem schon die Festplatten komplett getauscht wurden). Ich denke es lag vielleicht ein Mainboardschaden vor - vielleicht ist es bei dir ähnlich?
 
Danke soweit. Ich muss noch ein paar vorbereitende Arbeiten abschließen, damit keine Daten verloren gehen bevor ich mich eingehender der Hardware widmen kann.

Ich suche trotzdem schon nach Anhaltspunkten, was da schief läuft. Dabei ist mir folgendes aufgefallen:

~# dmesg |grep DMA
DMA 0x00000000 -> 0x00001000
DMA32 0x00001000 -> 0x00100000
DMA zone: 56 pages used for memmap
DMA zone: 107 pages reserved
DMA zone: 3836 pages, LIFO batch:0
DMA32 zone: 14280 pages used for memmap
DMA32 zone: 758618 pages, LIFO batch:31
PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
ata1: SATA max UDMA/133 cmd 0xf190 ctl 0xf180 bmdma 0xf150 irq 19
ata2: SATA max UDMA/133 cmd 0xf170 ctl 0xf160 bmdma 0xf158 irq 19
ata3: SATA max UDMA/133 cmd 0xf130 ctl 0xf120 bmdma 0xf0f0 irq 19
ata4: SATA max UDMA/133 cmd 0xf110 ctl 0xf100 bmdma 0xf0f8 irq 19
ata2.00: ATA-8: WDC WD7501AALS-00E3A0, 05.01D05, max UDMA/133
ata2.00: configured for UDMA/133
ata1.00: ATA-7: ST3750640NS, 3.AEG, max UDMA/133
ata1.00: configured for UDMA/133
Click to expand...

Ist das normal, dass SATA Platten mit UDMA/133 konfirugiert sind? Oder geht es hier schon mit einer Fehlkonfiguration los?

Und beim Raid wird eine Platte einfach gekicked?

Jan 20 00:13:09 kernel: md: Autodetecting RAID arrays.
Jan 20 00:13:09 kernel: md: Scanned 4 and added 4 devices.
Jan 20 00:13:09 kernel: md: autorun ...
Jan 20 00:13:09 kernel: md: considering sda2 ...
Jan 20 00:13:09 kernel: md: adding sda2 ...
Jan 20 00:13:09 kernel: md: sda1 has different UUID to sda2
Jan 20 00:13:09 kernel: md: adding sdb2 ...
Jan 20 00:13:09 kernel: md: sdb1 has different UUID to sda2
Jan 20 00:13:09 kernel: md: created md2
Jan 20 00:13:09 kernel: md: bind<sdb2>
Jan 20 00:13:09 kernel: md: bind<sda2>
Jan 20 00:13:09 kernel: md: running: <sda2><sdb2>
Jan 20 00:13:09 kernel: md: kicking non-fresh sdb2 from array!
Jan 20 00:13:09 kernel: md: unbind<sdb2>
Jan 20 00:13:09 kernel: md: export_rdev(sdb2)
Jan 20 00:13:09 kernel: raid1: raid set md2 active with 1 out of 2 mirrors
Jan 20 00:13:09 kernel: md2: detected capacity change from 0 to 744245624832
Jan 20 00:13:09 kernel: md: considering sda1 ...
Jan 20 00:13:09 kernel: md: adding sda1 ...
Jan 20 00:13:09 kernel: md: adding sdb1 ...
Jan 20 00:13:09 kernel: md: created md1
Jan 20 00:13:09 kernel: md: bind<sdb1>
Jan 20 00:13:09 kernel: md: bind<sda1>
Jan 20 00:13:09 kernel: md: running: <sda1><sdb1>
Jan 20 00:13:09 kernel: md: kicking non-fresh sdb1 from array!
Jan 20 00:13:09 kernel: md: unbind<sdb1>
Jan 20 00:13:09 kernel: md: export_rdev(sdb1)
Jan 20 00:13:09 kernel: raid1: raid set md1 active with 1 out of 2 mirrors
Jan 20 00:13:09 kernel: md1: detected capacity change from 0 to 5368643584
Jan 20 00:13:09 kernel: md: ... autorun DONE.
Click to expand...
 
Last edited by a moderator:
Nein, das ist nicht normal und deutet nur weiterhin auf einen Hardware-Defekt hin. Wenn der bisher keinerlei badblocks gefunden hat und bei beiden Platten so langsam ist, liegt es vermutlich am Board. Sollte nur eine Platte so langsam sein, das Kabel. Oder eben die Platten selber.
 
Vielen Dank für die Info. Ja es ist bei beiden Platten so langsam, also ich meine beide Platten parallel.
D.h. du meinst, es ist das Mainboard?
 
Angeblich wurde nun das Mainboard getausch, zwischendurch auch die Festplatte (sdb) noch einmal.

Das Problem bleibt aber bestehen: Nach einem Reboot sehe gibt mir fdisk -l mal nur sda und mal sda und sdb aus.

Woran kann das denn jetzt sonst noch liegen?:confused::confused::confused:
 
Das Problem schien gelöst. Offensichtlich hat der Anbieter einen nicht kompatiblen Kernel installiert. Mit der Vorversion läuft es bis jetzt ohne Pobleme.
 
You must log in or register to reply here.
Back
Top