RST Raid

ghostadmin

Grand Admiral Special
Mitglied seit
11.11.2001
Beiträge
25.179
Renomée
184
Standort
Dahoam Studios
Mir ist aufgefallen das die Intel Raid Controller die es Onboard gibt, nicht grade viele Optionen bieten. Da gibts nur Write back oder Write through. Der Cache im Laufwerk ist immer an, ist das nicht böse bei Stromausfall? Bei Server SSD gibts ja Powerloss Protection aber bei einer normalen HDD?

Von früher weiß ich nur das man Write back nur einschalten soll bei Batterie gepufferten Cache im Controller. Diese Hardware RAID Controller haben den Cache im Laufwerk wohl auch immer deaktiviert. Aber nicht im Intel RAID.

Bei einer SSD ist der Cache im Controller aber nicht mehr so wichtig und in vielen Fällen zu langsam.
 
Da gibts nur Write back oder Write through.
Welche Option hast Du denn noch erwartet?
Der Cache im Laufwerk ist immer an, ist das nicht böse bei Stromausfall?
Ja, kann es sein, aber NTFS hat ja immerhin Journaling, wenn auch nur für die Metadaten. Bei unerwarteten Spannungsabfälle ist immer mit Datenverlust zu rechnen, wer diese vermeiden will, verwendet eine USV und wer auch das Risiko bei Ausfall des Netzteils mindern will, eben zwei USVs und ein redundantes Netzteile sowie einen HW RAID Controller mit BBU, nur kostet dies eben und daher macht man sowas nicht in jedem Deskop, sondern i.d.R. nur in Servern und da nutzt man eben nicht die Chipsatz RAIDs. 100%ig Sicherheit gibt es nie, aber je näher man an die 100% zu kommen versucht, umso teurer wird es eben und Chipsatz RAIDs sind eben die Low-Budget Lösung.
Bei Server SSD gibts ja Powerloss Protection aber bei einer normalen HDD?
Nein, ich kenne zumindest keine HDDs die sowas hätte, dafür haben die RAID Controller ja eine BBUs und schalten den Schreibcache der Platte ab, damit weiß der Controller dann auch, dass die Daten auf dem Medium stehen, wenn die HDD das Schreiben quittiert hat und kann die Daten dann aus seinem Cache entfernen. Fällt der Strom aus bevor die Platte den Schreibvorgang bestätigt hat, kann dieser später wiederholt werden, die Daten stehen dann ja noch im Cache dessen Inhalt von der BBU vor Verlust geschützt wird.
Von früher weiß ich nur das man Write back nur einschalten soll bei Batterie gepufferten Cache im Controller.
Eben genau darum, denn sonst bekommt das Programm vom RAID Controller die Bestätigung das die Daten geschrieben wurden, obwohl sie in Wahrheit nur in Cache des RAID Controllers stehen, dies wird auch als sync Faking bezeichnet. Dies ist auch legitim, wenn eben sichergestellt ist, dass die Daten auch bei einem unerwarteten Spannungsverlust nicht verloren gehen, wie es eben bei einer BBU oder auch bei Enterprise SSDs mit Full-Power-Loss-Protection der Fall ist. Es gibt ja auch SSD bei denen die Power-Loss-Protection nur Data-at-rest schützt, nicht aber die Userdaten im Schreibcache, dies sind die sogenannten Client Lösungen.
Diese Hardware RAID Controller haben den Cache im Laufwerk wohl auch immer deaktiviert. Aber nicht im Intel RAID.
Kann man dies nicht über die normale Windowseinstellung zu den Laufwerken machen?
Bei einer SSD ist der Cache im Controller aber nicht mehr so wichtig und in vielen Fällen zu langsam.
Das Gegenteil ist der Fall, bei SSDs ist es extrem wichtig das der Cache aktiv ist, sonst brecht die Schreibperformance ein, ganz besonders bei kurzen zufälligen Schreibzugriffen, außer natürlich die SSD betreibt Sync-Faking, was z.B. die mit Sandforce Controller i.d.R. machen auch ohne Power-Loss-Protection zu haben, andere vermutlich auch und natürlich alle Enterprise SSDs mit Full-Power-Loss-Protection sowieso.

