Re: Welches Software-Raid unter freebsd auf SATA-Platten

On Sun, Feb 22, 2004 at 12:26:26AM +0100, Andreas Braukmann wrote:
> On 02/21/04 20:21:54 +0100 Bernd Walter wrote:
> > Der Schreibcache macht die Syncronität zu einer Spekulation.
>
> Und bei SCSI-Platten laesst Du den Schreibcache an, wenn
> Du ein vinum RAID darauf hast?

Bei SCSI geht dank TCQ die Performance beim schreiben nicht den
Bach runter wenn man den Schreibcache abschaltet.
Davon, dass der Cache bei SCSI Platten kontrollierbar ist mal
abgesehen.

> Ja, ich weiss, dass IDE-Platten einen ueber den Zustand
> des Caches beluegen. Solche Platten muss man aber selbst-
> verstaendlich nicht verwenden und genauso selbstverstaend-
> lich sagt dem 3Ware-Controller, er moege die Schreibcaches
> der Platte deaktivieren. Da die 3Wares keinen nenneswert
> grossen eigenen Cache haben, kann man recht gut testen,
> ob die Caches der Platten wirklich aus sind. (Ob eine IDE-
> Platte den Befehl zum Ausschalten befolgt, kann man ja auch
> ohne 3Ware in der Geraetekette untersuchen.)

Also lebst du damit dass das schreiben lahm ist.

> > Qutasch - der Schreibcache provoziert Inkosistenzen.
> > So ein kurzen Plattenausfall löscht den Schreibcache und kann beim
> > Controller unentdeckt bleiben.
>
> siehe oben.
> Nur, weil "IDE" im Spiel ist, solltest Du nicht automatisch
> darauf schliessen, dass saemtliche Sorgfalt bei der Hardware-
> auswahl fehlte.

Wenn du damit leben kannst, dass die Schreibperformance einfach weit
unter dem Potential der Platte liegt, dann ist das natürlich an der
Stelle OK.

> >> SCSI-Bussen immer wieder mal beobachten kann; wenn eine Platte den
> >> Betrieb des Busses massgeblich stoeren kann, hilft es auch nicht
> >> mehr, dass die anderen Platten am selben Bus noch ok sind. :-/)
> >
> > Ja - aber auch bei SCSI kann man die Platten an unterschiedlichen
> > Kanälen hängen.
>
> Hmmm. Fuer 5 Spindeln RAID-5 mit Hot-Standby also 6 Kanaele?
> Das halte ich fuer "wenige hundert GByte Setups" aber schon
> fuer uebertrieben. ;)

Dafür muss ich die Platten nicht wegen kruzer Kabel am Controller
kleben, was die Lüftung deutlich vereinfacht.
Außerdem kann man das nächste 5'er ja wieder problemlos an die gleichen
6 Kanäle hängen.
Natürlich hänge ich die Platten auch an die gleichen Kanäle, aber
das Risiko ist ja auch deutlich niedriger dass der Kanal durch eine
defekte Platte gestört wird.

> >> Der RAID-Controller (egal ob eigenstaendige Hardware oder ein Stueck
> >> Software auf dem Host) muss dann alle betroffenen Platten als "tot"
> >> annehmen. ==> Backup einspielen.
> >
> > Falsch - mit einer ordendlichen Zustandsdatenbank hat man Kenntniss
> > darüber wann welche Platte ausgefallen ist und kann die wieder
> > hochfahren.
>
> Kann man. Die Frage ist nur, ob man der Platte (bzw. derem
> Inhalt) noch vertrauen darf. Man muss schon sehr genau unter-

Deine Argumentation begann mit einem gestörten Kanal.
Warum sollte man dann der Platte nicht mehr trauen?

> suchen, welche Operationen auf den einzelnen Platten tatsaech-
> lich noch korrekt ausgefuehrt wurden. Damit man das *immer*
> kann, muesste man (IMHO) ein Log aller (schreibenden) Trans-
> aktionen in einem gepuffertem RAM haben. Das hat man bei Vinum
> aber z.B. auf keinen Fall.

Leider nein, da Vinum kein NVRAM hat und mehrstufiges Schreiben nicht
implementiert ist - wäre auch arg Langsamm.
Aber in dem Fall fährst du das System ja auch von Hand hoch und kannst
die Syncronität selber wieder herstellen lassen.

> > Mit Vinum jedenfalls - ein Hardwarecontroller mag da beleidigt sein.
> > Ich habe solche Fälle bereits gehabt, wenn Knaller den Stromstecker
> > der Plattenstation ziehen...
>
> toetlich. ja. :-/
> Man kann dann - auch bei RAID-Controllern - die Platten auch
> mit "Gewalt" wieder in den aktiven Zustand versetzen, aber
> das erste was dann zwingend ansteht ist ein vollstaendiger
> Synchronizitaetscheck.

Sicher.

> > Die Dinger versprechen immer heile Welt und verdecken Frühwarnungen.
>
> Die Dinger reichen eigentlich jede Auffaelligkeit an die Treiber
> durch; was fehlt Dir da? Das einzige Argument was ziehen wuerde,
> waere der "closed source"-Aspekt; man kann halt nicht selbst
> sicher ueberpruefen, ob nicht doch nur jeder zweite Leser-/Schreib-
> fehler gemeldet wird ...

Wenn die wirklich alles durchreichen würden wäre ich zufrieden.
Aber selbt wenn dann so ist, dann steht das noch lange nicht auf der
Verpackung und ist damit unkalkulierbar.

> > Einziger Vorteil ist NVRAM - man müsste sowas mal als generischen
> > Speicher in FreeBSD bringen.
>
> (PrestoServe anybody? ;-))
>
> Das waere nett. Das ist naemlich mit der Hauptgrund, weshalb
> ich noch PCI-RAID-Controller bevorzuge; ohne NVRAM halte ich
> sie auch fuer eher witzlos. Aktuelle SMP-Systeme bieten meist
> bessere XOR-Performance als die Chips der RAID-Controller.
> Bei Servern, die keine Zyklen zu verschenken haben, zieht der
> "off-loading"-Aspekt dann wieder.

XOR Offload hat einen anderen Grund.
Die Daten müssen gar nicht erst in den PC und sparen Memory Bandwidth.
Deshalb sind bei SCSI Platten XOR Operationen definiert - auch ohne
Controller.
Du kannst z.B. direkt XOR Daten zur Platte schreiben, während du
ansonsten den Block erst lesen, dann modifizeren und letzlich wieder
zurückschreiben müsstest.
Auch definiert ist Daten direkt zwischen Platten auszutauschen.
Z.B. kannst du die Parität vom Platte A zu Platte B schicken und von
Platte B dann das fertige XOR lesen.
Aber leider habe ich das noch nie Implementiert gesehen :(
Immerhin könnte man sowas aber vom OS steuern lassen wenn man die
Parity-Engine der RAID Controller nutzen könnte.

> Ein Adaptec 2200S liefert bei einem 4-Spindel-RAID-5 einen
> sequentiellen Schreibdurchsatz zwischen 42 und 45 MByte
> pro Sekunde. Das ist bei Fujitsu 10 kUPM Platten weniger
> als eine einzelne Platte abliefert. Ich bin mir ziemlich sicher,
> dass das Schreiben auf ein vinum RAID-5 schneller funktionieren
> kann. Es ist ja schon einigermassen widersinnig, dass beim Be-
> trieb eines caching-RAID-5-Controllers alle Block-Operationen
> zwei Mal serialisiert werden muessen.

Vinum serialisiert bei R5 schreiben leider auch, solange die
Transaktionen in dem gleichen Stripeset liegen.
 
> > Ich würde mich mehr freuen, wenn die Controller kein RAID machen
> > würden, sondern einfach nur PArityops anbieten würden.
>
> Das waere nett. Und ein dickes NVRam. Denn genau dann wuerde
> ich eine optimal ins Betriebssystem eingebettete RAID-Software
> (deren Plattenlayout offen dokumentiert ist) auf jeden Fall
> bevorzugen.
>
> > Dann hat man die Chance immer noch ein SoftwareRAID mit Hardwaresupport
> > zu machen.
>
> Dieses "Software"- vs. "Hardware"-RAID ist eh' Augenwischerei;
> letzendlich ist "Hardware"-RAID in weiten Teilen (von Parity-Co-
> prozessoren mal abgesehen) auch nur ein "closed-source" Software-
> RAID, welches nicht auf der CPU des Host-Systems laeuft. Und na-
> tuerlich gibt es auch in diesen "closed source"-Software-Paketen
> immer wieder mal Fehler.

Natürlich, aber die Controller machen auch Dinge, die diese besser
nicht machen sollten, wie z.B. das Volumemanagement.
Stelle dir aleine mal den Fall vor ein R5 von einem Hardwarecontroller
auf einen anderen zu übertragen...

-- 
B.Walter                   BWCT                http://www.bwct.de
ticso(at)bwct.de                                  info(at)bwct.de
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message