[GELÖST] MDraid + Ext4 → RAID10 arbeitet extrem instabil

[generalmajor]

Ahoi,

eigentlich wollte ich meinen Heimserver (einer openSuSE-12.1-Maschine) mit vier neuen Festplatten im RAID10-Verbund bestücken, doch beim Zugriff auf dieses (heute Mittag frisch installierte) MD-Soft-RAID hagelt es kryptische Fehlermeldungen, und Schreiboperationen werden mitunter einfach abgebrochen. Einige Fehlermeldungen (in annähernd chronologischer Reihenfolge):

ata1.00: failed command: WRITE FPDMA QUEUED 
Buffer I/O error on device md0p1, logical block 240556 
COMRESET failed
ata4.00: failed command: FLUSH CACHE EXT 
Aborting journal on device md0p1-0

Schreiboperationen verlaufen mitunter nicht zur Gänze: So wurden bei einem simplen cp -r mehrere Files einfach nicht kopiert.

Irgendwann heißt es Rien ne va plus, denn es erscheinen Meldungen wie:

Re-mounting device read-only

Wenig später stürzt die olle Möhre meist komplett ab.

Hier einige Eckdaten zu meiner Hardware:

4× Western Digital Black Series mit je 500 GB (allesamt fabrikneu)
1× Highpoint Rocket 640L (PCI Express 4×)

Das System selbst besteht aus einem Gigabyte-Board mit G31-Chipsatz + Core 2 Quad Q8200 + 2 GB RAM + OpenSuSE 12.1. 12.2 klappte leider nicht, weil das Image aus dem WWW reproduzierbar (!) Fehlbrände erzeugte.

Dateisystem ist, wie gesagt, Ext4 + MDraid. Es okkupiert alle vier Platten fast zur Gänze. Hinzu kommen noch kleinere Partis (ohne RAID) für Boot & Swap.

Wo liegt der Hund begraben? Sind es die Festplatten (aber fabriksneu & Marke WD…naja…), der Controller oder ein Bug im MDraid oder sonstwas?! Danke für jeden zweckdienlichen Tipp!

 

[josef-wien]

ata1.00: failed command: WRITE FPDMA QUEUED
ata4.00: failed command: FLUSH CACHE EXT

Nachdem hier 2 Festplatten betroffen sind, denke ich eher an den Controller. Steckt die Karte fest im Steckplatz? Stecken die 4 SATA-Kabel an beiden Enden fest? Ansonsten:

dmesg | grep -i ata
/usr/sbin/hwinfo --storage-ctrl

 

[generalmajor]

Steckplatz & Kabel → geprüft & OK

Wenn das der Controller ist, dann uhje! Das ist schon der dritte Controller (die beiden früheren hängten sich immer beim Booten auf, aber die waren von Startech).

 

[generalmajor]

Zum dmesg-Test kam es leider nicht mehr, denn schon beim nächsten Systemstart verweigerte Grub das Laden des Kernels. Dabei beschwerte er sich (no na!) über ein kaputtes RAID. /dev/sdb1 und /dev/sdd2 seien «inaktiv», der Superblock nicht auffindbar. Zwei brandneue HDDs sollen defekt sein? Wie bitte??

Versuche mit Ubuntu 12.10 scheiteren übrigens ebenfalls kläglich: Das Formatieren und Installieren klappte ohne RAID-Probleme, doch starten ließ sich gar nix (wegen kaputtem RAID). Also ist es nicht die Distro, die hier pfuscht. Zwischenzeitlich hörte sogar das «alte» RAID (dessen Platten aber direkt am Board hängen, nicht am Controller) zu arbeiten auf, doch hier reichten eine Rettungs-CD und ein wenig mit mdadm rumjonglieren: Eine der Mitgliedsplatten des Alt-RAIDs war aus ungeklärter Ursache nicht mehr Teil des MD-Raids…

 

[Anonymous]