Wie sehr die Schreibwerte leiden, sah man gut bei den NVMe SSDs mit dem Microsoft stornvme Treiber, der hatte früher (inzwischen sollte es behoben sein) auch bei Setzen es oberen Haken FUA Schreibbefehle verwendet und die zwingen die NVMe SSD die Daten direkt auf das Meium zu schrieben, ohne den Cache zu nutzen und damit können eben nicht Daten aus mehreren Befehlen gesammelt und zusammen aufs NAND geschrieben werden und schon schreibt so eine SSD bei 4k nur noch mit 3 oder 4MB/s, statt oft über 100MB/s.
 
Welche Option hast Du denn noch erwartet?

Na eben Cache komplett deaktivieren und individuell Controller/Laufwerk

Ja, kann es sein, aber NTFS hat ja immerhin Journaling, wenn auch nur für die Metadaten. Bei unerwarteten Spannungsabfälle ist immer mit Datenverlust zu rechnen, wer diese vermeiden will, verwendet eine USV und wer auch das Risiko bei Ausfall des Netzteils mindern will, eben zwei USVs und ein redundantes Netzteile sowie einen HW RAID Controller mit BBU, nur kostet dies eben und daher macht man sowas nicht in jedem Deskop, sondern i.d.R. nur in Servern und da nutzt man eben nicht die Chipsatz RAIDs. 100%ig Sicherheit gibt es nie, aber je näher man an die 100% zu kommen versucht, umso teurer wird es eben und Chipsatz RAIDs sind eben die Low-Budget Lösung.

Ich hatte mich aus diesem Grund für SSD mit Powerloss entschieden. Aber was ist nun wenn man dort noch zusätzlich z.b. eine HDD betreibt? Diese hat ja eben einen internen Schreibcache der betroffen ist.

Nein, ich kenne zumindest keine HDDs die sowas hätte, dafür haben die RAID Controller ja eine BBUs und schalten den Schreibcache der Platte ab, damit weiß der Controller dann auch, dass die Daten auf dem Medium stehen, wenn die HDD das Schreiben quittiert hat und kann die Daten dann aus seinem Cache entfernen. Fällt der Strom aus bevor die Platte den Schreibvorgang bestätigt hat, kann dieser später wiederholt werden, die Daten stehen dann ja noch im Cache dessen Inhalt von der BBU vor Verlust geschützt wird.

Das ist klar aber was ist mit internen RAID Controllern ohne BBU

Eben genau darum, denn sonst bekommt das Programm vom RAID Controller die Bestätigung das die Daten geschrieben wurden, obwohl sie in Wahrheit nur in Cache des RAID Controllers stehen, dies wird auch als sync Faking bezeichnet. Dies ist auch legitim, wenn eben sichergestellt ist, dass die Daten auch bei einem unerwarteten Spannungsverlust nicht verloren gehen, wie es eben bei einer BBU oder auch bei Enterprise SSDs mit Full-Power-Loss-Protection der Fall ist. Es gibt ja auch SSD bei denen die Power-Loss-Protection nur Data-at-rest schützt, nicht aber die Userdaten im Schreibcache, dies sind die sogenannten Client Lösungen.
Kann man dies nicht über die normale Windowseinstellung zu den Laufwerken machen?

Angeblich soll die Write back/through Einstellung im Controller gleichzeitig die Option im Laufwerk abändern. Ich habe derzeit 2x D3-S4610 500GB für virtuelle Maschinen am RSTe hängen und bei Write Through ist die Performance ziemlich gut, also kann der interne Schreibcache der SSD gar nicht aus sein.
Dazu ist es noch Windows Server in der Core Variante, da gibt es keinen Gerätemanager. Und die Remoteverwaltung vom Gerätemanager funktioniert bei Windows auch nicht mehr.

