Raid Controller unter FreeBSD

[.mp]

FreeBSD sendet praktisch die Daten einfach an das Device (ar0) und der Controller spiegelt die dann auf die Platten (ad0 und ad1) bei einem raid1

Meines wissens spiegelt bei Promise eben der Treiber ata(4) die Daten auf die Platten, nicht der Controller.

 

[marzl]

falsch. das ata-interface biete lediglich einen normalen zugriff auf die devices (damit nicht der umweg über das bios gegangen werden muss). hier ar0. die funktion bietet der controller. der spiegelt. ohne treiber, betriebssystem is dem egal. so zumindest meine erfahrung mit den teilen. ich hab hier einige von denen am laufen. bei silicon hab ich ebenfalls schlechte erfahrung gemacht, das ist dreck, aber highpoint und promise sind ok.

zitait aus atacpontrol(8):

Although the ATA driver allows for creating an ATA RAID on disks
with any controller, there are restrictions. It is only possi-
ble to boot on an array if it is either located on a ``real''
ATA RAID controller like the Promise or Highpoint controllers.

 

[rMarkus]

falsch. das ata-interface biete lediglich einen normalen zugriff auf die devices (damit nicht der umweg u:ber das bios gegangen werden muss). hier ar0. die funktion bietet der controller. der spiegelt. ohne treiber, betriebssystem is dem egal. so zumindest meine erfahrung mit den teilen. ich hab hier einige von denen am laufen. bei silicon hab ich ebenfalls schlechte erfahrung gemacht, das ist dreck, aber highpoint und promise sind ok.

zitait aus atacpontrol(8):

Weil diese Kontroller ein RAID-BIOS haben und damit das System dann von einem RAID-Array booten koennen.
Im Betrieb kuemmert sich der Treiber dann darum.

Soweit ich das damals gelesen habe, macht die Hardware bei den besseren preiswerten Controllern tatsaechlich einen kleinen Teil der Raid-Funktionaliaet.
Dies wird sich aber darauf beschraenken, dass die Transportierten Daten nur einmal zum Controller uebertragen werden muessen, die Host-CPU muss aber wahrscheinlich das Mapping selbst rechnen, was bei LBA und gleichen Platten nahezu entfaellt.
Problematisch bleibt dann aber, dass IDE synchrone Operationen vorraussetzt und die Platten quasi als EISA-Device direkt ins RAM schreiben. Eine Abstraktionsebene wie bei teureren Controllern bringt Sicherheit und parallele IO-Performance.

Ich hatte mal damals einen Adaptec 1542 Clone (ISA, SCSI2), der konnte auch zusaetzlich noch Raid Spiegeln. Die haben einfach die Firmware des Z80 oder 80086 darauf erweitert.
Das Spiegeln an sich ist ziemlich einfach, die Fehlerfaelle und vernuenftiges IO-Model sind das Problem.

 

[rMarkus]

Dies wird sich aber darauf beschraenken, dass die Transportierten Daten nur einmal zum Controller uebertragen werden muessen

Darüber habe ich gerade mal nachdecht und bin nun der Meinung, dass das der Conroller nicht kann.

Der Hintergrund ist, dass der Datenendpunkt bei IDE die Festplatte ist, der IDE-Controller ist nur eine bessere PCIzuEIDE-Bridge.
Im Busmaster-Betrieb (MWDMA, UDMAxxx) holt die Festplatte sich die Daten selbst aus dem RAM des Hosts bzw. legt sie da rein.
Da die einfachen RAID-Controller wie Promise oder Highpoint kein eigenes RAM haben (abgesehen von etwas transparentem Cache), müssen im Spiegelbetrieb schreibend beide Platten die Daten aus dem RAM holen, da wohl beide Platten nicht synchron laufen und zufaellig immer die gleichen Daten aus dem Cache des Controllers anfordern. Der Cache des Controllers ist dafuer auch gar nicht vorgesehen. Dafür spricht auch, dass immer nur ein IDE-Device aktiv sein kann.

Also die Daten wandern beim schreiben höchstwahrscheinlich immer doppelt über den Host (PCI usw.) und IDE-Bus. Beim Lesen ist das noch fraglicher. Entweder er liest doppelt und der Treiber vergleicht (Host-CPU) dann das Ergebnis oder es wird nur eine Platte gelesen, was einen Sicherheitsvorteil Vorteil von Spiegel-RAID vernichtet.
Wahrscheinlich koennen bessere preiswerte IDE-Controller dann nur die Befehle clonen, was ziemlich minimal ist.