Probleme mit 3ware 9550SX

H

Hubert

Well-Known Member
Hallo,

ich habe ein Problem mit dem 3ware Raid-Controller 9550SX.

Gleich vorab: Dies ist kein *BSD-spezifisches Problem, aber ich weiß langsam wirklich nicht mehr weiter.

Also:

An dem 3ware Controller sind 3 Festplatten angeschlossen, die als Raid5 laufen.

Das Problem ist die Schreibgeschwindigkeit. Ich erreiche unter FreeBSD 6.1 eine Schreibgeschwindigkeit von 3,5MB/s auf das Raid5, es sei denn, ich schalte für das Raid5 den Schreibcache ein (wobei eine fette Warnung erscheint, weil ich keine Batteriepufferung habe). Mit aktiviertem Schreibcache ist die Schreibgeschwindigkeit zwar hoch bzw. erwartungskonform, aber es gibt ab und zu sehr unangenehme Hänger, die von FreeBSD auch durch eine Hinweismeldung angezeigt werden:

Code: 
twa0: ERROR: (0x04: 0x0009): Drive timeout detected: port=0
twa0: INFO: (0x04: 0x000c): Initialize started: unit=0
twa0: ERROR: (0x04: 0x0009): Drive timeout detected: port=0, unit=0
twa0: ERROR: (0x04: 0x000e): Initialize failed: unit=0
twa0: ERROR: (0x04: 0x0002): Degraded unit: unit=0, port=0

Das Board ist ein Intel SE7221BK1-E. Ich habe es aber auch schon mit einem Asus P5CR-L ausprobiert.

Die Festplatten sind 3 gleiche Seagate Platten aus der NL35-Serie mit je 400GB. Ich habe es aber auch bereits mit 3 gleichen Western Digital Platten aus der Caviar RE2-Reihe mit ebenfalls je 400GB ausprobiert.

Es liegt auch nicht am Raid5, falls das jemand vermutet ;) Ich habe es auch im Raid1-Modus mit zwei Platten und im SingleDrive Modus mit einer Platte ausprobiert.

Ich habe es auch unter Linux ausprobiert - das Verhalten ist ein wenig anders gewesen, aber auch bei dieser Variante habe ich es nicht geschafft, eine konstant hohe Datenübertragungsrate ohne Timeouts zu erzielen.

Meine Frage lautet also: Warum ist die Schreibgeschwindigkeit ohne aktivierten Schreibcache so unglaublich viel zu langsam? Und warum gibt es diese unangenehmen Timeouts bei aktiviertem Schreibcache?

Vielen Dank schon mal :)
 
Zuletzt bearbeitet:
Die Antwort ist denkbar einfach : Diese Art von Controllern werden stets mit BBU`s verbaut, dort tritt das Problem normal nie auf, selbst wenn der Cache eingeschalten und verwendet wird. (warum das Problem ohne BBU auftritt wusste bisher noch keiner so genau)

Der Bär z.b. hat aus der Serie einen Model 9550SX-8LP, 8 ports, Firmware FE9X 3.01.01.028, BIOS BE9X 3.01.00.024, der seit über einem halben Jahr nun mit Raid 5 und 6 x 400 GB Seagate HD`s auf einer FreeBSD läuft. Derzeit 6.1-RELEASE-p10 - keinerlei Probleme. Selbst das 3ware storage controllers management CLI läuft einwandfrei ohne irgendwelche Probleme.

Rat des Bären: käuf ne BBU - kalibrier die im Runtime Mode 24 Stunden lang und wetten er läuft problemlos.

Gruß Bummibaer
 
Vielen Dank für deine Antwort, aber irgendwie hilft mir die jetzt nicht so recht weiter.

Ich habe bislang keine komplexen Benchmarks laufen lassen, denn das Problem tritt bereits bei ganz einfachen Tests auf.

Beispiel:

Code: 
dd if=/dev/zero of=/mnt/raid5/zero bs=1M count=1024

Bei diesem Vorgang muss die Übertragungsgeschwindigkeit bei 60MB/s liegen, und zwar bei deaktiviertem Schreibcache. (Bei aktiviertem Schreibcache mag es meinetwegen noch um 1/8 schneller sein.)

3,5 MB/s sind unter allen denkbaren Umständen viel zu wenig.

