oiledamoeba
Goto Top

SIL 3114 und Raid 1 - Sofort Status Reduced

Hallo,

folgendes Problem: Ich habe mir vor kurzem zwei Hitachi 250 GB SATA2 Platten gekauft. Diese habe ich an eine PCI32 Karte mit SIL3114 Chip gehängt.
Dass die Karte wegen dem Chip "nur" SATA1 fährt, ist mir egal, da die Platten ja auch nur "umgemünzte" PATA-Platten sind. Die bringen eh nicht die SATA2 Leistung. Laut Hersteller schalten die sich sogar selbsttätig auf SATA1 runter, wenn ein entsprechender Anschluss gefunden wird.
Aber egal, ich schweife ab.
Also: Ich weiß, dass der SIL3114 nur ein Hostadapter für SoftRAID ist. Trotzdem kann der die Platten im RAID1 booten.

Und genau das habe ich gemacht: Im Bios des Adapters habe ich die beiden Platten zu einem 232GB-RAID1 zusammengeschlossen. Wenn ich nun XP hochfahre, meldet mir die Software "SATARAID5Manager", dass der Status des Verbundes "reduced" sei (Group 0 "legacy" status: REDUCED).
Er legt sofort im Task-Manager (nicht im Win Taskmanager, sondern im Treiber-eigenen) den Task "Restore Redundancy, group 0, region 0, Highwater Mark 0" an.
Wenn ich die Platten jedoch platt mache und das Raid1 erst unter Win mit dem Treiber anlege, kann ich starten, sooft ich will, der Status ist immer "ok".
Woran liegt das? Was macht der Win-Treiber anders, als das Host-Bios? Nebenbei: Der über den Treiber erstellte Raid1-Verbund kann zwar partitioniert, nicht aber formatiert werden. Das Bios-Raid macht dabei jedoch keine Probleme...

Und vor allem: Die Synchronisierung dauert jetzt schon 11 Stunden und der Taskmanager erwartet noch weitere 6 Stunden. (Aktuell steht der Task bei 49%)
Warum dauert das so lange und wie kann ich das beschleunigen? Das muss doch schneller gehen... Die Blöcke von 232GB zu kopieren kann doch nicht so lange dauern. Der Taskmanager von Windows sagt dazu: Prozessorauslastung 1%. Und die Festplatten-LED deutet auch nicht unbedingt auf hohe Aktivität hin. Eine Änderung der Prio für den Recovery-Task bringt jedoch keine Besserung, im Gegenteil. Die Prio 10 scheint für die Software die höchste Prio darzustellen, da ein umschalten auf Prio 1 den Task sogar noch länger laufen lässt.
Der PC ist seit dem Start heute morgen ununterbrochen NICHT ausgelastet, ich habe alle Prozesse, bis auf die systemkritischen, terminiert. Sogar die INet-Verbindung ist getrennt und der Virenscanner aus. Diese Laufzeit des Tasks bringt mich zur Weißglut...

Rechenbeispiel (hoffentlich richtig...): 232 GB = 237568 MB / 133 MB = 1786,23 Sekunden, also etwa 29 Minuten.
Wenn ich mich nicht enorm verrechnet habe, dann kann der PCI32 ja mit seinen (theor.) 133MB/s eine 232GB Platte in etwa 30 Minuten komplett auslesen. Da aber bei einem SoftRaid die Daten nicht über den Controller auf den Platten verteilt werden, sondern über den Treiber, muss beim Spiegeln, bzw. Neuaufbau des Raid, alles durch den PCI-Hals. Also nur noch 62,5MB/s zur Verfügung. Damit wären wir aber immer noch im Bereich von einer Stunde für den ollen Task. Sollten es nicht MB, sondern MBit sein, sind wir bei acht Stunden. Aber nicht bei 15, wie es der Treiber behauptet.

Ach ja, in diesem Raid1 existieren 2 Partitionen, eine Primäre und eine Erweiterte mit vier logischen Laufwerken.

Hach, wenn ich doch nur einen FibreChannel-Controller und passende Laufwerke hätte, wie in der Firma... Dann würden 5GB nur 24 Sekunden dauern und die 232GB also umgerechnet auch nur etwa 19 Minuten.... *träum*

So, beim drüberlesen ist der Text etwas komisch geschrieben, stell ich gerade fest. Also konkret noch mal die Fragen rausgestellt:
1. Warum ist der Status des Raid1 sofort "reduced", wenn das Raid1 über das Bios aufgebaut wird?
2. Warum ist dann das über die Software aufgebaute Raid1 immer i.O.?
3. Warum kann das Treiber-Raid1 nicht formatiert werden, während das Bios-Raid ohne Probleme formatiert wird?
4. Kann ich die Geschwindigkeit des "Rebuild"-Vorgangs beschleunigen, dass es wenigstens den PCI32-Spezifikationen entspricht, oder diesen nahe kommt?
5. Wenn ich den PC über nun über Nacht das Raid weiter aufbauen lasse, habe ich eine möglichst hohe Garantie, dass das Raid nach einem Rechnerneustart noch i.O. ist, oder fängt der Controller dann wieder an, das Raid neu aufzubauen, weil er wieder meint, es wäre reduced?

Hmmm, habe ich alles?... Ich hoffe mal ja...

Gruß
Flo
(aka: OiledAmoeba)

Content-Key: 75022

Url: https://administrator.de/contentid/75022

Ausgedruckt am: 29.03.2024 um 04:03 Uhr

Mitglied: OiledAmoeba
OiledAmoeba 03.12.2007 um 17:47:28 Uhr
Goto Top
Hallo,

ich glaube, einige meiner Fragen selbst beantworten zu können... Man soll halt erst mal eine Nacht drüber schlafen... Oder erst denken, dann aufregen face-wink

1. Warum ist der Status des Raid1 sofort "reduced", wenn das Raid1 über das Bios aufgebaut wird?

Klar, weil das Raid erst aufgebaut werden muss. Er (der Treiber, oder der Controller) muss ja erst die Daten spiegeln, bevor die Checksum stimmen kann. Also erst mal "reduced", bis er fertig gespiegelt hat.

2. Warum ist dann das über die Software aufgebaute Raid1 immer i.O.?

Auch klar, weil er da nicht sofort spiegelt. Keine Ahnung, warum nicht, oder wann er das macht, aber er macht es nicht sofort. Er scheint nicht mal die Checksummen der beiden Platten zu prüfen, sonst würde er ein unvollständiges Raid entdecken (müsste dann also auch reduced melden und das spiegeln beginnen). Wohl ein Treiberfehler?

3. Warum kann das Treiber-Raid1 nicht formatiert werden, während das Bios-Raid ohne Probleme formatiert wird?

Hängt sicherlich mit 2. zusammen. Das Raid steht noch nicht, die Partitionen haben unterschiedliche Checksummen, Win nimmt nun sicherlich einen Fehler auf der Platte an. Vom Raid weiß Win ja direkt nichts. Den "Fehler" kann die Hardware auch nicht ausgleichen, da sie nichts vom Raid weiß, weil es nicht über den Adapter gebaut wurde und deswegen beim Rechnerstart nicht initialisiert wurde. Wird das Raid über den Adapter gebaut, so denke ich mir, gaukelt der Chip Windows "alles i.O." vor, weil er das Raid ja selbst initialisiert hat.

4. Kann ich die Geschwindigkeit des "Rebuild"-Vorgangs beschleunigen, dass es wenigstens den PCI32-Spezifikationen entspricht, oder diesen nahe kommt?

Keine Ahnung. Habe noch nichts dazu in meinen Hirnwindungen gefunden. Hier bräuchte ich doch noch mal externe Ideen.
Übrigens dauerte es 18 Stunden und 27 Minuten, um die beiden Platten zu synchronisieren. Bäh, das ist mir zu lange...

5. Wenn ich den PC über nun über Nacht das Raid weiter aufbauen lasse, habe ich eine möglichst hohe Garantie, dass das Raid nach einem Rechnerneustart noch i.O. ist, oder fängt der Controller dann wieder an, das Raid neu aufzubauen, weil er wieder meint, es wäre reduced?

Gerade probiert: Den Rechner angeschaltet, in das Raid-Tool gegangen und siehe da: Raid Status: GOOD. Wunderbar.

Sollte ich mit meinen obigen selbstgestellten Antworten falsch liegen, so korrigiert mich bitte!

Gruß
Flo
Mitglied: Senfmann
Senfmann 09.01.2012 um 20:36:05 Uhr
Goto Top
Hallo Flo,

hast du mittlerweile neue Erkentnise machen können?

Ich habe nämlich seit einiger Zeit dasselbe Problem. Der Status ist nach ein paar Wochen immer Reduced und die Synchronisation dauert extrem lange, so dass man sie nur abbrechen kann. Aus diesem Grund kann ich derzeit auch nicht den Verbund per Software neu einrichten (hab das damals direkt per Controller, also vor dem Hochfahren gemacht). Seltsamerweise war dies nicht von anfang an so... anfangs ging es sowohl vor dem Hochfahren als auch nachher unter Windows in normaler Geschwindigeit vonstatten.

Im Einsatz habe ich den DC-4320 von Dawicontrol mit Sil 3124 Chip. Als Festplatten zwei WD800AAJ von Western Digital.

Gruß,
Thomas