On 02/21/04 20:21:54 +0100 Bernd Walter wrote:
> Von Vinum habe ich den Source - das was ein TWE macht kann ich
> nicht im geringsten Beurteilen.
Das Argument zieht natuerlich.
> Die Tatsache dass du noch keine Probleme gehabt hast bedeutet ja
> nicht zwangsläufig, dass die sauber gearbeitet haben.
> Man kann auch nicht oft genug erwähnen, dass man mit IDE eigendlich
> auch nicht sauher arbeiten kann.
"eigentlich". So rein verallgemeinernd betrachtend gibt es
auch immer wieder SCSI-Geraete deren Produzenten noch nie
die notwendigen Dokumente gelesen zu haben scheinen.
> 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?
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.)
>
> 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.
>> 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. ;)
>> 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-
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.
> 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.
>> Das kommt zugegebenerweise selten vor, aber ich habe es nicht erst
>> einmal erlebt. (Interessanterweise immer mit Mylex-Controllern ...)
>
> Ich persönlich halte nichts von Hardwareraid.
Ich merks immer wieder ;-)
> 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 ...
> 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.
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.
> 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.
-Andreas
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Sun 22 Feb 2004 - 00:36:35 CET