Storage Spaces Write Back Cache (Parity)

Nutz doch erstmal den "WriteCacheSize" und erhöhe den WBC auf 5GB. Vielleicht tut sich da ja noch was. Ebenfalls wäre interessant, ob die Geschwindigkeit bei ungerader Plattenanzahl steigt (3,5,7...), manchmal wird davon berichtet.
Nur als letzte Option bliebe mal testweise die Möglichkeit, eine Virtuelle Ferstplatte auf der SSD zu erstellen und diese in den Pool aufzunehmen. Vielleicht klappts ja, sollte aber definitiv nicht produktiv eingesetzt werden.

@fdsonne
Müsste eigentlich problemlos klappen. Zumindest, wenn du alle HDDs gleichzeitig dem Pool hinzufügst und den Pool aus 3x500GB nicht später erst um 3x1000G erweiterst.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
@fdsonne
Müsste eigentlich problemlos klappen. Zumindest, wenn du alle HDDs gleichzeitig dem Pool hinzufügst und den Pool aus 3x500GB nicht später erst um 3x1000G erweiterst.

So recht klar ist mir das noch nicht, was Windows da genau macht beim Erstellen. Das war damals auch mein erster Gehversuch mit den Storage Spaces. Muss das bei Gelegenheit nochmal durchtesten...
Dachte eigentlich auch, dass das soweit funktioniert. Aber irgendwie hatte ich dann am Ende die Single Parity virtuellen Drives über die jeweiligen HDDs erstellt und als ich dann das Volume erstellen wollte, war die Größe nicht auf die Summe aller Pools einrichtbar, sondern ich musste zwei Volumes erstellen um die maximale Größe nutzen zu können... Eben wie, wenn der das nicht über zwei Pools erketten wollte.

Aber ggf. hab ich da auch grundlegend was falsch gemacht?
Ich hatte die Pools definitiv über die GUI erstellt für den damaligen Test.

Mal gucken, ggf. schaff ich das morgen mal nochmal anzugehen.
 
SS; 4x4TB SATA; Parity; WBC 10GB; => Capacity 10,8TB
Anhang anzeigen 297837

-----------------------------------------------------------------------
CrystalDiskMark 3.0.3 x64 (C) 2007-2013 hiyohiyo
Crystal Dew World : Crystal Dew World
-----------------------------------------------------------------------
* MB/s = 1,000,000 byte/s [SATA/300 = 300,000,000 byte/s]

Sequential Read : 456.498 MB/s
Sequential Write : 89.820 MB/s
Random Read 512KB : 45.679 MB/s
Random Write 512KB : 211.255 MB/s
Random Read 4KB (QD=1) : 0.153 MB/s [ 37.3 IOPS]
Random Write 4KB (QD=1) : 1.768 MB/s [ 431.7 IOPS]
Random Read 4KB (QD=32) : 5.010 MB/s [ 1223.1 IOPS]
Random Write 4KB (QD=32) : 66.859 MB/s [ 16322.9 IOPS]

Test : 4000 MB [E: 0.0% (0.5/11156.9 GB)] (x5)
Date : 2014/10/12 9:29:36
OS : Windows Server 2012 R2 Datacenter (Full installation) [6.3 Build 9600] (x64)

SS; 4x4TB SATA; Parity; WBC 100GB; => Capacity 10,8TB
Anhang anzeigen 297838
-----------------------------------------------------------------------
CrystalDiskMark 3.0.3 x64 (C) 2007-2013 hiyohiyo
Crystal Dew World : Crystal Dew World
-----------------------------------------------------------------------
* MB/s = 1,000,000 byte/s [SATA/300 = 300,000,000 byte/s]

Sequential Read : 302.969 MB/s
Sequential Write : 243.912 MB/s
Random Read 512KB : 47.249 MB/s
Random Write 512KB : 251.589 MB/s
Random Read 4KB (QD=1) : 0.398 MB/s [ 97.2 IOPS]
Random Write 4KB (QD=1) : 37.483 MB/s [ 9151.2 IOPS]
Random Read 4KB (QD=32) : 2.589 MB/s [ 632.0 IOPS]
Random Write 4KB (QD=32) : 65.548 MB/s [ 16002.8 IOPS]