Ich verstehe, dass eine Batterie bei aktiviertem Schreibcache die Datensicherheit im Falle eines Stromausfalls erhöht. Aber wenn kein Stromausfall auftritt, dann sollte es doch egal sein, ob eine Batterie angeschlossen ist oder nicht. (Und der Server hängt sowieso an einer USV, insofern sollte er selbst bei einem Stromausfall sauber herunterfahren.)

Ich wäre ja bereit, eine solche Batterie zu kaufen, wenn das das Problem lösen würde. Aber es kann doch nicht sein, dass der Controller ohne ein optionales Zubehör nicht vernünftig funktioniert?!
 
60MB/s ohne Schreibcache ist bei RAID5 und der Hardware wohl kaum erreichbar. Wie kommst du auf die kuehne Annahme?
3,5 MB/s sind allerdings auch recht wenig. Ich haette so mit ca. 12 MB/s gerechnet.
 
j_t schrieb:
60MB/s ohne Schreibcache ist bei RAID5 und der Hardware wohl kaum erreichbar. Wie kommst du auf die kuehne Annahme?
Zum Vergrößern anklicken....

Mh? Kannst du das erklären? Wie berechnet sich denn die Schreibgeschwindigkeit auf ein Raid5, das aus 3 Platten besteht, die einzeln jeweils 60MB/s schreiben können?

Außerdem bedenke bei deiner Antwort, dass es sich nicht um ein Raid5-spezifisches Problem handelt. Ich erhalte die gleichen schlechten Werte im Raid1-Modus und im SingleDrive-Modus.
 
Wenn selbst mit einer einzelnen Platte nicht mehr drin ist, hast du offensichtlich ein Problem mit dem Controller. Gibts es IRQ Konflikte? Kann ein anderer Slot testweise verwendet werden oder aber Einstellungen im Bios angepasst werden?
Sind die Caches der einzelnen Platten aktiv?

Zu RAID 5: Dieser RAID-Level benoetigt recht viele Rechenoperationen, sodass die Schreibgeschwindigkeit ungecacht meist sehr gering ist. Mit Cache ist die Schreibgeschwindigkeit oft im Bereich ein einzelnen Platte, wenn ich das hier einmal so ganz grob skizziere.
 
Also ich kriege hier auf einem 9550SXU-8LP mit 7 Platten im RAID5 und *ohne* BBU eine Schreibperformanz von 160MB/s auf das Dateisystem (also durch den VFS-Layer durch). Das ganze auf einem ... ja sagen wir RELENG_6_2 System.

Du solltest mal die Interruptrate mit vmstat -i ueberpruefen. Nach Möglichkeit sollte jeder Controller seine eigenen IRQ haben.
 
j_t]60MB/s ohne Schreibcache ist bei RAID5 und der Hardware wohl kaum erreichbar. Wie kommst du auf die kuehne Annahme? 3 schrieb:
Zu RAID 5: Dieser RAID-Level benoetigt recht viele Rechenoperationen, sodass die Schreibgeschwindigkeit ungecacht meist sehr gering ist. Mit Cache ist die Schreibgeschwindigkeit oft im Bereich ein einzelnen Platte, wenn ich das hier einmal so ganz grob skizziere.
Zum Vergrößern anklicken....
mein software-raid5 auf 5 platten macht unter netbsd per /dev/rraid0d ueber 70MB/s, d.h. ohne cache, der die noetigen rechenoperationen abfangen wuerde.
 
Dein Software-Raid5 auf 5 Platten benutzt indirekt fein den vorhandenen Arbeitsspeicher als Schreibcache um vorzugeben, dass die Daten schon geschrieben worden seien. In Wirklichkeit sind die Daten noch nicht tatsaechlich auf den Platten gelandet. Schreib doch mal ein File der vierfachen Groesse des RAM auf dein Laufwerk und stopp die Zeit, die dazu benoetigt wird.
 
wenn ich mit dd auf das rohdevice rraid0d schreibe, wird doch kein cache benutzt. ich rede nicht von irgendeinem filesystem.

die platten legen sofort beim absenden des kommandos los und hoeren auf, wenn's beendet ist. danach kommt auch keine aktivitaet mehr.
 
