Kurze Frage Raid 5 und Alignment

[Holt]

Ohne Prüfsummen hat das Dateisystem keine Chance einzelne Bitdreher zu erkennen. Das merkt man dann erst wenn man die JPG Datei öffnen und das Bild nen Fehler hat.

Moment, das ist ja nicht die Aufgabe des RAIDs, bzw. machen das nur SCSI/SAS Controller die ihre Platte mit 520/528 Byte pro Sektor formatieren und diese zusätzlichen 8/16Byte für eine eigenen ECC nutzen. Das geht aber bei SATA nicht und soll deshalb nicht Gegenstand der Betrachtungen sein.

Bei SATA sieht es so aus, dass die HDDs selbst die ECC verwalten und eine bestimmte Zeit lang versuchen den Sektor doch noch fehlerfrei zu lesen, bei WD heißt dies TLER. Schafft die Platte es nicht diesen Sektor fehlerfrei zu lesen, bzw. so fehlerfrei, dass die ECC ausreicht die Bitfehler zu korrigieren, denn meldet sie einen Lesefehler und den sollte das RAID nicht ignorieren, sonst würde auch nicht nur ein gekipptes Bit die Folge sein.

Von daher sollte das, was Du hier beschreibst nicht auftreten bzw. sollte man solche primitiven RAID Lösungen unbedingt meiden:

Klassisches Raid ist soweit ich weiß "dumm". Sprich es wird erst auf den Spiegel zugriffen wenn eine Platte gar keine Daten liefert. Zumindest war es früher so dass bei einem Raid1 es keine Chance gab um sagen zu können auf welcher Platte nun die richtigen und wo die falschen Daten sind wenn sie nicht komplett identisch waren. Das geht nur mit Prüfsummen.

Da ZFS auch allen freien Ram benutzt für Lese und Schreibcache kann man hier teilweise auch auf richtig hohe Werte kommen beim Benchen wenn die Dateien nur klein genug sind sodass sie in den Ram passen.

Wobei immer die Frage ist, wie praxisgerecht ein solcher Benchmark dann noch ist, wenn der alleine den Cache bencht.

Der Aufbau passt schon. Ich schicke auch 20GB in den non-ECC RAM meiner Workstation und am Ende kommen bunte Bildchen raus. Mal alles nicht dramatisieren.

Moment, Du hast glaube ich den Unterschied noch nicht verstanden. Bei einem Desktop oder eine WS wird etwas ins RAM geladen und damit gearbeitet. Die Daten stehen da also nicht so lange im RAM wie es bei einem Storageserver durchaus vorkommen kann, gerade Zuhause wo nicht so viele Leute ständig auf so viele Dateien zugreifen, dass der Cacheinhalt ständig ausgetaucht wird.

Außerdem hat man am Rechner auch mal, dass ein Programm abstürzt oder komisch reagiert und dann geht alles wieder ohne Probleme. War es ein Bug oder ist ein Bit im RAM gekippt? Du wirst es nie erfahren und daher merkst Du solche Bitfehler die entstehen weil in Bit des RAM Inhalts gekippt ist, auch gar nicht. Das geht nur mit ECC RAM.

Wie ihr schon richtig vermutet hattet, wäre jetzt die Frage, ob ich ein Software-RAID5 oder RAID6 oder ein Hardware RAID schalte. Das werde ich entscheiden, bis ich die Mindestmenge von 3 Platten zusammen habe.

Dann achte auch darauf, ob die Lösung ein dynamisches Erweitern des RAIDs und eine Umstellung von RAID 5 auf RAID 6 erlaubt. Meist geht es, aber es wäre schon schlecht, wenn das doch nicht gehen würde.

@Holt: Bitte richtig zitieren und nur die unwichtigen Stellen Streichen. Da oben stand WD Red pro.

Die gibt es aber nicht mit 6TB und die UBER der Red Pro ist nicht besser als die der normalen Red.

 

[Bogeyman]

Wobei immer die Frage ist, wie praxisgerecht ein solcher Benchmark dann noch ist, wenn der alleine den Cache bencht.

Naja man muss die Daten nur groß genug machen damit sie halt nicht in den Cache passen. Jedenfalls Gbit auszureizen ist problemlos möglich auch ohne Cache.

Richtig, die UBER Problematik wird damit auch massiv entschärft, da ja der Bitfehler einer Platte durch die von vorhandene Redundanz, bei Ausfall einer Platte ich ein RAID 6 ja immer noch wie ein RAID 5, ausgeglichen werden kann. Man müsste mal ausrechnen ab wann das dann auch an Grenzen stößt, aber das ist bei Kapazitäten die noch in ganz weiter Ferne liegen.