Habe ich das richtig verstanden, 4 Platten .
2 Hängen auf dem Systemboard und 2 an einem zusätzlich verbaute PCI-Karte "Highpoint Rocket 640L (PCI Express 4×) "

Darüber ein Raid 10 (mdadm) (per Hand aufgesetzt oder wie ? nicht das dort ein Raid 01 läuft)
Wo ist /boot ? mit auf dem Raid ?

Hier mal ein paar Bemerkungen für eine Fehlersuche und Eingrenzung

• 1. Firmware (BIOS) der Highpoint Rocket prüfen. Es gibt bei solchen Kontrollern gelegentlich mal wieder verschiedenen FW für Betrieb (fake )Raid Betrieb oder Betieb ohne Raid. Hauptunterschied dabei (aber oftmals nicht der einzige Unterschied) ist das Tool für Konfiguration für das Raid.
  
  2. Habe jetzt keine Lust mit die Doku für den Kontroller zu suchen, aber oftmals habe solche Kontroller bis zu 4 verschiedene Modi wie sie die Platten betreiben können, (Raid, nativ, kompatible ...... was weiß ich noch alles.) Wenn du Platten im Raid mit anderen Kontrollern mischt, dann sollte diese Einstellung mit der des anderen Kontrollers bzw des Kontroller des Systemboards harmonieren.
  
  3. Wenn du mal wieder die Maschine am laufen hast, dann mal die Ausgabe von "cat /proc/mdstat" hier posten.
  würde mich auch mal interessieren wie der Treiber heißt der dort an der PCI-Karte läuft (rr64x ??? ) und ob der standardmäßig aus deinem Kernel kommt, oder eventuell der vom Hersteller ist. (Manchmal hilft es wirklich mal nach Paches für solche Treiber zu suchen.)
  
  4. Die Kombination über Systemboard und PCI-Karte würde ich bei Problemen mal probehalber auflösen und alle Platte mal nur an der PCI-Karte versuchen. Keine Ahnung wo der PCI-Flaschenhals bei deinem Systemboard ist, aber wahrscheinlich wirst du in diesem Fall da bei 4 Platten am PCI Kontroller schon von der PCI Bandbreite ausgebremst.
  
  5. Bei solchen Problemen in Verbindung mit Raid 0 oder Ableitungen davon Raid10/ 50 /60 könnte der Cache der Platten dafür verantwortlich sein. Normalerweise sollte man diesen bei Raids sowieso fürs schreiben ausschalten, macht man aber meist nur auf produktiven Servern wo es wirklich darauf ankommt das beim Absturz nichts oder sehr wenig verloren gehen kann. Das Abschalten des Cache wird die Geschwindigkeit der Platten ganz schön relativieren.
  
  6. vor einer weiteren Neuinstallation die Superblöcke der alten Raids erstmal auf den Platten löschen bevor du ein neues Raid aufsetzt.
  
  7. die neuen Platten sind neuerdings alle schon auf die 4KBlöcke formatiert, bei einem neuen Raid 10 würde ich hier mal die optimale Chunksize für das Raid manuell oder per Webtool nachrechnen und dann eventuell das Raid entsprechend per Hand so optimal aufbauen. Bei Raid 10 mit 4 Platten gibt es zwar keine falschen Einstellungen aber es muss ja einen Grund haben warum du 4 Platten a 500GB und nicht 2 Platten a 1TB haben willst, was wahrscheinlich 50€ oder mehr billiger kommen würde.

robi

 

[generalmajor]

D'Ehre & danke erst mal für die Tipps /* die ich gerade am Handy las, während ich meinen «Patienten» verarztete */

An der Rocket hängen alle 4 Platten des neuen Systems. Muss so sein, denn das sind SATA-3-Platten (und die Onboard-Anschlüsse unterstützen nur SATA 2, die Rocket aber SATA 3). Dazu kommen 2 Platten vom alten System, die am Board hängen, von denen ich aber nur noch die Daten auf die neuen Platten schaufeln und sie hernach entfernen will, und natürlich das DVD-Laufwerk (ebenfalls onboard).

/boot ist nicht auf dem Raid, sondern auf einer separaten Partitionen auf der ersten der vier «neuen» Platten.

#1 Das BIOS-Setup des Controllers habe ich schon begutachtet. RAID-Optionen gibt's dort nicht, denn es ist ja «nur» eine Rocket (ohne RAID).

#2 Wie gesagt: Alle Mitglieder des neuen Raids hängen an der Rocket.

#3 Die Maschine bootet gar nicht mehr, daher konnte ich nur noch eine Ubuntu-Server-CD als Rettungsmedium missbrauchen und folgende Meldungen entlocken:

/target/dev # cat /proc/mdstat
Personalities [raid10]
md128 : active raid10 sdd2 [3] sdc2 [2] sdb1 [1] sda2 [0] (F)
975508480 blocks super 1.2 512K chunks 2 near-copies [4/3] [_UUU]

/target/dev # mdadm --detail /dev/md128
/dev/md128
Version: 1.2
Creation Time: Mon Dec 17 21:46:34 2012
Raid Level: raid10
Array Size: 975508480 (930.32 GiB 998.92 GB)
Used Dev Size: 487754240 (465.16 GiB 499.46 GB)
Raid Devices: 4
Total Devices: 4
Persistence: Superblock is persistent
Update Time: Mon Dec 17 21:54:46 2012
State: active, degraded
Active devides: 3
Working devides: 3
Failed devices: 1
Spare devices: 0
Layout: near=2
Chunk size: 512K

Komisch ist aber, dass Raid device 0 den Status «removed» hat, die ausgewählte Partition /dev/sda2 aber weiter unten als «faulty spare» verzeichnet ist. Versuche mit mdadm --add klappten nicht: Erst hieß es «/dev/sda2 added», danach (auch nach Neustart!!) «device is busy». Änderte ich die Reihenfolge der Partis beim mdadm-Aufruf, machte immer die erste angegebene Parti Probleme. Es hängt also nicht an einer konkreten Festplatte.

Weil das System nicht bootet und ich von der Rettungs-CD darauf zugriff, kann ich keinen Treibernamen nennen. Ich weiß lediglich, dass auf der Rocket ein Marvell-Chipsatz residiert.

#4 s.o.
#5 Wie macht man das?
#6 Habe ich schon gemacht, hilft aber nicht.
#7 Der Hauptgrund ist die Performance. Vorher hatte ich ein RAID 1, das für mich gerade noch ausreichend war.

 

[Anonymous]

#5 Wie macht man das?

prinzipiell 3 Möglichkeiten.

1. fest an der Platte selbst durch einen Jumper an der Platte selbst.
2. im Bios des Kontrollers oder für onboard Sata gibt eine Einstellung eventuell im BIOS selbst
3. hdparm ( -W Get/set the IDE/SATA drive´s write-caching feature.)


PS für SCSI-Plattenbesitzer
falls jemand richtige SCSI Platten im System hat dann am besten mit sdparm (Paket muss eventuell erst installiert werden)
aktuellen Write Cache prüfen mit

# sdparm -g WCE=1 -H /dev/sdc

einschalten

# sdparm --set=WCE /dev/sdc

ausschalten

# sdparm --clear=WCE /dev/sdc

robi

 

[generalmajor]

OK, danke. Es wird wohl hdparm, denn einen passenden Jumper hat die WD Black Series nicht, und im /* sehr rudimentären */ BIOS-Setup der Rocket fehlt eine entsprechende Position.

 

[josef-wien]

Wenn Du am mainboard genügend Anschlüsse hast, würde ich die vier neuen Platten einmal dort anschließen, das RAID von Grund auf neu machen und schauen, ob es funktioniert. Tut es das, dann ist der Controller als Fehlerquelle identifiziert.

Hinsichtlich der Geschwindigkeit hast Du falsche Vorstellungen. Für übliche Festplatten reicht die Geschwindigkeit eines ordentlichen SATA-1-Controllers vollkommen aus, die bei SATA-2 und SATA-3 hinzugekommenen Befehle werden das Kraut nicht wirklich fett machen.

 

[luwa]

Wenn Du am mainboard genügend Anschlüsse hast, würde ich die vier neuen Platten einmal dort anschließen

Ich habe vor nicht langer Zeit hier im Forum gelesen das man ein Raid nur als Software-Raid aufsetzen sollte weil es bei der Restauration sonst zu Problemen kommen könnte. Bei mir läuft ein Hardware-Raid 1 via Controller. Ein Raid und schon gar kein Raid10 würde ich mixed laufen lassen. Heißt entweder das Board gibt das her oder der Controller. Problematisch sehe ich auch SATA 2 und 3 zwischen Board und Controller. Da kann es beim Spiegeln zu Schreibfehlern durch die unterschiedlichen Datenraten kommen. Beim lesen dito.
Sind nur Ideen. Mein Raid1 läuft, musste ich ja auch noch nicht wiederherstellen.
Gut wenn man nochmal liest. Du hast jetzt alle 4 Platten am Controller. Sorry versuch es doch mal, am Controller mit einem Software Raid. Könnte ja sein das es auf der Hardwareebene nicht genug Unterstützung für den Controller gibt.
Jupp, für meine Neugier, brauchst Du die Lesegeschwindigkeit eines Raid 0? Ich frag nur so. Mein Sohn und ich haben verschiedene Filme geschaut welche da auf dem Server lagen. System war P3 600MHZ 512MB-RAM kein Raid und geht.

mfg
luwa

PS: ich habe zwei baugleiche Platten im Raid. Frag mich mal welche der Master ist. So wenn es um das Restore geht. :???:

 

[generalmajor]

@luwa: Das RAID 10 brauch ich wirklich, denn ich mache sehr viel Bildbearbeitung (inkl. Panos, die schon mal 100 MB groß werden).
@josef-wien: Mir geht's weniger um die zusätzlichen Features von SATA 3. Die Platten, die ich kaufte (WD Caviar Black Edition), sind SATA-3-Dinger mit 500 GB Platz, 6 Gb/sec und 64 MB Cache. Die Datenrate wird praktisch nie erreicht (allein schon wegen der Latenzzeiten, aber SSDs haben wiederum andere Nachteile), doch liegt sie dann wohl immer noch etwas höher als bei meinen alten SATA-2-Flundern.

 

[josef-wien]

Deine Black bringt es laut Spezifikation auf maximal 150 MB/s (interessanterweise sind die größeren Kapazitäten dann langsamer). Prinzipiell ist einem direkten Anschluß an die southbridge (also den Anschlüssen am mainboard) der Vorzug gegenüber dem Umweg über den PCIe-Bus zu geben.

 

[generalmajor]

@josef-wien: Ich habe aber auf der Platine keine 4 Anschlüsse frei, sonst hätte ich gar keinen Controller gekauft! :-X

Gerade habe ich einige letzte Tests gemacht (u.a. Platten umgestöpselt, Kabel getauscht,…), die aber auch keinen Erfolg brachten. Merkwürdig fand ich nur:

† Vertausche ich zwei Platten, «wandert» das Problem (Parti auf Platte nicht ins RAID einbindbar) mit der Platte meistens mit (was mich eine Zeit lang an eine hinnige Platte denken ließ), aber nicht immer! Vertausche ich sda und sdd, macht manchmal die physikalische Partition von sdd (die ja früher sda war) Probleme (device is busy), manchmal aber die phys. Parti von sda (die ja früher sdd war, aber keinen Ärger machte).
† In Einzelfällen meldet hdparm bei einer der Platten einen I/O Error.
† mdadm meldet mitunter «dev/sdc2 not suitable for array», meist (aber nicht immer!) im Zusammenhang mit einem «device or resource busy».
† Mitunter spinnt der Controller beim Einschalten: Er braucht dann ~30 sec zum Hochfahren (Bildschirm bleibt schwarz) und / oder erkennt eine der Platten (oder gleich alle vier) nicht.
† …oder er fährt normal hoch, doch das Rettungssystem erkennt eine der Platten (oder auch alle vier) nicht.

Ein richtiges System hinter diesen Fehlermeldungen finde ich nicht, außer: Versuche ich, ein RAID einzurichten, meckert er mindestens wegen einer Platte, wo die physikalische Partition ein Problem hat.

Gehe ich in der Annahme richtig, dass sich der Controller mit meinen Platten beißt? Immerhin habe ich einen vagen Hinweis in diese Richtung bekommen: http://www.tomshardware.co.uk/forum/251076-14-raid-issues-western-digital-hard-disk

Oder kann auch die Hauptplatine bzw. ihr (zu langsamer?) Chipset die Wurzel allen Übels sein?

 

[Anonymous]

Wenn ich mir deine Tests so durchlese :???: :???: :???:
irgendwo scheint dort was nicht recht zusammenzupassen oder überfordert zu sein.

Sind dort jetzt die 2 alten Platten auch immer noch im System? Die Leistung vom Netzteil hast du hoffentlich auch mit etwas Reserve berechnet. Die Platten brauchen beim Starten erstmal ungefähr das doppelte wie später dann im Betrieb.

Ich würde es erstmal mit 2 Platten weniger versuchen. Also das Raid10 mit 2 fehlenden Platten per Hand aufsetzen und dann installieren.
Wenn das rund läuft, dann die beiden alten Platten rüber kopieren, dann raus mit diesen Platten und die 2 fehlenden rein und zum Raid dazufügen.

Angenommen deine Platten am Kontroller sind jetzt sda, sdb, sdc und sdd,
dann die 3 und 4 raus also sdc und sdd. Hier aber darauf achten das das wirklich die sind die als 3. und 4. erkannt werden sonst ändert sich beim entfernen oder dazu fügen die Zuordnung.

von einem Livesystem aus folgende Vorgehensweise:

• 1 . von sda und sdb die Raidsuperblöcke entfernen
  2 . sda partitionieren für /boot (sda1) und Rest (sda2)
  3 . danach den MBR auf sdb kopieren.
  4 . Rechner rebooten
  5 . jetzt Raid10 aufsetzen Chunksize wenn da wirklich nur 2GB Speicher im Rechner sind, würde ich 64K (default) nehmen,
  bei nur 2GB Hauptspeicher und Suse 12.? und fast 1TB Filesystemgroße wird dort nicht sehr viel zum Cachen der Filesysteme übrig bleiben, so das wahrscheinlich ziemlich oft auf die Platten zugegriffen wird.
  ( /boot würde ich als Raid1 aufsetzen und zwar über alle 4 Platten, aber das musst du selbst wissen)
  

  mdadm -C /dev/md0 -l 10 -n 4 /dev/sda2 missing /dev/sdb2 missing

  Achtung die Reihenfolge hier "sda,missing,sdb,missing" beachten.
  Das Ergebnis ist ein degradiertes Raid10, das derzeit eigentlich nur aus 2 Platten besteht die als Raid0 zusammenarbeiten.
  6. Jetzt rebooten und Installieren. Hier beachten das du das jetzt bestehende Raid10 zum installieren nutzt, dieses sollte beim scannen der Platten von der Installationsroutine gefunden werden. Sonst manuell von Konsole aus in die Installation eingreifen und das Raid aufsetzen. dann sollte es beim nochmaligen Plattenscan auf alle Fälle erkannt werden.
  7. ausprobieren und wenn funktioniert die Daten der alten Platten rüberkopieren.
  8. alte Platten raus.
  9. ausprobieren
  10. wenn alles soweit funktioniert dann die beiden fehlenden Platten rein, und prüfen ob sie wirklich sdc und sdd sind. Möglich das das Raid jetzt als md127 erkannt wird, das könnte man auch noch ändern, oder aber so lassen und den Befehl unten anpassen. Auf jeden Fall prüfen. wenn auf sdc und sdd noch alte Raidsuperblöcke drauf sein sollten, dann könnten hier ein paar Fehlermeldungen entstanden sein, dann diese Superblöcke löschen, damit sie beim nächsten Reboot nicht wieder auffallen.
  11. den MBR von sda auf sdc und sdd kopieren
  12. rebooten
  13. jetzt einzeln oder gleich beide auf einmal zum Raid hinzufügen
  

  mdadm /dev/md0 -a /dev/sdc2 -a /dev/sdd2

  14. rebuild abwarten
  15. prüfen, testen.
  16. wenn du /boot als Raid1 über alle 4 Platten ausgelegt hättest, könntest du jetzt auch noch mit der Grubshell jeder Platte einen eigenen Bootloader verpassen, dann könntest du theoretisch sogar von jeder Platte das System starten.
  17. zum Schluss unbedingt noch /etc/mdadm.conf anpassen zB so hier
  

  echo 'DEVICE /dev/sd*[0-9]' > /etc/mdadm.conf
           mdadm --detail --scan >> /etc/mdadm.conf