Es wird nicht der Cache des File systems verwendet. Der SW-RAID-Treiber hat seinen eigenen Cache, den er dazu benötigt, um die RAID 5-Berechnungen durchzuführen. Der Cache wird immer verwendet. Der Unterschied zwischen mit ohne ohne Write Cache liegt darin, daß ohne Schreibcache, das OS erst ein ok für ein Schreibkommando erhält, wenn auch von den Platten das ok zurückkam. Mit Write Cache enabled bekommt das OS das ok schon, wenn alle Daten im Cache vorhanden sind (ich beziehe mich hier auf den Cache des Controllers, bzw des SW-Treibers).
Für die Performance des RAID-Controllers ist zudem sehr wichtig die Stripe size korrekt zu setzen. Im Normalfall ist der Default value von 64k ok. Zudem ist wichtig welche Blockgröße das Filesystem verwendet.
 
didel schrieb:
Der SW-RAID-Treiber hat seinen eigenen Cache, den er dazu benötigt, um die RAID 5-Berechnungen durchzuführen. Der Cache wird immer verwendet. Der Unterschied zwischen mit ohne ohne Write Cache liegt darin, daß ohne Schreibcache, das OS erst ein ok für ein Schreibkommando erhält, wenn auch von den Platten das ok zurückkam. Mit Write Cache enabled bekommt das OS das ok schon, wenn alle Daten im Cache vorhanden sind (ich beziehe mich hier auf den Cache des Controllers, bzw des SW-Treibers).
Zum Vergrößern anklicken....
ich glaube, jetzt verwechselst du was.

der sw-raid-treiber fuehrt die berechnungen sicher im ram aus. das wuerde ich aber nicht als cache bezeichnen. deine beschreibung des write cache ist mir so nur von den platten direkt bekannt, die 8M oder 16M cache haben. davon hat aber der sw-raid-treiber nichts in dem sinne, dass es das schreiben beschleunigt. in den plattencache kommen die daten ja erst, wenn die parity schon berechnet ist.

ich glaube ausserdem nicht, dass ein cache im sw-raid-treiber fuer 70MB/s verantwortlich waere, wenn ich mehr daten schreiben lasse als die kiste ueberhaupt ram hat.

richtiges software-raid ist nicht langsam. die maerchen von maximal 10MB/s kann jeder selber widerlegen, indem er es einfach mal ausprobiert.

der hinweis mit den richtigen stripe-groessen und blockgroessen im filesystem ist hingegen goldrichtig. deswegen sollte man auch darauf achten, dass man 2^n+1 platten fuer ein raid5 benutzt.
 
Der SW- RAID-Treiber buffert wie man so schön im Neudeutsch sagt, die Daten, die auf die Platten geschrieben werden. Man könnte das mit einem Schreibcache vergleichen.

Die allgemein übliche Meinung, daß SW-RAID langsamer sind als HW-RAID kann verneint werden. In der Regel sind SW-RAID-Lösungen auch heute noch zum Teil erheblich schneller als HW-RAID-Controller (man denke nur an manche low-cost RAID controller). Neuere Controller kommen aber immer näher an SW-RAID-Lösungen heran.
Lediglich im Fehlerfall und beim Rebuild kann es sein, daß die SW-Lösung nicht an sehr schnelle RAID-Controller hinkommt. Die bessere Performance liegt einerseits an den heuten üblichen schnellen Prozessoren (üblich 3GHz und mehr oder 1.5GHz und mehr bei Dualcore) Dem stehen Prozessoren in RAID-controller bis ca. 800MHz zur Verfügung. Zudem ist die Leistung des RAID controller abhängig von seiner Architektur, daher kann man nicht einfach sagen, dieser Controller ist schneller, weil er eine schnellere CPU hat.
Der RAID-Controller hat aber einige andere Vorteile weshalb er ja auch verwendet wird. Performance ist nicht alles.
 
didel schrieb:
Der SW- RAID-Treiber buffert wie man so schön im Neudeutsch sagt, die Daten, die auf die Platten geschrieben werden. Man könnte das mit einem Schreibcache vergleichen.