Das Gegenteil ist der Fall, bei SSDs ist es extrem wichtig das der Cache aktiv ist, sonst brecht die Schreibperformance ein, ganz besonders bei kurzen zufälligen Schreibzugriffen, außer natürlich die SSD betreibt Sync-Faking, was z.B. die mit Sandforce Controller i.d.R. machen auch ohne Power-Loss-Protection zu haben, andere vermutlich auch und natürlich alle Enterprise SSDs mit Full-Power-Loss-Protection sowieso.

Der interne Cache in den Laufwerken ja, aber nicht der Cache im Controller. Bei einigen etwas älteren Controllern ist dieser sogar langsamer als die SSD, insbesondere bei IOPS.

Hier einige Links:
http://www.admin-magazine.com/Archive/2015/28/Tuning-SSD-RAID-for-optimal-performance/(offset)/6
https://www.heise.de/select/ix/2018/2/1517711476799852
https://notesbytom.wordpress.com/2016/10/21/dell-perc-megaraid-disk-cache-policy/

Wie sehr die Schreibwerte leiden, sah man gut bei den NVMe SSDs mit dem Microsoft stornvme Treiber, der hatte früher (inzwischen sollte es behoben sein) auch bei Setzen es oberen Haken FUA Schreibbefehle verwendet und die zwingen die NVMe SSD die Daten direkt auf das Meium zu schrieben, ohne den Cache zu nutzen und damit können eben nicht Daten aus mehreren Befehlen gesammelt und zusammen aufs NAND geschrieben werden und schon schreibt so eine SSD bei 4k nur noch mit 3 oder 4MB/s, statt oft über 100MB/s.

Ich hab da mal auf meinem PC mit ATTO und einer billigen Sandisk SSD Plus rumgespielt. Die Option bypass write cache im Programm bewirkt gar nichts. Wenn ich im Gerätemanager das flushing deaktiviere dann sind die Werte auch nicht großartig anders, erst wenn ich den Schreibcache im Laufwerk ausschalte sinken die Werte auf unzumutbare Werte. Wie das flushing performt hängt vermutlich vom Treiber ab. Ich dachte immer das diese SSD gar keinen Cache hätte, wie funktioniert das?

Mir stellt sich jetzt vor allem die Frage ob es überhaupt empfehlenswert ist, ein RST Raid mit 2x HDD im RAID1 zu betreiben wenn sich der interne Schreibcache der Festplatte nicht ausschalten lässt und selbst wenn man den ausschalten kann, ist die Performance übergrottig. Eine USV allein reicht auch nicht immer, so ein Netzteil kann auch mal Probleme machen oder was auch immer. Für ein normales Share mit Files, brauche ich aber eigentlich keine schnellen und teuren SSD aber Sicherheit. Das günstige was ich mit Powerloss Protection gefunden habe sind die Intel D3-S4510 1TB, die liegen fast 3x so hoch wie eine Festplatte mit 2TB z.B. WD RED. Ein extra Controller mit BBU für HDD lohnt sich auch nicht, da kann man gleich SSD nehmen. Man weiß ja auch nicht wie häufig dieser Cache geleert werden. Aber wenn da keine Datenbanken draufliegen und eben NTFS ein Journal hat, sollte das ganze doch eigentlich mit HDD oder mit Consumer SSD nicht so kritisch sein das es das ganze Laufwerk zerschießt.
 
Zuletzt bearbeitet:
Aber was ist nun wenn man dort noch zusätzlich z.b. eine HDD betreibt? Diese hat ja eben einen internen Schreibcache der betroffen ist.
Genau so ist es.
Das ist klar aber was ist mit internen RAID Controllern ohne BBU
Da sollte man nur Write Through benutzen, aber es gibt auch solche die Write Back ohne BBU erlauben, nur ist dann das Risiko von Datenverlust bei einem unerwarteten Spannungsabfall höher, weil 0 ist es ja sowieso nie.
Angeblich soll die Write back/through Einstellung im Controller gleichzeitig die Option im Laufwerk abändern.
Das dürfte vom Controller abhängen und ggf. auch der jeweiligen FW. Es macht natürlich Sinn bei Vorhandsein eine BBU in der Write Back Einstellung die Schreibcaches der Platte zu deaktivieren bzw. nach den Schreibvorgängen dann sync Befehle zu schocken oder eben entsprechende Schreibbefehle zu verwenden, bei denen die Platte angewiesen wird die Daten direkt auf das Medium zu schreiben.
Ich habe derzeit 2x D3-S4610 500GB für virtuelle Maschinen am RSTe hängen und bei Write Through ist die Performance ziemlich gut, also kann der interne Schreibcache der SSD gar nicht aus sein.
Das sind ja auch Enterprise SSDs mit Fill-Power-Loss-Protection und die machen wie schon gesagt eben auch sync-faking, ignorieren also die Aufforderung Daten auf das Medium zu schreiben und tun so als hätten sie es getan, obwohl die Daten noch im Schreibcache stehen. Da diese Daten ja nicht verloren gehen, ist dies bei denen ja auch kein Problem und Performance dieser SSDs ist mit wie ohne Aktivierung des Schreibcaches gleich gut. Die Performance des RAIDs wird bei Write Back wegen der Nutzung des Caches des Controllers natürlich anderes sein als bei Write Through.
Dazu ist es noch Windows Server
Mit Windows Server kenne ich mich nicht und ich kann auch Windows nicht als ein Serverbetriebssystem ansehen.
Der interne Cache in den Laufwerken ja, aber nicht der Cache im Controller. Bei einigen etwas älteren Controllern ist dieser sogar langsamer als die SSD, insbesondere bei IOPS.
Ja, diese alten RAID Controller haben ja auch nur lahme CPU wie solche auf Basis von PowerPC mit vielleicht einem GHz. Die sind eben auf HDDs und deren lange Zugriffszeiten optimiert und für SSDs zu lahm. Daher sind solche HW RAID Controller auch am Aussterben, für SSDs nimmt man lieber SW RAIDs, denn die CPUs haben viel mehr Resorucen als man sinnvollerweise auf einem HW RAID Controller verbauen will.
Ich hab da mal auf meinem PC mit ATTO und einer billigen Sandisk SSD Plus rumgespielt. Die Option bypass write cache im Programm bewirkt gar nichts
Keine Ahnung ob die SanDisk Plus Sync-Faking betreibt, aber wenn, dann solltest Du sie mit dem AS-SSD benchen, denn ich denke nicht, dass ATTO überhaupt sync Befehle schickt und da es eine DRAM less SSD ist, ist sie sowieso lahm.
Wenn ich im Gerätemanager das flushing deaktiviere dann sind die Werte auch nicht großartig anders, erst wenn ich den Schreibcache im Laufwerk ausschalte sinken die Werte auf unzumutbare Werte.
Keine Ahnung was das mit dem Flusching für eine Einstellung ist, ich kenne nur die zum Schreibcache und da werden die SSDs ohne sync Faking eben sehr lahm, wenn man den oberen Haken entfernt.
dachte immer das diese SSD gar keinen Cache hätte, wie funktioniert das?
Die SanDisk Plus haben zwar keine DRAM Cache, aber der Controller hat ein internes SRAM und cacht dort einen Teil der Mappingtabelle und eben auch einige Userdaten. Aber auch die SSD Controller mit DRAM Cache, cachen dort ja nicht die Userdaten, sondern ihre Verwaltungsdaten, vor allem eben die Mappingtabelle, also den Flash Translation Layer (FTL) wo eben drin steht wie die Daten welcher logischen Adresse im NAND stehen und welche NAND Pages frei sind.
Mir stellt sich jetzt vor allem die Frage ob es überhaupt empfehlenswert ist, ein RST Raid mit 2x HDD im RAID1 zu betreiben wenn sich der interne Schreibcache der Festplatte nicht ausschalten lässt und selbst wenn man den ausschalten kann, ist die Performance übergrottig.
Bei HDDs hat der Schreibcache nicht so einen großen Einfluss auf die Performance wie bei SSDs ohne sync-Faking. Die Ergebnisse aus den Tests mit den SSD, sowohl mit der SanDisk Plus also auch erst recht mit der Intel SSD D3-S4610, die das hat, was Intel "Enhanced Power Loss Data Protection" nennt.

Eine USV allein reicht auch nicht immer
...
Ein extra Controller mit BBU für HDD lohnt sich auch nicht
Wie gesagt ist Sicherheit immer auch eine Frage des Preises und mehr Sicherheit kostet mehr. Jeder muss selbst entscheiden wie viel Sicherheit ihm welchen Preis wert ist. Generell würde ich beim Heimserver vor allem auf das Backup vertrauen, dies schützt gegen sehr viele Risiken und beim Heimserver sind meistens weder hohe Performance noch Verfügbarkeit nötig.
 
Da gehts um etwas mehr als nur Heimserver aber das Budget ist überall knapp in der heutigen Cloudwelt.
Samsung hat in den Consumerdisks wohl ein Journal
https://insights.samsung.com/2016/0...ds-are-protecting-data-integrity-white-paper/
Da steht eben u.a. auch das es generell nichts neues ist und auch bei HDD wegen deren DRAM Cache auftritt (die ja eben überhaupt keinen Schutz bieten).

Crucial hat seine Consumerdisks mit Powerloss Immunity für data-at-rest protection ausgestattet
https://www.micron.com/~/media/docu.../ssd_power_loss_protection_white_paper_lo.pdf
Nicht vollwertig aber aber vermutlich besser als nichts.

siehe auch Typen von Kondensatoren:
https://www.elektroniknet.de/design-elektronik/power/back-up-power-fuer-ssds-155252.html

Wenn also diese Multicell SSD Chips so extrem auf SLC Cache angewiesen sind um die Performance und Verschleiss zu verbessern*, hört sich das erstmal so als ob diese noch gefährlicher als normale HDDs sind. Inwieweit man da mit z.B. einer MX500 oder 860 Evo vor Datenkorruption geschützt ist, ist für den Verbraucher überhaupt nicht feststellbar.

Bei Intel ist selbst bei den DC nur ein ganz billiger Elko verbaut:
https://www.intel.com/content/dam/w...-imminent-technology-brief.pdf?language=en_US
Bei der aktuellen S4610 sinds immerhin mehrere aber im Vergleich zu anderen DC SSD ist das ja armseelig:
Intel-SSD-D3-S4610-480GB-03.png

So ein Elko hat ja auch nicht gerade die riesen Lebensdauer.

* https://blogs.technet.microsoft.com/filecab/2016/11/18/dont-do-it-consumer-ssd/
 
Samsung hat in den Consumerdisks wohl ein Journal
Auch die Samsung Consumer SSD sind schon lange als recht robust gegenüber unerwarteten Spannungsabfälle und dies eben nur auf Basis der FW, die eben Technologien wie bei Journaling Filesystemen.Dies schützt aber eben nicht die Userdaten im Schreibcache.
Das ist die schon von mir erwähnte Client Lösung die nur Data-at-rest schützt, nicht aber die Userdaten im Schreibcache und die Crucial ab er M500 bei allen Modellen mit Marvell Controllern eingebaut hat. Die Vorgänger C300 und m4 waren nämlich sehr anfällig bzgl. unerwarteten Spannungsabfälle und daher hat Micron damals schon bei der m4 zu dem Trick gegriffen, dass die LBAs nicht nur in der Mappingstabelle stehen, sondern auch noch einmal zusammen mit den Daten im normalen NAND Bereich, die NANDs haben ja ein paar zusätzliche Byte pro Page für die ECC und eben solche zusätzlichen Informationen. Bei der m4 Power Cycle Wiederbelebung wird der Controller getriggert die durch den unerwarteten Spannungsabfall korrupte Mappingtabelle anhand dieser Daten zu rekonstruieren, was natürlich eine Weile dauert und daher nicht einfach so beim Booten gemacht wird. Wie die Praxis zeigt, hat diese auch bei den Nachfolgern wie der M500 bis zu MX300 immer mal wieder funktioniert, was bedeutet, dass die Kapazität von denen Kondensatoren nicht immer ausreichend war um eine Korruption Mappingtabelle bei unerwarteten Spannungsabfällen zu verhindern.

Inzwischen setzt Crucial nur noch auf SMI Controller und bewirbt dort nur noch den schlauen Algorithmus in der FW als Power Loss Technologie, denn die Crucial mit SMI haben allesamt keine Stützkondensatoren.
Wenn also diese Multicell SSD Chips so extrem auf SLC Cache angewiesen sind um die Performance und Verschleiss zu verbessern*, hört sich das erstmal so als ob diese noch gefährlicher als normale HDDs sind.
ja bei MLC (oder TLC oder QLC, was ja beides auch unter MLC fällt) kann es zu Low-Page-Corruption kommen, aber es hängt auch wieder vom Algorithmus in der FW ab ob dies praktisch zu Korruption anderer Daten führt, die schon vor längerer Zeit in diese Low Page geschrieben wurden. Wenn das Budget aber schon so ein knapp ist, dass Consumerhardware verwendet werden soll, dann reicht es ganz sicher nicht für SLC SSDs, die gibt es auch kaum noch, spontan fallen mir da nämlich nur die Z-SSDs von Samsung und eben die Intel Optane ein, denn das 3D XPoint ist auch SLC, es speichert bisher auch nur ein Bit pro "Zelle".
Inwieweit man da mit z.B. einer MX500 oder 860 Evo vor Datenkorruption geschützt ist, ist für den Verbraucher überhaupt nicht feststellbar.
So ist es. Aber es ist ja auch nur eine Consumer Client SSD und bei Consumerhardware ist der Preis wichtiger als der Schutz der Daten vor Korruption, sonst hätte jeder Consumer PC ja auch ECC RAM. Bei Consumer Hardware reicht es eben, wenn es meistens bei den meisten Leuten korrekt funktioniert, was ja auch bei RAM ohne ECC der Fall ist und wenn man mehr Sicherheit möchte, muss man eben entsprechend mehr Geld ausgeben, wo der normale private PC Käufer aber eben nicht bereit ist. Wenn man damit auch bei Enterpriseanwendungen zufrieden ist, dann bitte, aber da bei Enterpriseanwendungen Probleme und Fehler wie korrupte Daten richtig ins Geld gehen können, sind die meisten Enterpriseanwender eben auch bereit mehr Geld für passende Enterprisehardware auszugeben.

Gerade bei SSDs haben die richtigen Enterprise Datacenter SSDs eben zwei wichtige Features die für mehr Sicherheit vor Datenkorruption sorgen, die Full-Power-Loss-Protection und die Internal-Data-Path-Protection. Es gibt auch Anbieter die SSDs ohne diese Features als Enterprise anbieten, wo solchen lässt der kundige Einkäufer dann aber die Finger. Die Full-Power-Loss-Protection bringt wie schon gesagt wegen dem sync-Faking dann gegenüber den Consumer SSDs auch noch deutliche Performancevorteile, wenn sie an einem Enterprise RAID Controller betrieben werden, der den Schreibcache der Laufwerke deaktiviert. Man sollte eben nicht Consumer Hardware mit Enterprise Hardware mischen, zumal wenn man nicht genau weiß was man macht!
Bei Intel ist selbst bei den DC nur ein ganz billiger Elko verbaut
Wie teuer diese Elkos sind, weiß ich nicht, aber wichtiger als der Preis ist die Kapazität. Bei Intel gibt es i.d.R. eine Einkerbung in der Seite der Platine und da sitzen dann ein paar wenige runde Elkos, während andere Hersteller lieber viele SMD Kondensatoren auf die Platine löten und dann für ausreichende Kapazitäten die teuren Tantalkondensatoren nehmen müssen, weil für die anderen nicht genug Platz auf der Platine wäre. Beide Ansätze haben Vor- und auch Nachteile, bei viele Kondensatoren ist die Wahrscheinlichkeit das einer kaputt geht, natürlich größer.
Bei der aktuellen S4610 sinds immerhin mehrere aber im Vergleich zu anderen DC SSD ist das ja armseelig:
Wie viel Kapazität die Stützkondensatoren haben müssen, hängt von vielen Faktoren ab, neben der Leistungsaufnahme des Controllers und der NANDs, auch von der Größe des Caches für Userdaten. Bei mehr Kapazität ist die Mappingtabelle größer und bei NANDs mit mehr bpc braucht man ebenso mehr Strom um die Data-at-rest zu sichern. Aber ich zähle da 5 Elkos, was ich im Vergleich zur DC S3700 nicht als armseelig bezeichnen würde, die hatte nämlich nur zwei:



So ein Elko hat ja auch nicht gerade die riesen Lebensdauer.
Nichts hat eine ewige Lebensdauer, aber wie viel Kapazität ein Elko verliert, (dies hängt auch sehr von den Temperaturen ab) und sie sollten natürlich so ausgelegt sein, dass die Kapazität auch am Ende der vom Hersteller geplanten Nutzungsdauer noch ausreichend ist. Außer besonderer Hardware für Extended Lifecycle, wie Embedded, Industrial, Automotiv etc. sind dies üblicherweise 5 Jahre. Deshalb bekommt man vom Hersteller ja auch keine länger laufenden Serviceverträge.
 
zu allem Überfluss tauchen auch noch stordiag Fehler auf (504/509 hauptsächlich) und zwar auf beiden RAID1 Arrays. Die sind auch etwas versteckt d.h. nicht unter System sondern da muss man erstmal unter Anwendungs- und Dienstprotokolle in den entsprechenden Ordner schauen.
Auf meinem PC sehe ich da allerdings auch Fehler...
 
Dann poste doch mal die Screenshot von CrystalDiskInfo für die SSD im RAID, ziehe aber bitte das Fenster soweit auf, dass alle Attribute und auch die Rohwerte vollständig sichtbar sind, also keine Scrollbalken mehr erscheinen. Beim Intel Chipsatz RAID sollten sie dort erscheinen, bei Hardware RAIDs müsstest Du das Tool des RAID Controller Herstellers nehmen um die S.M.A.R.T. Werte auszulesen.
 
Das sind keine Smart Fehler sondern taucht in den Windows Logs auf. Anscheinend ist das aber "normal" weil ich das auf jedem Windows 10 PC auch so sehe.
 
Frage mich grade wie das beim Microsemi 8405E ist, ob der den Disk Cache deaktiviert.

Wenn das so ist wie bei den alten:
https://www.thomas-krenn.com/de/wiki/Adaptec_Controller_per_Raid_Bios_verwalten
Da ist der Disk Cache default immer aktiv. Was nützt dann der batteriegepufferte Cache im Controller wenn der Cache von der Disk beim stromausfall weg ist? Also speziell bei normalen HDDs und Consumer SSDs.
Der hier sagt ja man soll Disk Cache immer ausschalten:
https://notesbytom.wordpress.com/2016/10/21/dell-perc-megaraid-disk-cache-policy/

Nur bei SSD dürfte das dann eben seeeehr langsam werden. Konnte aber nichts dazu finden wie sich das genau auf die Performance bei SSD auswirkt ohne drive cache.

Als Zusammenfassung verstehe ich das jetzt so:

1) RAID Controller ohne BBU
- mit SSD: gute Performance, write through im controller und möglichst nur SSD mit poweloss protection verwenden da diese sonst zu langsam werden wenn man Disk Cache ausschaltet
- mit HDD: write through und ohne disk cache, wegen ersterem sehr schlechte Performance also nicht zu empfehlen

2) RAID Controller mit BBU
- mit SSD: bessere Performance mit write through weil der Controller unnötig IO Last bzw. Verzögerungen produziert und nur lineare Schreiblasten vom Cache profitieren würden aber auch SSD mit PLP sinnvoll. Ausnahme ist wohl RAID5/6 wo die Latenz mit write back sinkt weil der Controller nicht sofort die Parität berechnen muss. Also lohnt dann bei DB aber da hat man wohl eher kein RAID5 oder 6.
- mit HDD: write back und ohne disk cache, gute Performance weil Platten auf den Cache vom Controller angewiesen sind und der Cache in der Disk bringt nicht viel

Und Read Policy wohl generell immer ohne Read ahead

Was mir jetzt auch aufgefallen ist, der RST Controller steht bei controller cache default auf disable d.h. nicht mal write through ist aktiv. Da ist ja auch gar kein RAM da...
 
Zuletzt bearbeitet:
Was nützt dann der batteriegepufferte Cache im Controller wenn der Cache von der Disk beim stromausfall weg ist? Also speziell bei normalen HDDs und Consumer SSDs.
Nichts, weshalb üblicherweise auch immer der Schreibcache der Disks abgeschaltet wird, wenn der Cache des Controller mit BBU aktiv ist und wenn keine BBU vorhanden ist, sollte man den Cache des Controller eigentlich auch nicht aktivieren bzw. sollte er per Default nicht aktiv sein.
Dies bezieht sich soweit ich beim querlesen gesehen habe, aber nur auf HDDs.
Nur bei SSD dürfte das dann eben seeeehr langsam werden. Konnte aber nichts dazu finden wie sich das genau auf die Performance bei SSD auswirkt ohne drive cache.
Eben, die Consumer SSDs werden ohne ihren eigenen Schreibcache i.d.R. sehr lahm, bei 4k QD1 Schreibend gerne im unteren einstelligen MB/s Bereich, denn NAND ist eben lahm und die 100 bis teils fast 200NB/s bei 4k QD1 Schreibend kommen nur von ihrem Schreibcache, in dem die Daten gesammelt und dann gemeinsam ins NAND geschrieben werden. Deshalb sollte man an solchen Controllern unbedingt Enterprise SSDs mit Full-Power-Loss-Protection verwenden, die nutzen ihren Schreibcache immer, denn im Notfall können sie ja die Daten darin immer noch auf das NAND schreiben. Oder man verzichtet auf die Sicherheit im Fall eines unerwarteten Spannungsabfalls und nimmt entweder Consumer SSDs die sich nicht um die Einstellung scheren, die damals die mit Sandforce Controllern oder lässt den Schreibcache der SSD eben aktiviert, sofern diese Einstellung möglich ist.

Generell sind so alte HW RAID Controller eher eine Bremse für SSDs, die Controller sind einfach zu lahm und brauchen im Verhältnis zu Zugriffszeit der SSD viel zu lange um ihren Cache zu verwalten, also zu prüfen ob die Daten schon im Cache stehen oder doch von der Platte gelesen werden müssen. Die HW RAID Controller sind deswegen auch vom Aussterben bedroht und die meisten Hersteller wurden an große Konzerne verkauft, schau Dir mal an was es in der Branche in den letzten Jahren für Übernahmen gab.
 
Interessant ist auch der Mischbetrieb von SSD und HDD Sets auf einem Controller z.B. ein SSD RAID für schnelle Daten und ein anderes mit HDD für z.B. Fileserver. Dann müsste man wohl wieder zum Controller mit BBU greifen wegen den HDD und der sollte dann wegen den SSD auch nicht zu langsam sein.

Und ist es dann bei SSD Betrieb in RAID1 auch egal ob der Controller sogar ohne Cache ist. Es gäbe ja z.b. den Supermicro 3008 ohne Cache während der Microsemi 8405E 512MB hat aber eben auch ohne Write back.
 
Zuletzt bearbeitet:
Zurück
Oben Unten