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)
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)
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 75022
Url: https://administrator.de/contentid/75022
Ausgedruckt am: 22.11.2024 um 08:11 Uhr
2 Kommentare
Neuester Kommentar
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
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