robi

 

[generalmajor]

Leider scheiterte der Parcours bereits bei Schritt 6. Da weigerte sich der Installer, Ext3 auf das große RAID10 mit den (noch) zwei Platten zu schreiben, ohne aber Details auszugeben. Auch der Versuch, die beiden fehlenden Platten hinzuzufügen (nach Neustart natürlich) und das RAID damit zu vervollständigen, endeten mit einem «/dev/sdd: Device or resource busy». Ganz nebenbei versuchte ich noch, die Bootpartition auf einem RAID1 unterzubringen, doch hier zeigte sich das «Faulty spare»-Problem von vorher.

H.i.K.: Der Controller und die Platten verstehen sich nicht so richtig, und es ist nicht immer die gleiche Platte, die Ärger macht. Gestern las ich etwas davon, dass so mancher Controller Festplatten, die zu lange im Energiesparmodus schlummern, nach einigen Sekunden gnadenlos aus dem RAID kickt, doch damals bezog sich das auf die Green Series von WD (und auf ein RocketRAID von Highpoint). Kann man bei einer Platte Stromsparfunktionen eigentlich abschalten?

 

[generalmajor]

Gerade hat mir der Support von Highpoint geschrieben, dass er mir hier nicht wirklich weiterhelfen könne (weil vermutlich der Treiber ein Problem hat), aber vorgeschlagen, andere Festplatten zu nehmen.

Eine andere Meldung, die ich gerade gefunden habe, liest sich wie folgt: http://wiki.ubuntuusers.de/WD_IntelliPark Doch auch hier geht es um die Green Series und Blue Series von WD, die sich schon nach 8 sec ohne Zugriffe schlafen legt und der Controller denkt, die Platte sei ausgegangen. Dass die Black Series über ein ähnliches Feature verfügen, steht nicht in den WD-Specs, aber man weiß ja nie…

 

[josef-wien]

IntelliPark™ wurde von WD so um 2008 herum verwendet. Die Festplatte geht nicht "schlafen", sondern die Schreib-/Leseköpfe werden zwischendurch geparkt, was problemlos ausschaltbar ist (meine Green [die der Ubuntu-Artikel übrigens verschweigt] läuft seit mehr als 4 Jahren als Bestandteil eines Software-RAID an bis jetzt 2 sehr unterschiedlichen Controllern [VIA, Intel] ohne das geringste Problem).

weil vermutlich der Treiber ein Problem hat

Das kann schon eher des Pudels Kern sein, aber bis jetzt hast Du uns den verwenden Treiber noch nicht verraten. Meinen zweiten Befehl vom 16. Dezember 2012, 23:34 Uhr, kannst Du auch im Rettungssystem der openSUSE-DVD oder während der Installation ausführen.

 

[generalmajor]

Hätte ich das bloß früher gewusst…! Bitteschön:

rescue ~# /usr/sbin/hwinfo --storage-ctrl
27: PCI 100.0: 0106 SATA controller (AHCI 1.0)
[Created at pci.319]
Unique ID: VCu0.yeRtuIXvwGE
Parent ID: vSkL.oInrXZofMHD
SysFS ID: /devices/pci0000:08/0000:00:01.0/0000:01:00.0
SysFS BusID: 0000:01:00.0
Hardware Class: strorage
Model: "SATA controller"
Vendor: pci 0x1b4b
Model: pci 0x9230
SubVendor: pci 0x1b4b
SubModel: pci 0x9230
Revision: 0x10
Driver: "ahci"
Driver Modules: "ahci"
I/O Ports: 0xaf00-0xaf07 (rw)
I/O Ports: 0xae00-0xae03 (rw)
I/O Ports: 0xad00-0xad07 (rw)
I/O Ports: 0xac00-0xac03 (rw)
I/O Ports: 0xab00-0xab1f (rw)
Memory Range: 0xfdaff000-0xfdaff7ff {rw, non-prefetchable}
Memory Range: 0xfd600000-0xfd60ffff {ro, non-prefetchable, disbaled}
Module Alias: "pci:v00001D4Bd00009230sv00001D4Dsd00009230bc01sc06i01"
Config Status: cfg=new. avail=yes, need=no, active=unknown
Attached To: #13 (PCI bridge)
IRQ: 43 (1587 events)

Fehlt noch was‽

Die Platten habe ich mit smartctl geprüft und habe dort nichts Verdächtiges dabei gefunden. Kann es trotzdem sein, dass Controller und Platten zueinander nicht 100% kompatibel sind…?

 

[generalmajor]

Gerade bin ich über diesen Thread gestolpert: http://ubuntuforums.org/showthread.php?t=1722440

Seine Quintessenz lautte offenbar: Physische Partitionen + Partitionstabelle löschen reicht nicht, um allfällige Superblöcke /* oder Überreste davon */ zu löschen. Soll ich also noch das da ausführen:

mdadm --zero-superblock /dev/sda

…und so weiter bis /dev/sdd

Hat das Aussicht auf Erfolg…?

 

[josef-wien]

mdadm --zero-superblock /dev/sda

1 . von sda und sdb die Raidsuperblöcke entfernen
10. ... Auf jeden Fall prüfen. wenn auf sdc und sdd noch alte Raidsuperblöcke drauf sein sollten, dann könnten hier ein paar Fehlermeldungen entstanden sein, dann diese Superblöcke löschen, damit sie beim nächsten Reboot nicht wieder auffallen.

Vendor: pci 0x1b4b
Model: pci 0x9230
SubVendor: pci 0x1b4b
SubModel: pci 0x9230
Revision: 0x10
...
Module Alias: "pci:v00001D4Bd00009230sv00001D4Dsd00009230bc01sc06i01"

Auf Grund von

Hardware Class: strorage

nehme ich an, daß Du das abgeschrieben hast und in beiden Fällen 1B4B steht. Für die Zukunft hilft Dir vielleicht http://www.linupedia.org/opensuse/Hilfe_zu_Antworten_aus_dem_Forum#Konsolausgabe_ins_Forum_posten.2C_wenn_Grafisch_nichts_geht bzw. http://www.linux-club.de/viewtopic.php?f=4&t=115729&p=728617&p728617#p728617.

Kann es trotzdem sein, dass Controller und Platten zueinander nicht 100% kompatibel sind…?

Theoretisch kann man nichts ausschließen, ich denke eher, daß der Controller mit Linux (oder Linux mit dem Controller?) nicht ganz zurechtkommt.

Kann man bei diesem Controller auch etwas anderes als AHCI einstellen? Ob es hilft, steht in den Sternen, aber Du kannst versuchen, auf Deinem bisherigen System (ohne Controller) zusätzlich den aktuellen stabilen Kernel zu installieren und von dort (mit Controller) das RAID einzurichten.

P. S.
1b4b Marvell Technology Group Ltd.
9230 88SE9230 PCIe SATA 6Gb/s Controller