Raid0 mit Write-Back oder ohne

[Knorkator4711]

Hallo zusammen,

bei einer Raid-0 Testkonfiguration auf einem Intel X79 Board ist mir aufgefallen, dass man im Intel RST Manager auch Write-Back einstellen kann.
Auf Raid-5 Systemen ist Write-Back Pflicht, da sich die Schreibleistung extrem verbessert.
Bei Raid-0 habe ich dies noch nie ausprobiert.

Ein Bild mit und ohne Write-Back ist im Anhang.

Der Leistungsgewinn bei Schreibzugriffen mit Write-Back ist nur im Bereich von 512B bis 16Kb messbar.
Die Frage an Euch ist nun.. bei welchen Anwendungsszenarien würde man etwas davon merken?

Genutzt werden soll das Raid0 als Photoshop und Lightroom Cache sowie Ablage für Spiele etc.

Das man bei Aktivierung von Write-Back ohne BBU ich mindestens eine USV haben sollte, und ein Datenverlust trotzdem denkbar ist, ist mir bewusst.

Vielen Dank für Eure Beiträge und Meinungen!

 

[^R4iD]

Bei vielen! kleinen Dateien ist das merkbar.. bei !vielen!..

 

[xexex]

Das man bei Aktivierung von Write-Back ohne BBU ich mindestens eine USV haben sollte, und ein Datenverlust trotzdem denkbar ist, ist mir bewusst.

Eine USV bringt bei dem Problem praktisch gar nichts, außer vielleicht in Ländern in denen der Strom alle paar Stunden zusammenbricht. Problem vom Write-Back Cache?

Stürzt dein Rechner ab, ist der Inhalt von diesem Cache bei so einem Controller weg. Bei einem Cache verschmerzbar, bei einem Spiel vermutlich schon weniger. In der heutigen SSD Zeit praktisch grosser Unsinn, außer die eigenen Daten sind einem ganz egal.

 

[Knorkator4711]

Das mit dem Absturz ist nen gutes Argument.. bei einer BBU im Server ist das was anderes.

Die USV bringt an der Stelle scheinbar wirklich nichts!


Die 2x1TB HDDs bekomme ich für Umsonst, daher der Gedanke wie man am ehesten noch Performance rausholen kann!

Thx!

 

[Holt]

Da ein RAID 0 auch 0 Sicherheit für die Daten bietet, ist es am Ende doch egal ob man den Schreibcache mit oder ohne BBU aktiviert. Von einem USV weiß ein RAID Controller natürlich nichts.

 

[xexex]

Da ein RAID 0 auch 0 Sicherheit für die Daten bietet, ist es am Ende doch egal ob man den Schreibcache mit oder ohne BBU aktiviert.

Bei einem Softwareraid ist das nicht ganz egal. Da geht es dann nicht mehr darum ob ein Datenträger ausfallen kann. Da reicht schon ein dicker Systemabsturz beim Schreiben, um die Struktur zu beschädigen und die Daten zu verlieren.

 

[Masamune2]

Es bringt dir immer dann etwas wenn die zu schreibenden Blöcke kleiner sind als die Stripesize des Raids. Die liegt bei Intel onboard Raids in der Regel bei 64k. Ist Write Back an sammelt der Controller die Daten so lange im Cache bis 64k zusammen sind und schreibt sie dann am Stück. Die erhöhte Geschwindigkeit kommt dann dadurch zu stande das du quasi immer min. 64k am Stück schreibst.

 

[xexex]

Es bringt dir immer dann etwas wenn die zu schreibenden Blöcke kleiner sind als die Stripesize des Raids. Die liegt bei Intel onboard Raids in der Regel bei 64k. Ist Write Back an sammelt der Controller die Daten so lange im Cache bis 64k zusammen sind und schreibt sie dann am Stück. Die erhöhte Geschwindigkeit kommt dann dadurch zu stande das du quasi immer min. 64k am Stück schreibst.

Das macht ein Raid Controller auch mit Write Trough. Der Unterschied besteht darin, wann der Controller ein "Complete" an das System zurücksendet. Bei Write Through geschieht das erst wenn die Daten sich auch auf den Datenträgern befinden, bei Write Back kann man fröhlich in den Cache speichern und das System denkt die Daten wären auch gespeichert, während sich diese aber noch im Puffer befinden. Bei einem Stromausfall oder Systemabsturz sind diese Daten weg.

Ganz gefährlich ist sowas natürlich bei Datenbanken oder bei dem Dateisystem (MFT).
http://www.tecchannel.de/a/ratgeber-raid-controller-optimal-konfigurieren,432631,3

 

[Knorkator4711]

Vorab: Projekt Write-Back ist gestorben..

Aus Neugier habe ich trotzdem mal ein paar File-Copy Tests mit und ohne WB gemacht.

Ein 12GB Ordner mit ca. 6000 Dateien wurde von einer SATA3 SSD mit folgendem Befehl auf den Raid-0 Verbund kopiert.

measure-command {robocopy .\Testordner h:\ /mir /ndl /nfl /fft /mt:10}

Stripe-Size beträgt 128KB -> Defaultwert.

Interessant ist, dass der Kopiervorgang mit Write-Back reproduzierbar langsamer ist als ohne Write-Back.


Mit WB:2:01 sek
Ohne WB:1:50 sek

Zur Verteilung der Dateien:
0KB - 10KB: 1103
10KB - 100KB:1839
101KB - 1MB:2312
1MB - 16MB: 729
16MB - 128MB:43
>128MB: 8

 

[Masamune2]

Das macht ein Raid Controller auch mit Write Trough. Der Unterschied besteht darin, wann der Controller ein "Complete" an das System zurücksendet.

Das macht aber keinen Sinn, dann hätte man bei kleinen Schreibzugriffen mitunter wahnsinnig hohe Latenzen. Wenn ich nur 4k schreiben will und danach nichts mehr kommt kann der Controller ja nicht ewig warten und die Daten nicht auf die Platten zurückschreiben.

 

[xexex]

Das macht aber keinen Sinn, dann hätte man bei kleinen Schreibzugriffen mitunter wahnsinnig hohe Latenzen. Wenn ich nur 4k schreiben will und danach nichts mehr kommt kann der Controller ja nicht ewig warten und die Daten nicht auf die Platten zurückschreiben.

Das funktioniert etwas anders wie du dir vorstellst und einen passenden Link habe ich auch beigefügt.

Ich vereinfache das mal für dich.

Ich bin das OS, du das Raid.

Ich gebe dir ein Paket und bitte dich es zu lagern.

Mit WT
Gehst du ins Lager, stellst es in ein Regal und wenn es zu gross ist auch gerne in 2 oder 3 Regale, dann kommst du zurück und bestätigst mir den Empfang.

Mit WB
Nimmst das Paket stellst es hinter dir und schreibst mir eine Bestätigung. Später stellst du es auch ins Lager, mit etwas Glück kannst du noch ein paar andere Pakete mitnehmen oder jemand holt in der Zwischenzeit sein Paket wieder ab.

In beiden Fällen hat das Paket die gleiche Größe. In beiden Fällen landet es in einem, zwei, 3 oder noch mehr Regalen. Die Unterschiede sind nur:
Das dich im Fall B jemand überfallen kann und das Paket weg ist sind obwohl ich mir sicher bin du es eingelagert hast.
Das du im Fall B das Paket noch zu Füßen hast, wenn ich es doch ganz plötzlich wieder brauche.

Dein Gedankengang ist wie du siehst nicht ganz falsch. Aber die Optimierung geschieht an einer anderen Stelle, sonst würde WB nur einen konstanten Datenstrom beschleunigen und genau dort ist der Gewinn durch WB am geringsten oder wird die Sache sogar verlangsamen. Bei SSDs ist der Zwischenspeicher gar in meisten Fällen ein Hindernis.

Interessant ist, dass der Kopiervorgang mit Write-Back reproduzierbar langsamer ist als ohne Write-Back

Wirklich? Write-Back ist nicht dazu da um Daten am Stück schneller speichern zu können. Write-Back dient, wie ich ein paar Zeilen oben weiter erklärt habe, die Anzahl der IOPS zu reduzieren und Fragmente wie die MFT im Cache vorzuenthalten. Ein Systemstart mit Write-Back ist erheblich schneller, eine Defragmentierung um Welten!

Kopierst du nur Daten am Stück unter Windows, speichert das System die Daten eh in eigenem Cache zwischen und schreibt die in einem konstanten Datenstrom auf die Datenträger.

Mache einen anderen Test! Starte dein System neu, damit keine Daten mehr im Systemcache sind und kopiere diesen Ordner auf den gleichen Datenträger. (D:\Daten auf D:\Datenkopie\) Da wirst du dann sehen welchen Unterschied WB ausmacht.

 

[Knorkator4711]

Das macht aber keinen Sinn, dann hätte man bei kleinen Schreibzugriffen mitunter wahnsinnig hohe Latenzen. Wenn ich nur 4k schreiben will und danach nichts mehr kommt kann der Controller ja nicht ewig warten und die Daten nicht auf die Platten zurückschreiben.

So kann man das nicht sehen glaube ich.
Es handelt sich dabei wohl eher um eine Optimierung wenn viele Daten auflaufen und eine Warteschlange entsteht.
Unsere Raid-Controller in den Servern haben z.b. 2GB RAM, da kann viel gepuffert werden und effizienter gearbeit werden.

Wenn die Festplatte "Langeweile" hat, wird sie das 4k Paket direkt auf die Platte schreiben und nicht auf weitere Daten warten.

 

[Masamune2]

Das funktioniert etwas anders wie du dir vorstellst und einen passenden Link habe ich auch beigefügt.

Ich stell mir das auch anders vor, es war nur die Frage ob ich deine Aussage so interpretieren kann. Denn allein das Write Commit ist nicht der Unterschied zwischen WB und WT.
Ich weiß sehr wohl wie das funktioniert.

Es macht nur keinen Sinn bei Raid Leveln ohne Parität die Daten so lange im Cache liegen zu lassen bis ein komplettes Stripeset zusammen gekommen ist, die werden auch direkt auf die Platten durchgeschrieben sobald dafür Zeit ist.