Die allgemein übliche Meinung, daß SW-RAID langsamer sind als HW-RAID kann verneint werden. In der Regel sind SW-RAID-Lösungen auch heute noch zum Teil erheblich schneller als HW-RAID-Controller (man denke nur an manche low-cost RAID controller). Neuere Controller kommen aber immer näher an SW-RAID-Lösungen heran.
Lediglich im Fehlerfall und beim Rebuild kann es sein, daß die SW-Lösung nicht an sehr schnelle RAID-Controller hinkommt. Die bessere Performance liegt einerseits an den heuten üblichen schnellen Prozessoren (üblich 3GHz und mehr oder 1.5GHz und mehr bei Dualcore) Dem stehen Prozessoren in RAID-controller bis ca. 800MHz zur Verfügung. Zudem ist die Leistung des RAID controller abhängig von seiner Architektur, daher kann man nicht einfach sagen, dieser Controller ist schneller, weil er eine schnellere CPU hat.
Der RAID-Controller hat aber einige andere Vorteile weshalb er ja auch verwendet wird. Performance ist nicht alles.
Zum Vergrößern anklicken....

Das klingt, imho, nach relativen blödsinn ...

1. "billige" Raidcontroller, lassen das ganze meist _auch_ den Treiber/ den Prozessor machen, (insb. die auf Desktop-Mainboards verbauten dinger die sich "raid" nennen).

2. Wenn es der Prozessor des Systems macht, bedeutet das, das die leistung, die für das Raid gebraucht wird, anderen Programmen NICHT mehr zur verfügung steht - mag sein das das raid selbst dann schneller ist - die restlichen applikationen werden es ganz sicher nicht danken!
 
überprüfe mal mit tw_cli dem Command line tool den Controller und die Platten. Vielleicht findest du ja da mögliche Anomalien. wenn du tw_cli ohne parameter aufrufst, gib help info ein für weitere infos. du kannst dort den Status des Controllers des log. Laufwerks und der einzelnen Platten abrufen.
 
Ich habe das selbe Problem und eine ähnliche Konfiguration. Vielleicht hilft ja das ein
odere andere Detail das Problem einzugrenzen.


Board: Intel SE7210TP1-E (Pentium 4, 2.26Ghz)
OS: FreeBSD 6.1-RELEASE-p7 i386, UP

Platten: 8x Western Digital Caviar RE 320GB
Code: 
Device Model:     WDC WD3200SD-01KNB0
Firmware Version: 08.05J08

Raid: 3ware 9550SX-8LP, Raid5 8x320GB, Write Cache aktiv, keine BBU

Code: 
nas2# dmesg | grep "twa"
twa0: <3ware 9000 series Storage Controller> port 0xbc00-0xbc3f mem 0xfa000000-0xfbffffff,0xfc5ff000-0xfc5fffff irq 24 at device 2.0 on pci2
twa0: [GIANT-LOCKED]
twa0: INFO: (0x15: 0x1300): Controller details:: Model 9550SX-8LP, 8 ports, Firmware FE9X 3.04.01.011, BIOS BE9X 3.04.00.002

Ich bin bisher davon ausgegangen, dass die Platten daran schuld sind denn wenn ich konstant mit ca 30MB/Sec
auf das Raid schreibe ist alles okay. Aber so irgendwo bei 35 bis 40MB/Sec fangen die Problem dann an.

Dann zeigt sich, dass Port 4 und 5 Drive Timeouts melden. Sobald die Transferrate wieder nachlässt und unter diesen Schwellenwert fällt ist wieder alles okay. Sehr oft treten die Meldungen auch schön abwechselnd auf und _nur_ auf diesen 2 Platten. Bisher ist diese Meldung noch auf keiner der anderen 6 Ports aufgetreten.


- Laut smartctl mit Long und Short tests sowie S.M.A.R.T sind die Platten okay. (alle 8)
- Wechseln der SATA Kabel hat keine Auswirkung.
- Eine neuere Firmware für die Platten gibt es auch nicht.
- Der 3ware Controller hat die neueste Firmware und einen IRQ für sich alleine.


Was hat es mit der BBU in diesem Fall auf sich? Kann das schon irgendjemand erklären was sich da abspielt? Oder hat schon jemand 3ware danach gefragt?

Wenn jemand Ideen hat bin ich gerne bereit weiter zu testen um das Problem einzugrenzen. Es sind zwar Daten auf dem Array aber ich mache mittlerweile wöchentlich ein volles Backup.
 