Test : 4000 MB [E: 0.0% (0.5/11021.9 GB)] (x5)
Date : 2014/10/12 9:44:21
OS : Windows Server 2012 R2 Datacenter (Full installation) [6.3 Build 9600] (x64)


Hmm so ganz glauben kann ich die Messwerte nicht glauben

14GB Windows filecopy von SSD zu SS; 4x4TB SATA; Parity; WBC 100GB; => Capacity 10,8TB
14GB_file_copy.jpg

sustained write speed sieht für mich anders aus :d
 
Zuletzt bearbeitet:
Nach vorbild aus dem Thread

Code:
$phy = Get-PhysicalDisk -CanPool $true
New-StoragePool -FriendlyName PoolImages -StorageSubSystemFriendlyName "Storage Spaces*" -PhysicalDisks $phy
New-StoragePool -FriendlyName Pool -StorageSubSystemFriendlyName "Storage Spaces*" -PhysicalDisks $phy
Get-StoragePool -FriendlyName Pool | Get-PhysicalDisk
Get-StoragePool -FriendlyName Pool | Get-PhysicalDisk | ? Size -lt 300GB | Set-PhysicalDisk -MediaType SSD
Get-StoragePool -FriendlyName Pool | Get-PhysicalDisk | ? Size -gt 300GB | Set-PhysicalDisk -MediaType HDD
New-StorageTier -FriendlyName TierSSD -StoragePoolFriendlyName Pool -MediaType SSD
New-StorageTier -FriendlyName TierHDD -StoragePoolFriendlyName Pool -MediaType HDD
Get-StoragePool -FriendlyName Pool | Get-PhysicalDisk | ? MediaType -eq SSD | Set-PhysicalDisk -Usage Journal
New-VirtualDisk -StoragePoolFriendlyName Pool -FriendlyName vDisk -UseMaximumSize -ResiliencySettingName Parity -ProvisioningType fixed -WriteCacheSize 50GB

SS; 4x4TB+50GB SSD von 500GB SSD SATA; Parity; WBC 50GB; => Capacity 10,8TB
T20E1225v3_4_4TB_50GBSSD_Parity_50GBWBC.jpg

-----------------------------------------------------------------------
CrystalDiskMark 3.0.3 x64 (C) 2007-2013 hiyohiyo
Crystal Dew World : Crystal Dew World
-----------------------------------------------------------------------
* MB/s = 1,000,000 byte/s [SATA/300 = 300,000,000 byte/s]

Sequential Read : 456.200 MB/s
Sequential Write : 221.172 MB/s
Random Read 512KB : 39.196 MB/s
Random Write 512KB : 251.978 MB/s
Random Read 4KB (QD=1) : 0.200 MB/s [ 48.9 IOPS]
Random Write 4KB (QD=1) : 2.495 MB/s [ 609.0 IOPS]
Random Read 4KB (QD=32) : 2.544 MB/s [ 621.1 IOPS]
Random Write 4KB (QD=32) : 69.996 MB/s [ 17088.9 IOPS]

Test : 4000 MB [E: 0.1% (14.8/11096.9 GB)] (x5)
Date : 2014/10/12 13:56:33
OS : Windows Server 2012 R2 Datacenter (Full installation) [6.3 Build 9600] (x64)
 