Bei nem Raid6 (degraded) müsste ein Fehler aber mindesten bei 2 Platten auftauchen und noch dazu an der gleichen Stelle. Sprich selbst wenn es mehrere Bitfehler gibt ist das egal da die Warscheinlichkeit minimal ist dass sie an den selben Stellen sind bei jeder Platte.

Wie ihr schon richtig vermutet hattet, wäre jetzt die Frage, ob ich ein Software-RAID5 oder RAID6 oder ein Hardware RAID schalte. Das werde ich entscheiden, bis ich die Mindestmenge von 3 Platten zusammen habe.

Es gibt Hard- und Software. Storage Spaces und ZFS zählen aber nicht zu Software Raid.

Von Software Raid unter Windows würde ich abraten, soll nicht so stabil laufen. Wenn dann eher Hardware, ich würde aber SS bevorzugen. Allerdings gibts da kein dynamisches erweitern.
Man kann es schon erweitern aber muss bestimmte Sachen beachten was die Anzahl der Platten betrifft

 

[Masamune2]

mdadm und zfs sind beim Schreiben so viele schneller da sie den RAM als Write-Back Cache verwenden. Das tut Microsoft mit Absicht nicht und hat nichts mit schlechte Algo zu tun, denn wenn der Rechner abschmiert bevor die Daten auf die Platten kopiert werden konnten sind sie im Nirwana. Mit Server 2012 R2 und Storage Space kann ich allerdings SSDs als Write-Back Cache nutzen und bringe so auch ein Software Raid unter Windows auf gescheite Schreibraten.

 

[Bogeyman]

mdadm und zfs sind beim Schreiben so viele schneller da sie den RAM als Write-Back Cache verwenden. Das tut Microsoft mit Absicht nicht und hat nichts mit schlechte Algo zu tun, denn wenn der Rechner abschmiert bevor die Daten auf die Platten kopiert werden konnten sind sie im Nirwana.

Man kann Daten auch mit dem Sync Befehl senden. Dann bekommste bei ZFS auch erst das "ok" wenn die Daten auf den Platten sind.
Allerdings hat es sehr wohl was mit schlechtem Algo zu tun. Ich habe 9GB Ram, sprich 8GB rein zum Cachen. Meist habe ich so 80-100MB/s schreibend. Gehen wir jetzt mal davon aus dass ZFS intern nur etwa 30MB/s schreiben könnte wie Windows, ich aber mit 80MB/s kopiere. Dann wären die 8GB nach 2:45min bzw. 13GB voll (bei 50MB/s differenz) und die Geschwindigkeit müsste auf 30MB/s abfallen, sprich die Geschwindigkeit mit der auf die Platten geschrieben wird. Ich kann dir aber sagen dass ich selbst 20GB und mehr dauerhaft mit 80-100MB/s auf meinen Pool schreiben kann. Das ist also nicht mit dem Cache zu erklären.


Obendrein hatte ich damals zu Pentium 4 Zeiten mit Windows Software Raid5 schon 30MB/s und jetzt nen paar Jahre und CPU Generationen später dümpeln alles was mit Parity zu tun hat immer noch da rum und die Leute berichten teilweise auch nur von 10% CPU Last.

 

[Masamune2]

Doch, der Grund warum man den Cache nutzt ist ja nicht um in den ersten paar Minuten möglichst schnell schreiben zu können, sondern um immer möglichst komplette Stripesets auf einmal schreiben zu können. Hab ich weiter vorne aber auch schon mal erklärt.

 

[Bogeyman]

Ja aber was soll ich dir sagen Bei ZFS habe ich nunmal durchgängig deutlich höhere Schreibwerte als bei Windows. Wo sollen die Daten denn hingeschrieben werden wenn der Ram voll ist?

Das ist nur so zu erklären dass ZFS deutlich schneller als Windows bei Parity arbeitet

sondern um immer möglichst komplette Stripesets auf einmal schreiben zu können

Ja schon klar dann sollte man bei Windows den Write Back Cache aber ebenso aktivieren. Bei einem Copy On Write Dateisystem wären beim Stromausfall auch eh nur die Daten betroffen die man grade eben geschrieben hat, alles was auf den Festplatten liegt ist da ja nicht in Gefahr.

Ich persönlich nutze eh eher kopieren statt verschieben. Dann muss man eben die paar Sekunden abwarten ob es kein Stromausfall gibt.
Oder sync writes da kann man es für einzelne Dateien angeben ob Write Back genutzt wird oder nicht. Ist doch irgendwo auch sinnvoller als es komplett nur an und aus zu schalten.

Beim nem Word dokument kann ich auf Write Back verzichten, da ist mir Sicherheit wichtiger. Bei nem Video ist Sicherheit aber weniger wichtig, weils meist Kopien gibt. Da wären mir 100MB/s wichtiger als 30MB/s

Kann man das bei Windows wenigstens für einzelne Freigaben getrennt regeln?

 

[Masamune2]

Ja aber was soll ich dir sagen Bei ZFS habe ich nunmal durchgängig deutlich höhere Schreibwerte als bei Windows. Wo sollen die Daten denn hingeschrieben werden wenn der Ram voll ist?

Auf Platte, aber dann immer ein ganzes Stripeset am Stück, sodass man sich das Einlesen, Daten ändern, Parität berechnen und dann erst neu schreiben sparen kann.

Bei einem Copy On Write Dateisystem wären beim Stromausfall auch eh nur die Daten betroffen die man grade eben geschrieben hat, alles was auf den Festplatten liegt ist da ja nicht in Gefahr.

Und das reicht nicht? Also ich hätte schon etwas dagegen wenn meine Anwendung zurück gemeldet bekommt das alles geschrieben wurde und der Cache die Daten anschließend verliert weil der Strom weg war.

Kann man das bei Windows wenigstens für einzelne Freigaben getrennt regeln?

Nein, die Freigaben haben auf Ebene des Volume Managers nicht verloren. Aktivieren lässt sich der Write Back Cache nur pro Storage Space wenn man SSDs hinzugefügt hat.

 

[Bogeyman]

Nein, die Freigaben haben auf Ebene des Volume Managers nicht verloren.

Warum? Weil das irgendwer mal so in Stein gemeißelt hat?

Wie gesagt ich finds recht dämlich so zu lösen.

Und das reicht nicht? Also ich hätte schon etwas dagegen wenn meine Anwendung zurück gemeldet bekommt das alles geschrieben wurde und der Cache die Daten anschließend verliert weil der Strom weg war.

Ansichtssache. Der eine wartet dann lieber 3mal so lange dafür. Muss jeder selber wissen.

Bei mir dient der Server als Backup und als Medienserver. Große Dateien kopiere ich eh statt ich sie verschiebe und nen Backup ist auch immer nur ne Kopie von etwas anderem. Strom fällt hier in Deutschland auch eher sehr sehr selten aus noch müsste er genau in dem Moment ausfallen nachdem ich grade was gespeichert habe.

Unter all den Umständen kann ICH daher auf diese Sicherheit verzichten.

 

[Masamune2]

Warum? Weil das irgendwer mal so in Stein gemeißelt hat?

Nein, aber es ist nun mal zu Zeit so? Wo ist dein Problem? Natürlich kann sich das auch mal ändern.

Ansichtssache. Der eine wartet dann lieber 3mal so lange dafür.

Oder schafft sich Batterie/Flash gestützten Schreibcache an der seit Jahrzehnten bei Storagesystemen Standard ist. Mag ja sein das du konkret keinen brauchst, hier ging es aber ja allgemein darum was möglich ist.

 

[Bogeyman]

Nein, aber es ist nun mal zu Zeit so? Wo ist dein Problem? Natürlich kann sich das auch mal ändern.

Sorry aber "weil das zur Zeit so ist" ist doch kein Argument..

Bei ZFS habe ich halt die möglichkeit sync writes an aus oder auf auto zu stellen. Bei Auto entscheidet dann ganz einfach derjenige der schreibt wie er es gern hätte.

Ich persönlich finde das praktisch da man so dokumente welche eher klein aber wichtig sind direkt auf die Platten schreiben lässt, weil Performance egal ist und bei großen Videodateien nutzt man die maximale Leistung. Man kann sogar Freigaben mit verschiedenen Einstellungen einrichten. Geht bei Windows alles nicht.

Auf meinem Pool sind nunmal nicht nur Multimediadateien, und wenn ich das ganze dann nur Global an und aus stellen kann finde ich das nicht grad praktisch. Entweder schlafe ich dann ein beim großen Datein schreiben wie Videos oder hab mehr Risiko weil nen Word Dokument futsch ist. Ist doch dumm

Oder schafft sich Batterie/Flash gestützten Schreibcache an der seit Jahrzehnten bei Storagesystemen Standard ist. Mag ja sein das du konkret keinen brauchst, hier ging es aber ja allgemein darum was möglich ist.

Das ist aber Hardware und die kostet zusätzlich Geld wohingegen die Software einfach schlauer zu machen billiger käme.

 

[Masamune2]

Wieso sollte das auch ein Argument sein, es ist schlicht eine Tatsache. Darüber braucht man nicht diskutieren, es ist wahr egal was man für eine Meinung davon hat^^

Mir ging es auch eher darum klar zu machen das man flüchtigen Speicher nun mal nicht als Schreibcache nutzen kann wenn einem die Daten wichtig sind. Bin mir nicht sicher ob das jetzt angekommen ist aber habe auch keine Lust mehr mich ständig zu wiederholen.

 

[Bogeyman]

Wieso sollte das auch ein Argument sein, es ist schlicht eine Tatsache. Darüber braucht man nicht diskutieren, es ist wahr egal was man für eine Meinung davon hat^^

Die Welt besteht aber nichtmal nur aus Windows und Linux.

Nein, aber es ist nun mal zu Zeit so?

Auf einzelne Betriebsysteme bezogen vllt aber doch nicht generell. Wie gesagt es gibt andere Ansätze und die finde ich teilweise deutlich besser als den Weg wie MS es handhabt.

Mir ging es auch eher darum klar zu machen das man flüchtigen Speicher nun mal nicht als Schreibcache nutzen kann wenn einem die Daten wichtig sind.

Klar "kann" man... Beim sync write kommt dann aber erst die Bestätigung wenn die Daten auf den Platten sind. Das heißt aber nicht dass sie direkt dadrauf geschrieben werden müssen.

Ferner speichert man wenn man klever ist eh öfter ab (zB bei Office), bzw macht das die Software automatisch. In dem Fall wäre dann sowieso nur die Arbeit der letzten paar Minuten weg.

Und wenn du hingehst und sagst der Server braucht umbedingt ne USV wegen dem Cache dann brauchste an deiner Workstation/DesktopPC ebenso eine um keine Daten zu verlieren.

Ich mein wenn ich nen großes Video rendere oder was kopiere und mittendrin fällt Strom aus sind die Dateien eh für die Tonne. Egal ob man nun Write Back Cache benutzt hat oder nicht.

Es geht ja nur um diesen einen Moment wo die Daten noch nicht auf den Platten sind. Sprich ich muss was drauf geschrieben haben und grade nachdem ich fertig bin muss der Strom ausfallen. Das ist zwar nicht unmöglich aber doch sehr unwarscheinlich, zumindest bei nem Homeserver bei 1 oder 2 Nutzern.

Man kann daher WBC auch nutzen ohne ein Risiko einzugehen. Bei mir sinds halt Backups hauptsächlich. Was müsste denn deiner Meinung nach passieren damit ich bei WBC=on Datenverlust erleide bei einem Stromausfall?

 

[Ilsan]

Masamune2: Kannst du vielleicht mal erklären wieso das Raid5 bei Windows deutlich langsamer ist wenn es denn nicht an der Software liegen soll?

Unabhängig von der Write Back Cache Geschichte reden wir bei den genannten 30-40MB/s ja nur von einem Bruchteil der Übertragungsrate von einer Festplatte alleine.

Wenn es so ist wie du sagst dann müsste ein Raid1 oder 10 ebenfalls bei 30-40MB/s daher dümpeln was es aber nunmal nicht tut.

Write Back Cache kann die Sache beschleunigen aber das Problem scheint mir doch eher da zu liegen dass irgendwas anderes hier bremst.

 

[Masamune2]

Hab ich irgendwo oben schon mal angerissen aber ich finds grad selbst nicht mehr. Daher noch mal:

Das Stichwort hier ist Write Penalty (und unter diesem Stichwort finden sich auch schon tausende Erklärungen per Google).

Die Kurzfassung:
Bei Raid Leveln ohne Parität (Raid 1 oder 10) können die Daten direkt auf die Platten geschrieben werden als ob es eine normale einzelne Platte wäre. Hier gibt es quasi keine Geschwindigkeitsunterschied zwischen einer Einzelplatte und einem Raid 1.

Bei Raid Leveln mit Parität (5 und 6) kann man nicht einfach beliebige Blöcke neu schreiben da dann die Parität nicht mehr zu den Daten passt. Bei jedem Schreibzugriff muss also zunächst ein komplettes Stripeset (Stripegröße * Anzahl der Platten) eingelesen werden. Anschließend werden die Daten geändert, die Parität neu berechnet und der komplette Stripe neu geschrieben. Das kostet logischerweise Zeit und senkt die Transferrate.

Beispiel: Ich habe ein Raid 5 aus 5 Platten und einer Stripesize von 256kb. Ein komplettes Stripeset besteht also aus 1280kb Daten. Will ich darin jetzt 4kb ändern (ein NTFS Cluster) müssen erst 1280kb gelesen, darin die 4k Daten geändert, die 256kb Parität neu berechnet und anschließend 1280kb neu geschrieben werden. Um 4k Daten zu ändern werden 2560kb Daten "bewegt".

Hat man jetzt einen Schreibcache sorgt dieser dafür, dass die Daten zunächst gesammelt werden bis ein kompletter Stripeset beisammen ist. Dann kann man diesen inkl. Parität direkt auf die Platten schreiben ohne vorher die alten Daten lesen zu müssen. Die Geschwindigkeit steigt dadurch enorm an.
Der Nachteil hier ist jetzt das die Applikation davon ausgeht die Daten sind auf der Festplatte sicher geschrieben obwohl sie noch im Cache liegen können. Schmiert jetzt der Server ab sind die Daten im Cache weg. Um das zu verhindern sichert man diesen in der Regel entsprechend ab.
Nun kann man bei Linux Software Raids (oder halt auch ZFS) trotz fehlender Absicherung den Cache trotzdem aktivieren. Man sollte sich halt darüber im Klaren sein das es zu Datenverlust kommen KÖNNTE. Wie wichtig die Daten in dem Moment waren muss jeder selbst wissen.
Windows lässt das halt nicht zu, da vermutlich zu viele Hobby Admins damit ihre Datenbanken killen würden. Außerdem bräuchten NTFS Volumes dann immer einen chkdsk Lauf der auch mal längern dauern kann. Der alte LVM von Windows stammt übrigens gar nicht direkt von Microsoft sondern ist eine abgespeckte Version von Veritas Storage Foundation.


Ansonsten wie gesagt einfach mal "Raid 5 write penalty" googlen, es gibt zahlreiche Erklärungen, teils mit bunten Bildchen^^

 

[Rumo]

Beispiel: Ich habe ein Raid 5 aus 5 Platten und einer Stripesize von 256kb. Ein komplettes Stripeset besteht also aus 1280kb Daten. Will ich darin jetzt 4kb ändern (ein NTFS Cluster) müssen erst 1280kb gelesen, darin die 4k Daten geändert, die 256kb Parität neu berechnet und anschließend 1280kb neu geschrieben werden. Um 4k Daten zu ändern werden 2560kb Daten "bewegt".

Die Chunksize bedeutet keineswegs, daß immer der ganze Chunk gelesen/geschrieben werden muss.

Linux (mdadm) macht das auch nicht bei RAID 5. Da werden bei 512k Chunk Size, wenn du 4k schreibst, trotzdem nur 4k (Daten) + 4k (Parity) neu geschrieben. An den restlichen 508k des Chunks ändert sich ja nichts, selbst wenn du alles liest.

 

[Masamune2]

Ja die Erklärung war an der Stelle nicht ausführlich genug. mdadm macht es hier geschickter, löst aber nur einen Teil des Problems da nach wie vor die 4k Daten plus 4k Parität gelesen und anschließend geschrieben werden müssen. Um 4k zu schreiben muss ich wieder 16k Daten bewegen.

Um es zu vervollständigen: ZFS macht es noch viel besser da es keine feste Stripesize gibt und jeder Schreibzugriff immer vollständig ist. Allerdings hat ZFS dafür mit mehr Metadaten zu kämpfen und wird dadurch langsamer.

 

[Ilsan]

Bei Raid Leveln ohne Parität (Raid 1 oder 10) können die Daten direkt auf die Platten geschrieben werden als ob es eine normale einzelne Platte wäre. Hier gibt es quasi keine Geschwindigkeitsunterschied zwischen einer Einzelplatte und einem Raid 1.

Bei Raid Leveln mit Parität (5 und 6) kann man nicht einfach beliebige Blöcke neu schreiben da dann die Parität nicht mehr zu den Daten passt. Bei jedem Schreibzugriff muss also zunächst ein komplettes Stripeset (Stripegröße * Anzahl der Platten) eingelesen werden. Anschließend werden die Daten geändert, die Parität neu berechnet und der komplette Stripe neu geschrieben. Das kostet logischerweise Zeit und senkt die Transferrate.

Das würde aber nur die Veränderung erklären, nicht aber das komplett neuschreiben.

Ein Raid5 ist doch im Grunde auch nichts anderes als ein Raid0 vom Stripping her. Die Berechnung der Parität dürfte für eine heutige CPU auch nebenbei zu erledigen sein.

Und was genau da auf die Platten geschrieben wird macht für die Performance auch kein Unterschied, ob das nun 0en oder 1sen sind, ob das Nutzdaten oder Paritätsinfos sind ist der Platte ja egal.

Wenn ein Windows Raid 5 oder Storage Spaces mit Parity dauerhaft eine hohe Performance liefern bei aktiviertem WBC (dauerhaft=deutlich mehr Daten als in den Ram passen) würd ich auch sagen es liegt nicht an der Software.

Mit Windows kann ich das aber nicht testen wäre zu aufwendig, aber ich könnte bei meinem ZFS mal den Cache deaktivieren und gucken wo ich dann da lande

Allerdings hat ZFS dafür mit mehr Metadaten zu kämpfen und wird dadurch langsamer.

Langsamer ja aber ich würde sagen das dürften maximal 10% an einbußen sein.

 

[Rumo]

Die Berechnung der Parität dürfte für eine heutige CPU auch nebenbei zu erledigen sein.

Bei ner 0815 Haswell Kiste: raid6: using algorithm avx2x4 (26796 MB/s). Davon merkst du nix.

 

[Masamune2]

Ein Raid5 ist doch im Grunde auch nichts anderes als ein Raid0 vom Stripping her.

Naja da kann man jetzt viel rein interpretieren. Es ist schon was anderes wie oben erklärt.

Die Berechnung der Parität dürfte für eine heutige CPU auch nebenbei zu erledigen sein.

Korrekt, das ist bei weitem nicht das Problem.

Und was genau da auf die Platten geschrieben wird macht für die Performance auch kein Unterschied

Richtig, aber wenn ich im Windows angezeigt bekomme das gerade 30MB/s auf die Platten geschrieben wird, durch die Write Penalty sind es aber in Wirklichkeit 200MB/s wird ein Schuh draus.

Wenn ein Windows Raid 5 oder Storage Spaces mit Parity dauerhaft eine hohe Performance liefern bei aktiviertem WBC (dauerhaft=deutlich mehr Daten als in den Ram passen) würd ich auch sagen es liegt nicht an der Software.

Nochmal: Der RAM wird NICHT als Schreibcache genutzt. Lediglich bei Storagespaces unter Server 2012 R2 kann man SSDs als Cache nutzen und dann ist die Datenrate auf einmal auch sehr viel höher. Siehe:
http://globalsp.ts.fujitsu.com/dmsp...ndows-storage-spaces-r2-performance-ww-de.pdf File Copy oder File Server Benchmark Seite 30.

 

[Holt]

Beispiel: Ich habe ein Raid 5 aus 5 Platten und einer Stripesize von 256kb. Ein komplettes Stripeset besteht also aus 1280kb Daten. Will ich darin jetzt 4kb ändern (ein NTFS Cluster) müssen erst 1280kb gelesen, darin die 4k Daten geändert, die 256kb Parität neu berechnet und anschließend 1280kb neu geschrieben werden. Um 4k Daten zu ändern werden 2560kb Daten "bewegt".

Es braucht nicht das ganze Stripeset gelesen und schon gar nicht alles neu geschrieben zu werden. Einmal kann man auf das Lesen der Parity verzichten, solange kein Lesefehler auftritt (ist bei RAIDs auch üblich) und dann muss man nur schreiben war geändert wurde, also in diesem Fall 8k, die 4k neuer Daten und die 4k neue Parity. Und natürlich kann man auch da noch kürzen und liest nur die 4k von den anderen Datenplatten ein, die überhaupt für die Parityänderung relevant sind, dann liest man nur 12k und schriebt 8k, aber im Vergleich zu einem RAID 1 oder 10 ist das immer noch eine Penalty.

Da werden bei 512k Chunk Size, wenn du 4k schreibst, trotzdem nur 4k (Daten) + 4k (Parity) neu geschrieben. An den restlichen 508k des Chunks ändert sich ja nichts, selbst wenn du alles liest.

Eben und die Frage ist da, was man alles lesen muss und das sind im Prinzip nur die 4k der anderen 3 Platten die die Daten enthalten die mit den neu zu schreibenden Daten zusammen die neue Parity ergeben werden.