Steckt der RAID-Controller in einem PCI-Slot?
Wenn ja, ist der Busmaster-fähig?

Wenn nicht, dann Slot wechseln.

Gruss...

Der Indy
 
indy schrieb:
Steckt der RAID-Controller in einem PCI-Slot?
Wenn ja, ist der Busmaster-fähig?
Zum Vergrößern anklicken....

Ja steckt in einem 64-bit/66MHz PCI-X Slot. Laut Blockschaltbild hängen alle 3 PCI-X Slots auf einem PCI Bus; auf Slot 1 hängt der 3ware die anderen 2 sind leer.

Laut Dokumentation unterstützt der verbaute 6300ESB I/O Controller 4 externe Bus Master aber wie die aufgeteilt sind wird nicht erwähnt. Gibt es eine Möglichkeit das raus zu finden?

Ich hab dabei außerdem in der Dokumentation entdeckt, dass Slot 1 in dem die Karte steckt wohl ein Extrawürstchen zu sein scheint.

The ZCR add-in cards leverage the on-board SCSI controller along with their own built-in intelligence to provide a complete RAID controller subsystem on-board. The riser card and baseboard use an implementation commonly referred to as RAID I/O Steering (RAIDIOS) specification version 0.92 to support this feature. If either of these supported RAID cards are installed, then the SCSI interrupts are routed to the RAID adapter instead of to the PCI interrupt controller.
Zum Vergrößern anklicken....

Das klingt für mich zumindest so als könnte das potentiell Probleme begünstigen. Ich werde also am Abend die Karte in einen anderen Slot stecken und testen ob es Unterschiede gibt.
 
So ich hab den Controller jetzt in Slot 2 aber das Problem besteht immer noch.

Code: 
nas2# iostat da0 -w 3
      tty             da0             cpu
 tin tout   KB/t tps  MB/s  us ni sy in id
   0   14 127.02 316 39.26   5  0 34 27 34
   0   15 128.00 411 51.32   4  0 31 21 44
   0   15 128.00 410 51.26   4  0 29 25 41
   0   15 128.00 405 50.59   5  0 29 25 40
   0  214 128.00 310 38.73   4  0 22 18 56
   0   15 127.90 381 47.64   4  0 25 21 50
   0   15 128.00 390 48.76   3  0 34 22 41
   0   15 127.15 399 49.59   5  0 34 21 40
   0   15 128.00 402 50.22   5  0 26 24 44
   0   15 127.69 401 50.01   4  0 29 19 47
   0   15 127.25  85 10.60   1  0  6  5 88
   0   15   0.00   0  0.00   0  0  0  0 100
   0   15   0.00   0  0.00   0  0  0  0 100

Ich hab für den Test einfach per Samba ein paar größere Files raufkopiert nach ca 35sek bricht der Transfer ein und die gewohnte Meldung ein paar Sekunden später.

Code: 
Jan  3 18:41:56 nas2 kernel: twa0: ERROR: (0x04: 0x0009): Drive timeout detected: port=5
 
Hallo.

Ich habe hier mit dem gleichen Problem zu kämpfen: Drive timeout detected :mad:
Hat jemand inzwischen eine eine Konfiguration gefunden, mit der der Controller zuverlässig betrieben werden kann?

Bei mir läuft übrigens ein Raid 10 (Port 0 & 1 und 3 & 4 als Raid 0). Betroffen sind immer nur Port 1 und 3, so dass es derzeit noch nicht zu einem Datenverlust kam. Aber ich dreh schier durch ...

LG!
 
Ich hab in den letzten Wochen einiges ausprobiert was einem von diversen Seiten so empfohlen wird aber leider bisher ohne Erfolg. Etwas gebessert hat sich die Situation als ich ein SATA Kabel mit 60cm gegen eines mit 50cm getauscht habe.
Jetzt schaffe ich zumindest schon ein paar Minuten Volllast bis ein Drive Timeout auftritt.

@blickdicht: kannst du deine Konfiguration etwas genauer beschreiben? OS, HDDs, Controller, Firmware ...
 
Re.