@simon
Danke für die Tests.
Das ist ja absolut verrückt. D.h. du hast tatsächlich höheren Write-Speed auch ohne SSD im Pool, wenn du einfach nur den WBC manuell erhöhst?
Storage Spaces sind einfach unpredictable, das hat sich in anderen Threads auch schon als Quintessenz ergeben.
Es ist weder wirklich vorherzusehen, wieviel GB jetzt wirklich bei Parity bei unterschiedlichen Festplattengrößen genutzt werden, noch wie schnell jetzt wirklich ein SS-Pool ist.
Aus anderen Threads weiß ich, dass die WBC-Größe ebenfalls entscheidenden Einfluss auf den Write-Speed hat und zwar nicht konstant. Soll heißen, manchmal sind 5GB WBC besser als 100GB. Ebenfalls hat es einen Einfluss, ob die SSDs als Journal genutzt werden (ebenfalls nicht konstant) und wieviele Columns ein Pool hat.
Ihr seht schon SS sind a) miserabel dokumentiert und b) alles andere als vorhersagbar und nachvollziehbar. Alles in allem würde ich niemandem ernsthaft SS für seine wichtigen Daten empfehlen, das ist alles viel zu undurchsichtig. Das fängt schon damit, wenn eine Festplatte ausfällt. Der Pool repariert sich dann nicht so einfach von alleine und ist mit falscher Handhabung sofort für immer verloren (gibt etliche Threads dazu).

Typisch Microsoft, mal wieder richtigen Bullshit gebaut. Ich hoffe auf Win 10 oder Server 2015/16.
 
@simon
Danke für die Tests.
Das ist ja absolut verrückt. D.h. du hast tatsächlich höheren Write-Speed auch ohne SSD im Pool, wenn du einfach nur den WBC manuell erhöhst?

Was jetzt primär aber auch nicht unbedingt unlogisch ist... Der größere Cache, sofern das OS diesen auch als solches nutzt, würde ja länger die höhere Schreibperformance garantieren. Die Frage ist eher, warum bei 100GB WBC und einem Transfer eines "nur" 15GB großen Files gegen Ende hin die Datenrate so massiv zusammenbricht?
Das sollte eigentlich nicht der Fall sein, wenn das richtig funktioniert.

Typisch Microsoft, mal wieder richtigen Bullshit gebaut. Ich hoffe auf Win 10 oder Server 2015/16.

Kannst ja mal die Windows Server Preview antesten. Da gibts ja imho aktuell eine Version mit Basis "Windows 10" zum Download bei MS...
Auch diese hat das Startmenü wieder bekommen, wenn auch in eingekürzter Form ohne die App Leiste. Entspricht damit sozusagen dem halben Windows 7 Startmenü und hat damit den Touch eines alten Windows 95 Startmenüs + das Suchfeld am unteren Rand (was es ja erst ab Vista gab)

Eventuell hat MS ja da schon weitere Sachen gedreht bei den Storage Spaces.
 
Unwahrscheinlich. Die Preview soll noch um etliche Funktionen gekürzt worden sein.

Es ist insofern unlogisch, als dass der WBC eigentlich nur mit SSDs funktionieren sollte, nicht mit HDDs. Ebenfalls ist es so, dass 100GB nicht unbedingt besser als 10GB WBC ist - selbst wenn die zu kopierende Datei weitaus kleiner ist, als der WBC. Und genau das ist der springende Punkt:

Die Transferrate bricht ein, obwohl der WBC nicht verbraucht ist. Und es kann u.U. laut anderen Threads sein, dass bei 10GB WBC die Schreibgeschwindigkeit eben nicht einbricht, während es sie bei 100GB doch tut.

Und ja: Der Einbruch der Schreibgeschwindigkeit lässt sich auch auf SSDs beobachten - und zwar in etwa um dieselben Werte (siehe dazu Thread auf CB).
Warum das so ist, das weiß wohl nichtmal MS selbst.
 
Es ist insofern unlogisch, als dass der WBC eigentlich nur mit SSDs funktionieren sollte, nicht mit HDDs. Ebenfalls ist es so, dass 100GB nicht unbedingt besser als 10GB WBC ist - selbst wenn die zu kopierende Datei weitaus kleiner ist, als der WBC. Und genau das ist der springende Punkt:

Ja aber was sollte da technisch dagegen sprechen das auch mit HDDs zu machen?
Rein von der Warte her ist das ja zumindest bei einigen Systemen durchaus gängige Praxis schnelle SAS Platten mit langsamen Platten zu kombinieren... Da gibts schon ein paar Hersteller die sowas intelligent nutzen. Mit den Storage Spaces will ja MS auch dort ansetzen. Nur spricht man eben häufiger bzw. fast ausschließlich von SSDs in Verbindung mit HDDs anstatt von schnellen und langsamen Platten oder gar nem Tripplegespann aus allein dreien.

Was die reine Cachegröße angeht, ggf. tritt da ein Umstand in Kraft, den ich bspw. von NetApp Systemen kenne. Dort wird bspw. der Cache entweder dann geleert und auf die Platten geschrieben, wenn er A) voll ist bzw. fast voll ist, oder B) wenn eine bestimmte Zeit verstrichen ist. Könnte bei MS ggf. ähnlich laufen... Sprich zu großer Cache würde dann bedeuten, dass man gar nicht umhin kommt, diesen völlig zu befüllen... Irgendwo sollte es, sofern diese Theorie stimmt, einen Break Even Point geben, wo der Speed dann wieder sinkt... Das ganze müsste rein von der Theorie her stark davon abhängen, wie das Plattensystem dahinter agiert. Was auch erklären würde, warum bei manchen Messungen Größe so und so und bei anderen völlig andere Größen des WBC fixer sind...
 
Ja aber was sollte da technisch dagegen sprechen das auch mit HDDs zu machen?
Rein von der Warte her ist das ja zumindest bei einigen Systemen durchaus gängige Praxis schnelle SAS Platten mit langsamen Platten zu kombinieren... Da gibts schon ein paar Hersteller die sowas intelligent nutzen. Mit den Storage Spaces will ja MS auch dort ansetzen. Nur spricht man eben häufiger bzw. fast ausschließlich von SSDs in Verbindung mit HDDs anstatt von schnellen und langsamen Platten oder gar nem Tripplegespann aus allein dreien.
Technisch spricht dagegen nichts. Nur ist merkwürdig warum MS standardmäßig den Cache bei HDDs jedweder Art auf 32MB beschränkt. Jemand der per GUI dann den SS erstellt, hat dann automatisch immer mit der langsamen Schreibgeschwindigkeit im Parity zu kämpfen.

Was die reine Cachegröße angeht, ggf. tritt da ein Umstand in Kraft, den ich bspw. von NetApp Systemen kenne. Dort wird bspw. der Cache entweder dann geleert und auf die Platten geschrieben, wenn er A) voll ist bzw. fast voll ist, oder B) wenn eine bestimmte Zeit verstrichen ist. Könnte bei MS ggf. ähnlich laufen... Sprich zu großer Cache würde dann bedeuten, dass man gar nicht umhin kommt, diesen völlig zu befüllen... Irgendwo sollte es, sofern diese Theorie stimmt, einen Break Even Point geben, wo der Speed dann wieder sinkt... Das ganze müsste rein von der Theorie her stark davon abhängen, wie das Plattensystem dahinter agiert. Was auch erklären würde, warum bei manchen Messungen Größe so und so und bei anderen völlig andere Größen des WBC fixer sind...
Hmm ja, da könntest du durchaus Recht haben. Ist aber trotzdem alles nur Spekulation solange da keine ordentliche Dokumentation seitens MS gemacht wird und bringt letzten Endes auch wenig, wenn man dann sein System nicht Voraus abschätzen kann.
 
Aus meiner Sicht ist das einzige halbwegs brauchbar ist aktuell dieses:

SS; 4x4TB SATA; Parity; WBC 32MB (Default); => Capacity 10,9TB

da hier nichts ungewöhnlich einzubrechen scheint o.ä. und es vermutlich auch halbwegs sicher ist, mal abgesehen von Problemen die SS vielleicht noch allgemein hat.

nur finde ich 40-50MB/s schreiben nicht so berauschend.

Wenn ihr noch weitere Ideen zu SS habt teste ich es gerne da mir die Konstellation so aktuell gar nicht schmeckt.

Auch interessant fände ich was die besten alternativen wären die man jetzt mal dagegen halten müsste ZFS, Hardware RAID, alternative Software-RAID Windows Lösungen etc.. Ob ich alle Szenarien gut bei mir testen kann weis ich nicht aber versuchen kann ich es Ja.
 
Muss dir da zustimmen Simon. Ich würde auch möglichst auf default fahren, da das immernoch das zuverlässigste und sicherste System ist. Leider gibts zu Storage Spaces keine richtige Alternative, die die Funktionen genauso nur mit besserer Schreibgeschwindigkeit ersetzen kann - zumindest nicht unter Windows.
HW-Raid ist heutzutage Schwachsinn, da fehleranfällig, treiberabhängig, unflexibel, teuer und mit hohem Stromverbrauch.
Die besten Alternativen wirst du wohl nur bei Linux finden. Allerdings dann wieder nicht mehr so einfach einzurichten wie SS.

Sollte man wirklich aktuell auf SS angewiesen sein und nicht mehr auf evtl. Updates mit Win 10 warten, dann bliebe eigtl. nur, 2 Volumes zu erstellen: Eins mit Parity für das Datengrab, das keine großen Änderungen mehr erfährt und eins mit Mirror für schnelle Lese und Schreibzugriffe.

Das ist ja auch das, was mich so maßlos ärgert. SS hätte das Potential, grandios zu werden, geht aber unter in den ganzen Kachel- und Metrodiskussionen, die sonst die Berichterstattung von Win 8 dominieren.
 
sorry, dass ich den Thead noch mal ausgrabe. Aber das Thema ist ja eigentlich noch aktuell.

Ich komm mit den Powershellbefehlen gerade noch gar nicht zurecht.
Kann mir einer kurz mit den Befehlen helfen.

Setup: 5x3tb +100gb SSD.

Ziel: RAID 5 nur über die HDDs und die gesamte SSD nur als WBC.

Über Sinn oder Unsinn entscheide ich dann selbst, wenn ich es getestet hab.

Danke.
 
sorry, dass ich den Thead noch mal ausgrabe. Aber das Thema ist ja eigentlich noch aktuell.

Ich komm mit den Powershellbefehlen gerade noch gar nicht zurecht.
Kann mir einer kurz mit den Befehlen helfen.

Setup: 5x3tb +100gb SSD.

Ziel: RAID 5 nur über die HDDs und die gesamte SSD nur als WBC.

Über Sinn oder Unsinn entscheide ich dann selbst, wenn ich es getestet hab.

Danke.

Gibt es hier Neuigkeiten.

Auch generell zu dem Thema?
 
Ich versteh die Sache jetzt auch nicht mehr. Ich hab den Gen10 mit 3 x WD Red 8 TB und einer 860 Evo SSD als OS-Drive. Ich habe heute ein Samsung Evo 960 M.2 nachgebaut und versuche seit Stunden, das irgendwie zu nutzen. Mit PS habe ich es geschafft, die WD's auf "Verwendung: Automatisch" umzustellen, trotzdem erlaubt mit die Server-Manager UI nicht, eine Parity-VHD zu erstellen. Ich möchte die drei WD's als Parity anlegen und die M.2 als Write Back Cache UND Hot/Cold-Drive (hat immerhin 256 GB, das sollte doch reichen). Aber in der Auswahl beim Anlegen der VHD steht nur "Simple" und "Mirror".

Muss ich tatsächlich eine zweite M.2 einbauen damit Spaces es erlaubt, eine Parity aus den 3 WDs zu erstellen und mit den 2 M.2s zu beschleunigen?
 
Gib doch bitte Mal deine powershell Befehle an. Dann kann man gucken, wo es klemmt.

Gesendet von meinem XT1635-02 mit Tapatalk
 
Soweit ich weiß, geht Parity nur ohne oder mit mindestens zwei Cache Platten. Der Cache ist von der Ausfallsicherheit gleichzustellen mit den Datenplatten. D.h. der Ausfall einer Cacheplatte ist gleichzusetzen mit Datenverlust.
Wieso Mirror dann geht, entzieht sich meiner Kenntnis.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh