Kombination Mainboard + CPU für Server mit möglichst geringer Leerlauf-Stromaufnahme
Wolfgang Draxinger
von sowohl Intel als auch AMD in ihrer überschwänglichen
Phantasie einen so riesen Batzen verschiedener
Produktbezeichnungen hervorgebracht dass meinereiner total den
Überblick verloren hat.
Worum geht's: Seit einiger Zeit steht für mich fest, dass hier
endlich mal ein gescheiter Server her muss. Die momentane
Situation lässt sich unter "Flickschusterei" zusammenfassen.
Hauptaufgabe soll die Bereitstellung von Storage sein,
Linux-Software-RAID Level 6 (auf einen propritären Controller
will ich mich nicht einlassen). Daneben soll das Teil aber auch
als VDR, Fax, Anrufbeantworter, BitTorrent-Client, VPN-Gateway
und Webserver werkeln. Abgesehen vom VDR ist das alles recht
genügsam was CPU-Zyklen angeht und beim VDR fällt auch nur die
Rekodierung des Videomaterials in was speichersparendereres als
MPEG2 (was einem ja schon so komprimiert per DVB geliefert wird)
in die Kategorie "CPU-lastig". Das Linux-Software-RAID kommt auf
meiner Workstation (AMD Athlon 64 X2 4400+ @ 2.2GHz) unter
voller I/O-Last auf gerade mal max. 10% CPU-Last, wenn's
wirklich hart auf hart kommt. Und bei der Rekodierung von Video
darf's auch mal etwas länger dauern.
Nun wird das Ding allerdings die meiste Zeit vor sich hin idlen
und da ist es natürlich wünschenswert, wenn es dabei möglichst
wenig Saft zöge. Je weniger desto besser, denn es kommt ja noch
einiges an Peripherie dazu (Festplatten).
Das Mainboard sollte so wenig Hardware-Schnickschnack wie möglich
haben. Also keinen internen Sound, WLAN und auch auf VGA kann
ich verzichten, das braucht es alles nicht.
Was aber wichtig ist: GBit LAN, welches möglichst direkt an die
CPU angebunden ist, also nix von wegen NIC am PCI/PCI-E 1x.
Idealerweise hätte das Board sogar mehrere NICs, die man trunken
kann, zwei, oder sogar vier. Preislich gibt es da glaube ich nur
geringe Unterschiede. Ansonsten gibt es ja immer noch die
separaten NICs am PCI-E 8x/16x, nur sollte das Board dann auch
sowas aufnehmen können.
Ebenfalls wichtig wäre mir, eine ausreichende Anzahl an SATA-2
Ports zu haben. Mindestens 6, lieber 8. RAID müssen die aber
nicht können, das macht ja Linux. Ehrlich gesagt will ich
nämlich keinen separaten Controller verwenden, die kommen
nämlich alle _mit_ RAID und das wäre Perlen vor die Säue. Und
dann gibt es da ja auch noch die Möglichkeit mehrere Platten an
einen SATA-Kanal zu hängen (glaube ich), kann aber auch im
Zusammenhang mit E-SATA gewesen sein, zusammen mit speziellen
Gehäusen/Backplanes dafür. Dem bin ich nicht abgeneigt. SAS wäre
nett, ist aber nicht wirklich notwendig und ich halte es auch
für übertrieben.
Entsprechend viel RAM sollte das Board auch aufnehmen können (ich
tendiere zu 8GiB aus vier 2GiB-Modulen, natürlich FB ECC). Das
Kalkül ist, dass möglichst viel der Daten vom/zum RAID vom RAM
cached werden. Gerade wenn immer nur einzelne Dateien als
Brocken übertragen werden funktioniert das erstaunlich gut und
man kann die >1GiB/s Netz-I/O sogar kurzzeitig voll ausnutzen.
Das sind die Rahmenbedingungen. Jetzt die Frage: Was für eine
Kombination aus Mainboard(-Hersteller) Chipsatz und CPU ist
dafür der beste Kompromiss. Qualität geht vor, an der falschen
Stelle werde ich nicht sparen. Wichtigstes Kriterium ist jedoch
die Sparsamkeit im Leerlauf. Wenn's was zu tun gibt, darf es
sich aber schon etwas mehr gönnen. Und je nach CPU werde ich
auch ausgiebig Gebrauch davon machen, das Teil mit reduzierter
Kernspannung zu betreiben, d.h. es darf ruhig eine etwas
potentere/teurere CPU sein, die damit aber besser klar kommt.
Ich bin offen für sowohl AMD als auch Intel.
Intels Server-Boards gefallen mir recht gut, allerdings scheinen
deren CPUs mehr Saft zu brauchen. Dafür spielen die Intel
Server-Boards auch mit normalen Core2 zusammen und man muss
nicht gleich zum Xeon greifen.
AMD dagegen scheint die sparsameren CPUs zu haben, aber sind mir
bei meiner letzten Recherche keine servertauglichen Boards
untergekommen, die normale Athlons fressen. Es scheint zu gelten
AMD ^ Server => Opteron. Ansonsten => Gaming.
Allerdings wird in den Datenblättern immer nur die max.
Leistungsaufnahme genannt, so dass ich mir denke, dass es
durchaus sein könnte, das ein Core2 im Idle, wenn er dann auch
noch runtergetaktet wurde und per HALT-Instruktion Schlafen
gelegt wurde, doch sparsamer sein könnte als ein entsprechender
AMD.
Das ist jetzt ein Double-Post in sowohl AMD- als auch
Intel-Newsgroups, aber ohne F'up. Je nach Hersteller die
Antworten bitte (manuell) in die jeweils zugehörige/korrekte
Newsgroup posten.
So, die Diskussion/Flamewar/Besserwisserei/etc. ist eröffnet ;-)
Wolfgang Draxinger
P.S.: Ich bin auch anderen CPU-Architekturen (Sun SPARC,
CoolThreads) nicht abgeneigt, aber die gehen leider richtig in's
Geld, da nicht Mainstream und zumindest die CoolThreads kann man
für Videorekodierung vergessen.
--
E-Mail address works, Jabber: hexa...@jabber.org, ICQ: 134682867
Jan Heichler
<wdrax...@darkstargames.de> wrote:
>Nun wird das Ding allerdings die meiste Zeit vor sich hin idlen
>und da ist es natürlich wünschenswert, wenn es dabei möglichst
>wenig Saft zöge. Je weniger desto besser, denn es kommt ja noch
>einiges an Peripherie dazu (Festplatten).
Wieviele Platten sollen es denn sein?
>
>Das Mainboard sollte so wenig Hardware-Schnickschnack wie möglich
>haben. Also keinen internen Sound, WLAN und auch auf VGA kann
>ich verzichten, das braucht es alles nicht.
Ohne Sound wird auf jeden Fall schwer. Und "mit VGA" kann ich bzgl.
der Leistungsaufnahme nur empfehlen - es sei denn du willst das Teil
komplett ohne VGA betreiben und nur per tty arbeiten.
>
>Was aber wichtig ist: GBit LAN, welches möglichst direkt an die
>CPU angebunden ist, also nix von wegen NIC am PCI/PCI-E 1x.
Wie soll das denn direkt an die CPU angebunden sein? Per FSB? Oder
HyperTransport?
Solch eine Implementierung ist mir nicht bekannt und auch IMHO
reichlich überflüssig. Eine einzelne PCIe-Lane reicht gut aus um alles
vom und zum NIC zu transportieren - ohne GigE auszubremsen.
>Idealerweise hätte das Board sogar mehrere NICs, die man trunken
>kann, zwei, oder sogar vier.
In welchem Modus willst du denn trunken? Und was soll über den Trunk
laufen? Was ist das Ziel dieses Vorgehens und was steht auf der
anderen Seite (Clients).
>Preislich gibt es da glaube ich nur
>geringe Unterschiede. Ansonsten gibt es ja immer noch die
>separaten NICs am PCI-E 8x/16x, nur sollte das Board dann auch
>sowas aufnehmen können.
Alles was als Steckkarte kommt kostet normalerweise mehr Energie -
versuch also alles was du möchtest auf dem Board zu haben.
>Und
>dann gibt es da ja auch noch die Möglichkeit mehrere Platten an
>einen SATA-Kanal zu hängen (glaube ich), kann aber auch im
>Zusammenhang mit E-SATA gewesen sein, zusammen mit speziellen
>Gehäusen/Backplanes dafür. Dem bin ich nicht abgeneigt. SAS wäre
>nett, ist aber nicht wirklich notwendig und ich halte es auch
>für übertrieben.
Es gibt für Sata "Port-Multiplier" (glaub die heissen so) -
Alternative wäre dann SAS mit einer Backplane und z.B. einer x4
Verbindung dahin. Dann bewegst du dich (vor allem preislich) aber
bereits im professionellen Bereich.
>Entsprechend viel RAM sollte das Board auch aufnehmen können (ich
>tendiere zu 8GiB aus vier 2GiB-Modulen, natürlich FB ECC). Das
? FB ECC? FullyBuffered? Oder wofür steht bei dir das FB?
>Kalkül ist, dass möglichst viel der Daten vom/zum RAID vom RAM
>cached werden.
Bist du dir sicher das Linux RAM als Schreibcache einsetzt? In
Dimensionen von GByte? Das wäre etwas gefährlich.
>Gerade wenn immer nur einzelne Dateien als
>Brocken übertragen werden funktioniert das erstaunlich gut und
>man kann die >1GiB/s Netz-I/O sogar kurzzeitig voll ausnutzen.
>
>Das sind die Rahmenbedingungen. Jetzt die Frage: Was für eine
>Kombination aus Mainboard(-Hersteller) Chipsatz und CPU ist
>dafür der beste Kompromiss. Qualität geht vor, an der falschen
>Stelle werde ich nicht sparen. Wichtigstes Kriterium ist jedoch
>die Sparsamkeit im Leerlauf. Wenn's was zu tun gibt, darf es
>sich aber schon etwas mehr gönnen. Und je nach CPU werde ich
>auch ausgiebig Gebrauch davon machen, das Teil mit reduzierter
>Kernspannung zu betreiben, d.h. es darf ruhig eine etwas
>potentere/teurere CPU sein, die damit aber besser klar kommt.
Die C't hat mit bestimmten Kombinationen aus AMD-DualCores und
AMD-Chipsätzen idle-Aufnahmen von 40W erreicht. Allerdings mit nur
einer Platte und entsprechend kleinem Netzteil.
>Ich bin offen für sowohl AMD als auch Intel.
>
>Intels Server-Boards gefallen mir recht gut, allerdings scheinen
>deren CPUs mehr Saft zu brauchen. Dafür spielen die Intel
>Server-Boards auch mit normalen Core2 zusammen und man muss
>nicht gleich zum Xeon greifen.
Die SingleSocket Boards können auch Core2 - dafür sind die
SingleSocket Xeons auch nur 10 oder 20 EUR teurer (IIRC) - da seh ich
den Vorteil nicht.
>AMD dagegen scheint die sparsameren CPUs zu haben, aber sind mir
>bei meiner letzten Recherche keine servertauglichen Boards
>untergekommen, die normale Athlons fressen. Es scheint zu gelten
>AMD ^ Server => Opteron. Ansonsten => Gaming.
Du vergleichst hier Äpfel mit Birnen wie es mir scheint. Im 1-Sockel
Bereich sind Opteron 1xxx und Athlon64 normalerweise auch im gleichen
Board lauffähig.
Generell nimmt Intel wohl weniger Leistung unter Last auf
(insbesondere Performance/Watt ist besser) und AMD gewinnt bei idle.
Vor allem weil die Chipsätze für INtels einiges an Energie fressen.
Ich würde also klar zu AMD raten. Da gibt es CPUs mit einer ACP von
45W.
>
>Allerdings wird in den Datenblättern immer nur die max.
>Leistungsaufnahme genannt, so dass ich mir denke, dass es
>durchaus sein könnte, das ein Core2 im Idle, wenn er dann auch
>noch runtergetaktet wurde und per HALT-Instruktion Schlafen
>gelegt wurde, doch sparsamer sein könnte als ein entsprechender
>AMD.
Siehe oben.
>P.S.: Ich bin auch anderen CPU-Architekturen (Sun SPARC,
>CoolThreads) nicht abgeneigt, aber die gehen leider richtig in's
>Geld, da nicht Mainstream und zumindest die CoolThreads kann man
>für Videorekodierung vergessen.
Vergiss das gleich wieder - du wirst deine Ziele damit nicht so recht
erreichen.
Denk aber vielleicht noch über folgende Punkte nach:
- 2,5" Platten sind weniger Leistungshungrig
- es gibt eine Serie von Hitachi Deskstars in 3,5" die unter 5W idle
aufnehmen - das ist weniger als die 8 bis 10W anderer Platten. Wenn du
tatsächlich über 8 Platten nachdenkst, dann kannst du hier evtl. so
viel Leistung sparen wie der Rest vom System schluckt
- dimensioniere das Netzteil vernünftig
- jede Steckkarte nimmt Leistung auf - reduziere deren Anzahl
- jdes Speichermodul nimmt Leistung auf - auch hier mal drüber
nachdenken auf 2 x 4GB zu gehen (statt 4 x 2GB) - aber das wird
vermutlich preislich unattraktiv
Gruß
Jan
Wolfgang Draxinger
> On Tue, 23 Sep 2008 23:24:54 +0200, Wolfgang Draxinger
> <wdrax...@darkstargames.de> wrote:
>
>>Nun wird das Ding allerdings die meiste Zeit vor sich hin idlen
>>und da ist es natürlich wünschenswert, wenn es dabei möglichst
>>wenig Saft zöge. Je weniger desto besser, denn es kommt ja noch
>>einiges an Peripherie dazu (Festplatten).
>
> Wieviele Platten sollen es denn sein?
Vorerst 6 Stück. Die sollen aber heruntergefahren werden, wenn
kein Client angemeldet ist und auch sonst keine I/O auftritt. Da
die Platten sowieso nur bis zur Abschreibung drin bleiben ist
mir die Alterung durch Spin-Up/-Down ziemlich schnurz.
> Ohne Sound wird auf jeden Fall schwer. Und "mit VGA" kann ich
> bzgl. der Leistungsaufnahme nur empfehlen - es sei denn du
> willst das Teil komplett ohne VGA betreiben und nur per tty
> arbeiten.
Jup, tty reicht mir völlig, wozu brauche ich VGA? Muss natürlich
auch vom BIOS/EFI unterstützt werden.
> In welchem Modus willst du denn trunken? Und was soll über den
> Trunk laufen? Was ist das Ziel dieses Vorgehens und was steht
> auf der anderen Seite (Clients).
Für's Trunken gibt's ja allerlei Möglichkeiten. Einmal in
Software, per Interface-Bond. Und dann gibt's da noch das
Trunken auf Ethernet-Ebene, welches Zusammenarbeit mit dem
Switch erfordert. Letzteres würde ich gerne haben, da der Switch
den ich hier stehen habe dafür geeignet ist.
> Alles was als Steckkarte kommt kostet normalerweise mehr
> Energie - versuch also alles was du möchtest auf dem Board zu
> haben.
Das ist mein Ziel.
> ? FB ECC? FullyBuffered? Oder wofür steht bei dir das FB?
Jup, Fully Buffered. Die meisten richtigen Serverboards fressen
ja nur das.
>
>>Kalkül ist, dass möglichst viel der Daten vom/zum RAID vom RAM
>>cached werden.
>
> Bist du dir sicher das Linux RAM als Schreibcache einsetzt? In
> Dimensionen von GByte? Das wäre etwas gefährlich.
Tut es, wenn man es entsprechend konfiguriert. Gefährlich ist das
nur, wenn die Gefahr besteht, dass die Kiste unvermittelt
abschmiert. Das heißt im Falle von Linux: Stromausfall. 1.4kWh
USV ist hier aber schon vorhanden.
> Die C't hat mit bestimmten Kombinationen aus AMD-DualCores und
> AMD-Chipsätzen idle-Aufnahmen von 40W erreicht. Allerdings mit
> nur einer Platte und entsprechend kleinem Netzteil.
Nun ja, im Idle fallen ja die Platten weg, da die Schlafen gelegt
werden.
> Die SingleSocket Boards können auch Core2 - dafür sind die
> SingleSocket Xeons auch nur 10 oder 20 EUR teurer (IIRC) - da
> seh ich den Vorteil nicht.
Fressen die Xeons nicht mehr Saft?
Wolfgang Draxinger
Jan Heichler
<wdrax...@darkstargames.de> wrote:
>Jan Heichler wrote:
>
>> On Tue, 23 Sep 2008 23:24:54 +0200, Wolfgang Draxinger
>> <wdrax...@darkstargames.de> wrote:
>>
>>>Nun wird das Ding allerdings die meiste Zeit vor sich hin idlen
>>>und da ist es natürlich wünschenswert, wenn es dabei möglichst
>>>wenig Saft zöge. Je weniger desto besser, denn es kommt ja noch
>>>einiges an Peripherie dazu (Festplatten).
>>
>> Wieviele Platten sollen es denn sein?
>
>Vorerst 6 Stück. Die sollen aber heruntergefahren werden, wenn
>kein Client angemeldet ist und auch sonst keine I/O auftritt. Da
>die Platten sowieso nur bis zur Abschreibung drin bleiben ist
>mir die Alterung durch Spin-Up/-Down ziemlich schnurz.
Okay. Mit 6 Platten und Software RAID wirst du vermutlich eine
Schreibrate von max. 200 MB/s erreichen können (100% linear IO in
großen Blöcken) - das für später ;-)
>
>> Ohne Sound wird auf jeden Fall schwer. Und "mit VGA" kann ich
>> bzgl. der Leistungsaufnahme nur empfehlen - es sei denn du
>> willst das Teil komplett ohne VGA betreiben und nur per tty
>> arbeiten.
>
>Jup, tty reicht mir völlig, wozu brauche ich VGA? Muss natürlich
>auch vom BIOS/EFI unterstützt werden.
Ich fand es immer gut wenn ich einfach so nen Monitor anschliessen
konnte. Irgendwann braucht man es mal. Wenn du über richtige
Serverhardware nachdenkst: nimm IPMI mit KVM-over-IP. Dann hast du
alles was du brauchst auf dem Desktop.
>
>> In welchem Modus willst du denn trunken? Und was soll über den
>> Trunk laufen? Was ist das Ziel dieses Vorgehens und was steht
>> auf der anderen Seite (Clients).
>
>Für's Trunken gibt's ja allerlei Möglichkeiten. Einmal in
>Software, per Interface-Bond. Und dann gibt's da noch das
>Trunken auf Ethernet-Ebene, welches Zusammenarbeit mit dem
Das ist alles in Software...
>Switch erfordert. Letzteres würde ich gerne haben, da der Switch
>den ich hier stehen habe dafür geeignet ist.
... und du meinst vermutlich 802.3ad. Dir ist klar das damit eine
einzelne Verbindung niemals schneller als ein einzelner Link wird?
Also zwei Rechner mit je zwei Interfaces nach 802.3.ad können bei
einem einzelnen Datenstrom trotzdem nur 1 GBit/s austauschen.
Und: woher sollen die Daten kommen? Dein Software-Raid wird vermutlich
gerade dazu reichen einen GBit-Link mit 100 MB/s wirklich auszulasten
(immer dran denken das NFS und SMB auch ziemlich performance fressen -
und Software RAID aufwändig ist).
>> ? FB ECC? FullyBuffered? Oder wofür steht bei dir das FB?
>
>Jup, Fully Buffered. Die meisten richtigen Serverboards fressen
>ja nur das.
Das stimmt so aber nicht. FB-DIMM brauchst du bei Xeons der 5000er und
7000er Serie. Xeons der 3000er Serie (Single-Socket) nehmen DDR2 mit
ECC und Pufferung.
>>
>>>Kalkül ist, dass möglichst viel der Daten vom/zum RAID vom RAM
>>>cached werden.
>>
>> Bist du dir sicher das Linux RAM als Schreibcache einsetzt? In
>> Dimensionen von GByte? Das wäre etwas gefährlich.
>
>Tut es, wenn man es entsprechend konfiguriert.
Hast du dafür ein Howto oder Whitepaper? Das würde mich mal im Detail
interessieren.
>Gefährlich ist das
>nur, wenn die Gefahr besteht, dass die Kiste unvermittelt
>abschmiert. Das heißt im Falle von Linux: Stromausfall. 1.4kWh
>USV ist hier aber schon vorhanden.
Da gibt es noch den ein oder anderen Schwachpunkt - vermutlich alles
daheim zu verkraften. Aber wenn dann plötzlich 4 Gigabyte im
Filesystem fehlen bzw. inkonsistent sind ist das Geschrei wieder groß
;-)
>> Die SingleSocket Boards können auch Core2 - dafür sind die
>> SingleSocket Xeons auch nur 10 oder 20 EUR teurer (IIRC) - da
>> seh ich den Vorteil nicht.
>
>Fressen die Xeons nicht mehr Saft?
Nicht das ich wüsste. Es ist ja die gleiche CPU.
Gruß
Jan
Martin Bodenstedt
> Hauptaufgabe soll die Bereitstellung von Storage sein,
> Linux-Software-RAID Level 6 (auf einen propritären Controller
> will ich mich nicht einlassen).
Warum nimmst Du nicht ein MoBo, auf dem das Raid in hardware (schon im
Bios!) gemacht wird. Dann sieht das OS gar kein Raid sondern nur das
eine laufwerk. Also brauchst Du auch keine proprietären Treiber und
entlastest die CPU obendrein...
--
Martin Bodenstedt
Jan Heichler
<martin.b...@gmx.de> wrote:
>Wolfgang Draxinger schrieb:
>
>> Hauptaufgabe soll die Bereitstellung von Storage sein,
>> Linux-Software-RAID Level 6 (auf einen propritären Controller
>> will ich mich nicht einlassen).
>
>Warum nimmst Du nicht ein MoBo, auf dem das Raid in hardware (schon im
>Bios!) gemacht wird. Dann sieht das OS gar kein Raid sondern nur das
>eine laufwerk. Also brauchst Du auch keine proprietären Treiber und
>entlastest die CPU obendrein...
Naja... die üblichen OnBoard-Lösungen entlasten die CPU eigentlich
nicht, da die Arbeit im Treiber gemacht wird. Außerdem hat man oft
Probleme Treiber für das Betriebssystem seiner Wahl zu finden (so das
denn nicht Windows ist). Und außerdem: was ist besser? Proprietäre
Software oder proprietäre Hardware?
Linux-Software-RAID ist OpenSource. Im Extremfall kann man den Treiber
auf ein anderes OS portieren um wichtige Daten zu retten. Diese
BIOS-Raids oder generell Hardware Controller sind closed source und
ich bin vom Hersteller abhängig wenn was defekt ist.
Gruß
Jan
Jan Heichler
<jan.he...@gmx.net> wrote:
>>> Hauptaufgabe soll die Bereitstellung von Storage sein,
>>> Linux-Software-RAID Level 6 (auf einen propritären Controller
>>> will ich mich nicht einlassen).
>>
>>Warum nimmst Du nicht ein MoBo, auf dem das Raid in hardware (schon im
>>Bios!) gemacht wird. Dann sieht das OS gar kein Raid sondern nur das
>>eine laufwerk. Also brauchst Du auch keine proprietären Treiber und
>>entlastest die CPU obendrein...
>
>Naja... die üblichen OnBoard-Lösungen entlasten die CPU eigentlich
>nicht, da die Arbeit im Treiber gemacht wird. Außerdem hat man oft
>Probleme Treiber für das Betriebssystem seiner Wahl zu finden (so das
>denn nicht Windows ist). Und außerdem: was ist besser? Proprietäre
>Software oder proprietäre Hardware?
Mir fällt da gerade auf: auch deine "Hardware"-Lösung braucht ja den
Herstellertreiber. Also Hardware und Software proprietär.
Gruß
Jan
Martin Bodenstedt
>> Wolfgang Draxinger schrieb:
>>> Hauptaufgabe soll die Bereitstellung von Storage sein,
>>> Linux-Software-RAID Level 6 (auf einen propritären Controller
>>> will ich mich nicht einlassen).
>> Warum nimmst Du nicht ein MoBo, auf dem das Raid in hardware (schon im
>> Bios!) gemacht wird. Dann sieht das OS gar kein Raid sondern nur das
>> eine laufwerk. Also brauchst Du auch keine proprietären Treiber und
>> entlastest die CPU obendrein...
> Naja... die üblichen OnBoard-Lösungen entlasten die CPU eigentlich
> nicht, da die Arbeit im Treiber gemacht wird.
Flashc:
Hast Du einen Raidcontroller auf dem mainboard (im Chipsatz integriert),
so brauchst Du gar keinen Raidtreiber dafür und die CPU hat mit Raid
rein gar nichts zu tun. In diesem Fall hängen die (z.B.) S-ATA
Anschlüsse am Raidcontroller und das OS sieht nur das, was die
BIOS-Konfiguration des Raid Controllers weiter reicht.
> Außerdem hat man oft
> Probleme Treiber für das Betriebssystem seiner Wahl zu finden (so das
> denn nicht Windows ist). Und außerdem: was ist besser? Proprietäre
> Software oder proprietäre Hardware?
Du brauchst keine speziellen Treiber, sondern nur Unterstützung für den
entsprechenden Chipsatz. Und diese brauchst Du für jedes Motherboard, da
jedes auf einem bestimmten Chipsatz (North- und Southbridge) beruht.
> Linux-Software-RAID ist OpenSource. Im Extremfall kann man den Treiber
> auf ein anderes OS portieren um wichtige Daten zu retten. Diese
> BIOS-Raids oder generell Hardware Controller sind closed source und
> ich bin vom Hersteller abhängig wenn was defekt ist.
Von einer Raid-Implementierung in Software halte ich persönlich rein gar
nichts.
Martin Bodenstedt
> Mir fällt da gerade auf: auch deine "Hardware"-Lösung braucht ja den
> Herstellertreiber. Also Hardware und Software proprietär.
Ganz gleich welches Motherboard Du verwendest muss der verwendete
Chipsatz von Deiner Linux Distri unterstützt werden.
Jan Heichler
<martin.b...@gmx.de> wrote:
>>> Warum nimmst Du nicht ein MoBo, auf dem das Raid in hardware (schon im
>>> Bios!) gemacht wird. Dann sieht das OS gar kein Raid sondern nur das
>>> eine laufwerk. Also brauchst Du auch keine proprietären Treiber und
>>> entlastest die CPU obendrein...
>
>> Naja... die üblichen OnBoard-Lösungen entlasten die CPU eigentlich
>> nicht, da die Arbeit im Treiber gemacht wird.
>
>Flashc:
>
>Hast Du einen Raidcontroller auf dem mainboard (im Chipsatz integriert),
>so brauchst Du gar keinen Raidtreiber dafür und die CPU hat mit Raid
>rein gar nichts zu tun. In diesem Fall hängen die (z.B.) S-ATA
>Anschlüsse am Raidcontroller und das OS sieht nur das, was die
>BIOS-Konfiguration des Raid Controllers weiter reicht.
Ich gehe mal davon aus das du die üblichen Implementierungen von intel
und Nvidia auf 1-Sockel Boards meinst: da hast du einfach nicht recht.
Es sitzt keine XOR-Engine auf dem Board die die Paritätsberechnung für
RAID5 oder 6 macht. Das erledigt der Treiber mittels der CPU im
Rechner.
Und du brauchst natürlich genauso einen Treiber wie für jeden anderen
Controller. Nur weil auf BIOS-Ebene bereits die Möglichkeit besteht
auf das Array zuzugreifen heisst das nicht das das auch unter jedem
Betriebssystem so funktioniert.
Versuch mal ein SuSE 8 auf einem aktuellen Areca oder 3ware Controller
zu installieren... du wirst deine Freude haben. Und _das_ sind echte
Hardware-Controller.
>
>> Außerdem hat man oft
>> Probleme Treiber für das Betriebssystem seiner Wahl zu finden (so das
>> denn nicht Windows ist). Und außerdem: was ist besser? Proprietäre
>> Software oder proprietäre Hardware?
>
>Du brauchst keine speziellen Treiber, sondern nur Unterstützung für den
>entsprechenden Chipsatz. Und diese brauchst Du für jedes Motherboard, da
>jedes auf einem bestimmten Chipsatz (North- und Southbridge) beruht.
Sorry, aber das ist Quark. Natürlich brauchst du einen Treiber.
>
>> Linux-Software-RAID ist OpenSource. Im Extremfall kann man den Treiber
>> auf ein anderes OS portieren um wichtige Daten zu retten. Diese
>> BIOS-Raids oder generell Hardware Controller sind closed source und
>> ich bin vom Hersteller abhängig wenn was defekt ist.
>
>Von einer Raid-Implementierung in Software halte ich persönlich rein gar
>nichts.
Ich bevorzuge auch Hardware-Raids, aber deine Argumente sind es nicht
die mich dazu bringen.
Gruß
Jan
Jan Heichler
<martin.b...@gmx.de> wrote:
>> Mir fällt da gerade auf: auch deine "Hardware"-Lösung braucht ja den
>> Herstellertreiber. Also Hardware und Software proprietär.
>
>Ganz gleich welches Motherboard Du verwendest muss der verwendete
>Chipsatz von Deiner Linux Distri unterstützt werden.
Aber du kannst dir Hardware suchen die unterstützt wird und die
Platten daran anschliessen und deine Daten sind da.
Im Hardware-Fall brauchst du den Controller oder das Mainboard um
deine Daten zuzgreifen. Und das dafür kein Treiber nötig wäre ist
schlicht und ergreifend nicht richtig.
Gruß
Jan
Martin Bodenstedt
>> Hast Du einen Raidcontroller auf dem mainboard (im Chipsatz integriert),
>> so brauchst Du gar keinen Raidtreiber dafür und die CPU hat mit Raid
>> rein gar nichts zu tun. In diesem Fall hängen die (z.B.) S-ATA
>> Anschlüsse am Raidcontroller und das OS sieht nur das, was die
>> BIOS-Konfiguration des Raid Controllers weiter reicht.
> Ich gehe mal davon aus das du die üblichen Implementierungen von intel
> und Nvidia auf 1-Sockel Boards meinst: da hast du einfach nicht recht.
> Es sitzt keine XOR-Engine auf dem Board die die Paritätsberechnung für
> RAID5 oder 6 macht. Das erledigt der Treiber mittels der CPU im
> Rechner.
Wieso wird dann die Raid - Konfiguration mit einem Nvidia 760SLI
Chipsatz im Bios (also vor Installation des OS) einschließlich
Initialisierung und Formatierung vorgenommen (Mobo: Asus Striker Extreme
mit NVidia760SLI Chipsatz und Intel CPU)?
Schon bei der Installation von Vista auf einem MoBo mit diesem Chipsatz
hat die Installation nur eine Platte angeboten (mit der zu erwartenden
Größe von zwei TB bei einem Raid-5 System mit fünf Platten à 500GB).
Daraus schließe ich, dass das Raid sehr wohl in Hardware gemacht wird...
Aber ich lasse mich gerne eines Besseren belehren...
> Und du brauchst natürlich genauso einen Treiber wie für jeden anderen
> Controller. Nur weil auf BIOS-Ebene bereits die Möglichkeit besteht
> auf das Array zuzugreifen heisst das nicht das das auch unter jedem
> Betriebssystem so funktioniert.
OK. Aber noch bin ich nicht überzeugt davon, dass dieser Treiber auch
die Paritätsberechnungen macht.
Martin Bodenstedt
> Wieso wird dann die Raid - Konfiguration mit einem Nvidia 760SLI
> Chipsatz im Bios (also vor Installation des OS) einschließlich
> Initialisierung und Formatierung vorgenommen (Mobo: Asus Striker Extreme
> mit NVidia760SLI Chipsatz und Intel CPU)?
Kleiner Nachtrag dazu:
ich rede hier von der Nvidia nForce 680i-SLI Southbridge und das Asus
Handbuch sagt dazu:
Die Nvidia nForce 680i-SLI Southbridge verfügt über einen
Hochleistungs-SATA RAID Controller, der RAID 0, 1, 0+1, 5 und JBOD für
sechs unabhängige Kanäle unterstützt.
Jan Heichler
<martin.b...@gmx.de> wrote:
>Schon bei der Installation von Vista auf einem MoBo mit diesem Chipsatz
>hat die Installation nur eine Platte angeboten (mit der zu erwartenden
>Größe von zwei TB bei einem Raid-5 System mit fünf Platten à 500GB).
>
>Daraus schließe ich, dass das Raid sehr wohl in Hardware gemacht wird...
>
>Aber ich lasse mich gerne eines Besseren belehren...
Was akzeptierst du denn als Beweis? Es gibt diverse Diskussionen in
Foren und Benchmarks im Netz die z.B. die Last auf der CPU bei
RAID5-Betrieb messen. Die ist signifikant. Bei Hardware-RAID ist sie
nicht vorhanden.
>> Und du brauchst natürlich genauso einen Treiber wie für jeden anderen
>> Controller. Nur weil auf BIOS-Ebene bereits die Möglichkeit besteht
>> auf das Array zuzugreifen heisst das nicht das das auch unter jedem
>> Betriebssystem so funktioniert.
>
>OK. Aber noch bin ich nicht überzeugt davon, dass dieser Treiber auch
>die Paritätsberechnungen macht.
Sag mir was ich tun kann um das zu ändern? ;-)
Als Denkanstoß: wenn ein Intel-Mainboard mit 8 SATA-Schnittstellen
tolles RAID5 kann, warum verkaufen dann 3ware und Areca Controller di
a) schneller sind
b) dreimal so viel kosten wie ein solches Board?
Ich weiss...schwaches Argument... aber der Markt regelt solche Sachen
normalerweise. Und in Servern findest du von Intel keine solchen
Lösungen im Chipsatz. Es wird seine Gründe haben...
Gruß
Jan
Martin Bodenstedt
> Als Denkanstoß: wenn ein Intel-Mainboard mit 8 SATA-Schnittstellen
> tolles RAID5 kann, warum verkaufen dann 3ware und Areca Controller di
>
> a) schneller sind
> b) dreimal so viel kosten wie ein solches Board?
Eben weil sie - schneller - sind? ;-)
>
> Ich weiss...schwaches Argument... aber der Markt regelt solche Sachen
> normalerweise. Und in Servern findest du von Intel keine solchen
> Lösungen im Chipsatz. Es wird seine Gründe haben...
Natürlich hat das Gründe. Dass im Serverbereich andere hardware
eingesetzt wird, ist eigentlich logisch. Da geht es dann um Cachegröße,
Batteriepuffer, Performance, Hot swap, Rebuildzeiten und anderes.
Mein Frage war eigentlich - in Bezug auf das originalposting -, was
genau diese integrierten Raid Controller für den SoHo-Betrieb im
Gegensatz zu einer reinen Softwarelösung eigentlich tun...
Meine Antwort auf diese Frage war bisher, dass sie die je nach Raid Typ
notwendigen Paritätsberechnungen machen und die Schreib- bzw.
Leseanforderungen auf die entsprechenden physikalischen Platten
verteilen und das dann eben nicht die CPU machen lassen.
Gerrit Heitsch
> Jan Heichler schrieb:
>> Linux-Software-RAID ist OpenSource. Im Extremfall kann man den Treiber
>> auf ein anderes OS portieren um wichtige Daten zu retten. Diese
>> BIOS-Raids oder generell Hardware Controller sind closed source und
>> ich bin vom Hersteller abh�ngig wenn was defekt ist.
>
> Von einer Raid-Implementierung in Software halte ich pers�nlich rein gar
> nichts.
Das aendert sich schnell. Spaetestens dann wenn dir das Board stirbt, es
nicht mehr zu bekommen ist und du trotzdem gerne noch an deine Daten
ranwillst.
Bei den heutigen CPUs ist Software-RAID einfach die bessere Loesung.
Gerrit
Jan Heichler
<ger...@laosinh.s.bawue.de> wrote:
>> Von einer Raid-Implementierung in Software halte ich pers�nlich rein gar
>> nichts.
>
>Das aendert sich schnell. Spaetestens dann wenn dir das Board stirbt, es
>nicht mehr zu bekommen ist und du trotzdem gerne noch an deine Daten
>ranwillst.
>
>Bei den heutigen CPUs ist Software-RAID einfach die bessere Loesung.
Die CPUs sind sicher nicht mehr das Problem. Allerdings muss auch die
Bandbreite f�r die Daten�bertragung auf PCI oder PCIe zur Verf�gung
stehen. Immerhin verursachen RAID1, RAID5, RAID6 und entsprechende
Mischlevel eine deutlich h�here Buslast als ein einfaches RAID0 wenn
sie in Software ausgef�hrt sind.
Gru�
Jan
Gerrit Heitsch
Kannst du bei heutigen Bussystemen auch vergessen. Vor allem kannst du
ein Soft-RAID ueber mehr als einen Controller aufmachen und damit die
moegliche Bandbreite verdoppeln.
Selbst 2-Sockel 2HE-Server haben multiple PCIe 4x/8x
BTW: Bevor man RAID-5/6 benutzt sollte man genau wissen was man tut. Wer
da nicht aufpasst kann im Endeffekt beim Schreiben weniger Performance
bekommen als wenn er gleich bei RAID-1 geblieben waere. Bei den
aktuellen Groessen und Preisen fuer HDs gibt es wenige Gruende RAID-5 zu
benutzen.
Gerrit
Jan Heichler
<ger...@laosinh.s.bawue.de> wrote:
>>>> Von einer Raid-Implementierung in Software halte ich pers�nlich rein gar
>>>> nichts.
>>> Das aendert sich schnell. Spaetestens dann wenn dir das Board stirbt, es
>>> nicht mehr zu bekommen ist und du trotzdem gerne noch an deine Daten
>>> ranwillst.
>>>
>>> Bei den heutigen CPUs ist Software-RAID einfach die bessere Loesung.
>>
>> Die CPUs sind sicher nicht mehr das Problem. Allerdings muss auch die
>> Bandbreite f�r die Daten�bertragung auf PCI oder PCIe zur Verf�gung
>> stehen. Immerhin verursachen RAID1, RAID5, RAID6 und entsprechende
>> Mischlevel eine deutlich h�here Buslast als ein einfaches RAID0 wenn
>> sie in Software ausgef�hrt sind.
>
>Kannst du bei heutigen Bussystemen auch vergessen. Vor allem kannst du
>ein Soft-RAID ueber mehr als einen Controller aufmachen und damit die
>moegliche Bandbreite verdoppeln.
>
>Selbst 2-Sockel 2HE-Server haben multiple PCIe 4x/8x
Ich dachte wir sind noch im Desktop-Bereich. �
Im professionellen Bereich sehe ich Software-RAID aber sehr selten.
SUN hat mal Software RAID gemacht - weiss nicht ob das heute immernoch
so ist. Ein guter Hardware-Controller kostet mit 16 oder 24 Ports zwar
einiges an Geld, doch wenn ich diese Zahl an Platten in einen Rechner
packen m�chte muss ich Controller finden die ohne RAID-Funktion so
viele Ports bieten - eher schwer.
Au�erdem rennst du bei vielen (>8) Platten im Software RAID in ein
weiteres Problem: Interrupts. Das kann die Performance sehr deutlich
schm�lern - vor allem wenn die Daten noch auf ein Netzwerkinterface
m�ssen.
>BTW: Bevor man RAID-5/6 benutzt sollte man genau wissen was man tut. Wer
>da nicht aufpasst kann im Endeffekt beim Schreiben weniger Performance
>bekommen als wenn er gleich bei RAID-1 geblieben waere. Bei den
>aktuellen Groessen und Preisen fuer HDs gibt es wenige Gruende RAID-5 zu
>benutzen.
Stimm ich dir nicht zu. Klar. Write-Penalty ist ein Thema. Allerdings
scheinen aktuelle Controller sehr geschickt zu cachen und erreichen
hohe IO-Raten auch bei RAID5.
Dell MD3000 z.B.: externes Storage-System. Erreicht bei RAID5 eine
gr��ere Zahl an IOs als bei RAID10. Und da sind keine �ppigen Caches
verbaut - und auch keine ultraschnellen Controller.
8 Platten mit je 500 GB im RAID 5. geben eben 3,5 TB Platz. Im RAID10
nur 2 TB. Das ist ein Unterschied und der z�hlt.
Im Privatbereich hast du aber vermutlich recht. Lieber 2 x 1TB im
RAID1 als 3 x 500 GB im RAID5.
Gru�
Jan
> Gerrit
Joseph Terner
> Mein Frage war eigentlich - in Bezug auf das originalposting -, was
> Gegensatz zu einer reinen Softwarel�sung eigentlich tun...
Sie haben ein BIOS (das �brigens auf der Host-CPU ausgef�hrt wird),
welches spezielle Metadaten auf die Platten schreibt und �ber das
INT13h-Interface ein zusammenh�ngendes Laufwerk simuliert, damit davon
gebootet werden kann.
Der mit dem Controller mitgelieferte Treiber sucht zuerst nach dem
Controller, dann auf den einzelnen Platten nach den Metadaten und stellt
anschlie�end ebenfalls softwareseitig dem Betriebssystem ein
zusammenh�ngendes Laufwerk dar.
In der FreeBSD-Dokumentation ist das recht sch�n erkl�rt:
<http://www.freebsd.org/cgi/man.cgi?query=ataraid>
Der FreeBSD-Treiber weist allerdings den Vorteil auf, da� das RAID auch
ohne den zugeh�rigen Controller noch funktioniert, mangels BIOS kann
nat�rlich nicht mehr davon gebootet werden.
Die Windowstreiber verweigern ohne das zugeh�rige Hardware-Dongle
�blicherweise die Arbeit.
> Meine Antwort auf diese Frage war bisher, dass sie die je nach Raid Typ
> notwendigen Parit�tsberechnungen machen und die Schreib- bzw.
> Leseanforderungen auf die entsprechenden physikalischen Platten
> verteilen und das dann eben nicht die CPU machen lassen.
Dann k�nnten diese Controller das Array per AHCI darstellen und
br�uchten bei aktuellen Betriebssystemen �berhaupt keine speziellen
Treiber.
Nur dazu br�uchte der Controller erst einmal Eigenintelligenz (n�mlich
eine eigene CPU) und das kostet halt etwas mehr.
ciao, Joseph
Martin Bodenstedt
> Im Privatbereich hast du aber vermutlich recht. Lieber 2 x 1TB im
> RAID1 als 3 x 500 GB im RAID5.
Es kommt darauf an, was Du erreichen willst. Brauchst Du die (Schreib-)
Performance, ist Raid5 die falsche L�sung. Suchst Du aber Plattenplatz
f�r die Langzeitarchivierung, so bist Du mit Raid5 gut bedient - zumal
Du netto nur eine Platte verlierst.
Martin Bodenstedt
> Martin Bodenstedt wrote:
>> Mein Frage war eigentlich - in Bezug auf das originalposting -, was
>> genau diese integrierten Raid Controller f�r den SoHo-Betrieb im
>> Gegensatz zu einer reinen Softwarel�sung eigentlich tun...
> Sie haben ein BIOS (das �brigens auf der Host-CPU ausgef�hrt wird),
> welches spezielle Metadaten auf die Platten schreibt und �ber das
> INT13h-Interface ein zusammenh�ngendes Laufwerk simuliert, damit davon
> gebootet werden kann.
Aber damit ist es doch f�r das OS transparent oder nicht?
> Der mit dem Controller mitgelieferte Treiber sucht zuerst nach dem
> Controller, dann auf den einzelnen Platten nach den Metadaten und stellt
> anschlie�end ebenfalls softwareseitig dem Betriebssystem ein
> zusammenh�ngendes Laufwerk dar.
>
> In der FreeBSD-Dokumentation ist das recht sch�n erkl�rt:
>
> <http://www.freebsd.org/cgi/man.cgi?query=ataraid>
>
> Der FreeBSD-Treiber weist allerdings den Vorteil auf, da� das RAID auch
> ohne den zugeh�rigen Controller noch funktioniert, mangels BIOS kann
> nat�rlich nicht mehr davon gebootet werden.
>
> Die Windowstreiber verweigern ohne das zugeh�rige Hardware-Dongle
> �blicherweise die Arbeit.
>
>> Meine Antwort auf diese Frage war bisher, dass sie die je nach Raid Typ
>> notwendigen Parit�tsberechnungen machen und die Schreib- bzw.
>> Leseanforderungen auf die entsprechenden physikalischen Platten
>> verteilen und das dann eben nicht die CPU machen lassen.
>
> Dann k�nnten diese Controller das Array per AHCI darstellen und
> br�uchten bei aktuellen Betriebssystemen �berhaupt keine speziellen
> Treiber.
>
> Nur dazu br�uchte der Controller erst einmal Eigenintelligenz (n�mlich
> eine eigene CPU) und das kostet halt etwas mehr.
Danke. Wieder etwas gelernt... :-)
Jan Heichler
<martin.b...@gmx.de> wrote:
>Jan Heichler schrieb:
>
>> Im Privatbereich hast du aber vermutlich recht. Lieber 2 x 1TB im
>> RAID1 als 3 x 500 GB im RAID5.
>
>Es kommt darauf an, was Du erreichen willst. Brauchst Du die (Schreib-)
>Performance, ist Raid5 die falsche L�sung. Suchst Du aber Plattenplatz
>f�r die Langzeitarchivierung, so bist Du mit Raid5 gut bedient - zumal
>Du netto nur eine Platte verlierst.
Das "nur eine Platte" Argument sticht vor allem wenn du viele Platten
hast. Der Prozentuale Verlust von RAID5 wird immer geringer.
Ob du 4 Platten RAID10 oder 3 Platten RAID5 f�hrst ist nicht ganz so
entscheidend wie 8 Platten RAID5 oder 14 Platten RAID10.
Vor allem weil man f�r gro�e Setups eh entsprechende Controller etc.
kauft. F�r 4 Platten RAID10 reicht ein billiger HostRaid-Adapter
�blicherweise aus.
Gru�
Jan
Martin Bodenstedt
>> Es kommt darauf an, was Du erreichen willst. Brauchst Du die (Schreib-)
>> Performance, ist Raid5 die falsche L�sung. Suchst Du aber Plattenplatz
>> f�r die Langzeitarchivierung, so bist Du mit Raid5 gut bedient - zumal
>> Du netto nur eine Platte verlierst.
> Das "nur eine Platte" Argument sticht vor allem wenn du viele Platten
> hast. Der Prozentuale Verlust von RAID5 wird immer geringer.
>
> Ob du 4 Platten RAID10 oder 3 Platten RAID5 f�hrst ist nicht ganz so
> entscheidend wie 8 Platten RAID5 oder 14 Platten RAID10.
Du musst nur aufpassen, dass die Gr��e des resultierenden Raid Sets die
F�higkeiten Deines Betriebssystems nicht �berschreitet. Das tollste
Raid-5 System mit einer Nettokapazit�t von 100TB n�tzt Dir wenig, wenn
Dein OS ein Limit von 10TB hat...
Meine Devise im gro�en Umfeld ist es, m�glichst viele Spindeln, aber
nicht unbedingt die gr��ten Platten zu verwenden - ein guter Controller
vorausgesetzt, nat�rlich.
> Vor allem weil man f�r gro�e Setups eh entsprechende Controller etc.
> kauft. F�r 4 Platten RAID10 reicht ein billiger HostRaid-Adapter
> �blicherweise aus.
Im Serverumfeld setzen wir die PowerVaults von Dell ein...
Joseph Terner
> Joseph Terner schrieb:
>> Martin Bodenstedt wrote:
>>> Mein Frage war eigentlich - in Bezug auf das originalposting -, was
>>> genau diese integrierten Raid Controller f�r den SoHo-Betrieb im
>>> Gegensatz zu einer reinen Softwarel�sung eigentlich tun...
>
>> Sie haben ein BIOS (das �brigens auf der Host-CPU ausgef�hrt wird),
>> welches spezielle Metadaten auf die Platten schreibt und �ber das
>> INT13h-Interface ein zusammenh�ngendes Laufwerk simuliert, damit davon
>> gebootet werden kann.
>
> Aber damit ist es doch f�r das OS transparent oder nicht?
Nein, erstmal wird der RAID-Treiber Bestandteil des OS. Transparent ist
es nur f�r den Benutzer, aber nicht f�r das OS selbst. Das OS mu�
jederzeit wissen, da� Laufwerk X ein Array ist und mit dem RAID-Treiber
behandelt werden mu�. Der RAID-Treiber selbst nutzt das Lowlevel-API, um
auf die einzelnen Platten zuzugreifen.
ciao, Joseph
Martin Bodenstedt
> Nein, erstmal wird der RAID-Treiber Bestandteil des OS. Transparent ist
> es nur f�r den Benutzer, aber nicht f�r das OS selbst. Das OS mu�
> jederzeit wissen, da� Laufwerk X ein Array ist und mit dem RAID-Treiber
> behandelt werden mu�. Der RAID-Treiber selbst nutzt das Lowlevel-API, um
> auf die einzelnen Platten zuzugreifen.
Danke... :-)
Wolfgang Draxinger
> Wolfgang Draxinger schrieb:
>
>> Hauptaufgabe soll die Bereitstellung von Storage sein,
>> Linux-Software-RAID Level 6 (auf einen propritären Controller
>> will ich mich nicht einlassen).
>
> Warum nimmst Du nicht ein MoBo, auf dem das Raid in hardware
> (schon im Bios!) gemacht wird.
Weil das auch nichts anderes ist als ein Software RAID, nur das
das BIOS-RAID-Zeug propritär ist und gegen die Funktionalität
von ZFS (und demnächst BtrFS) anstinken kann.
> Dann sieht das OS gar kein RAID sondern nur das eine laufwerk.
Falsch. Dem wäre nur dann so, wenn es sich um ein echtes
Hardware-RAID handelte. Diese BIOS-RAID-Geraffel erfordert
spezielle Treiber für's OS, damit das die RAID-Tabellen aus dem
BIOS auslesen und sein Software-RAID entsprechend Konfigurieren
kann. Murks an 3 Stellen ist das.
> Also brauchst Du auch keine proprietären Treiber und entlastest
> die CPU obendrein...
Es geht nicht um propritäre Treiber, sondern um propritäre
RAID-Implementationen. Jedwedes propritäre RAID-System legt
einen auf genau die Kombination aus Hard- und Software fest mit
der man das RAID aufgesetzt hat.
Ein Wechsel des Controllers: Vergiss es.
Ein Wechsel der Software: Vergiss es.