Also ich betreibe den Controller an einem Tyan Tiger 7320 (dual Xeon) mit vier 250 GB Platten im Raid 10. Das ganze laeuft unter Debian mit Linux 2.6.18 als Datenbankserver. Timeouts treten bei mir bisher nur an Port 1 und 3 auf - was interessant sein kann, weil diese Platten ja gespiegelt sind.
Die Timeouts treten übrigens bei mir eher selten auf: so alle 2 bis 3 Wochen. Gestern Nacht allerdings gleich zwei Platten.

Der Controller ist ein 9550SXU-4LP (Firmware FE9X 3.04.00.005, Treiber-Version 2.26.02.007, BIOS-Version BE9X 3.04.00.002). Schreibcache ist übrigens aus! Keine BBU. Er steckt im einzigen Slot auf dem Board: 66 MHz.

Die Platten sind vier identische WDs aus der Raid-Edition (YS). Eine Seagate war auch mal dran, die dann auch ein Timeout produzierte. Alle SMART-Werte im grünen Bereich; auch kurz vor den Timeouts.

Die Platte an Port 1 power-cycled sich manchmal, weshalb ich die letztlich getauscht hab. Bisher keine power-cycles mehr.

Da die Verkabelung, Stromanschluss etc. auch in der Fehlerbeschreibung der Timeouts vorkommen, hier mal was dazu. Es sind einfach SATA-Kabel (ich glaub von reichelt, also eher billig) mit 50 cm Länge. Die PSU (460 W) ist von Tyan für das Board empfohlen, was die wohl nicht machen, wenn da nicht noch 6 Platten mit betrieben werden könnten.

Morgen werde ich den Rechner rebooten und die HDDs werden wohl wieder eingebunden werden. Das Kabel tausche ich mal gegen welche mit 30 cm Länge. Ich hoffe, dass ich da noch bis zum Controller hinkomm ...

Gruss!
 
Danke. Die Beschreibung für das Update klingt ja schon mal vielversprechend.

Von der WD-Seite:
Description:
This firmware resolves an issue where a WD1600YS, WD2500YS, WD4000YS, or WD5000YS hard drive is dropped from a RAID set without reporting errors after a period of normal usage. This utility is designed to upgrade the firmware of the following hard drives:

* WD1600YS
* WD2500YS
* WD4000YS
* WD5000YS
Zum Vergrößern anklicken....
Dann werd ich die 50-cm-Kabel erstmal dranlassen und nacheinander die Firmware updaten. Um die Daten auf dem Raid aber nicht zu verlieren, müsst ich das nacheinander machen und das Raid müsst sich zwischendurch immer wieder neu aufbauen. Da muss ich ja nen Schlafsack mit in Serverraum nehmen! :mad:

Ich meld mich dann mal in (hoffentlich erst) ein paar Wochen mit dem (auch hoffentlich positiven) Ergebnis.

Bis dahin!
 
3Ware probleme...

Juhuu!

Ich weiss, das erhebliche Probleme auftauchen, wenn der Controller nicht in einem 64bit Slot Sitzt und von weniger als 133MHz Busfrequenz angesteuert wird. Das kann sein, das Platten nicht erkannt werden, oder Timeout auftreten. Oder auch das Platten nach einer Zeit ausfallen, ohne wirklich einen defekt aufzuweisen!

Beim Controller in jedem Fall die FW auf den neusten Stand bringen!

Der Schreibcache sollte im Übrigen Aktiviert bleiben wg der Performance.
Die Warnmeldung die erscheint mit einem Lächeln ignorieren --> so :)
Eine BBU macht nur bei HA Anwendungen bzw Datenbanken Sinn, bei denen das Raid stark ausgelastet wird.
Bei einem Stromausfall können die letzten schreib-aktivitäten nicht mehr auf das Raid gebracht werden können. Hier versorgt die BBU den Schreibcache des Controllers einige Zeit, um den Cache mit dem Raid beim wiedereinschalten abzugleichen --> kein Daten verlust.

Was auch möglich ist: Platten differierend gejumpert SATA 150/300. Falls die Platten in einem Platten-Rahmen verbaut sind ist die Backplane zu Cheken!
Habe ich auch mehr als einmal gesehen - selbst einfachest Platinen können Probleme verursachen.
Die WD Firmware ist sicher auch ein Trick.:D

Gruss vom Michel
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben