Firmware gegen Bluescreens: SSDs von Western Digital haben Probleme unter Windows 11 24H2

Thread Starter
Mitglied seit
06.03.2017
Beiträge
113.744
Das diesjährige Windows-11-Update macht rein von der Build-Nummer 22631 (23H2) auf 26100 (24H2) einen großen Sprung nach vorne und inzwischen wurde das 24H2-Update auch bereits für alle Anwender in Form von ISO-Images freigegeben. Gleich fünf SSD-Serien von Western Digital haben mit dem neuen Windows-11-Update große Probleme, sodass das Betriebssystem mit einem Bluescreen abstürzen kann. Der Grund hierfür liegt beim Host Memory Buffer (kurz: HMB), dessen Zuweisung mit dem 24H2-Update geändert wurde. Doch zum Glück gibt es bereits Firmware-Updates, die dieses Problem aus der Welt schaffen.
... weiterlesen
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
HMB haben mittlerweile viele SSDs, aber nur ein paar WD sind betroffen?
 
Wenigstens gibt es eine schnelle Lösung. Ich frage mich nur, wie das passieren konnte. Hat sich WD sich nicht an den Richtlinien gehalten, oder lag es an Microsoft? Ich meine, es gibt Standards, die eingehalten werden müssen. Wenn jeder sein Süppchen kocht, dann ist Instabilität vorprogrammiert und frustriert nur. Wenn ich meine Arbeit schlampig machen würde, dann war es mit meinem Job. Das ärgert mich, weil bei jeder Installation von Patches/Updates immer die Angst mitschwingt, dass das System nicht richtig hochfährt oder gar abstürzt. Das darf einem standardisiertem, ins Detail vorgegebene System nicht passieren. Es kann nicht sein, dass ich im Vorfeld bei großen Updates eine Sicherungskopie oder Wiederherstellungsimage machen muss und bei evtl. Wiederherstellung unnötig Zeit verbrate. Ich bin immer noch dafür, dass Windows umsonst sein muss, weil es unfertig auf dem Markt kommt und ständig wegen irgendwas gepatcht werden muss. Der Spruch "never change a running system" kommt nicht von ungefähr.
 
Ich hab das Update erstmal für 4 Wochen pausiert - kein Bock auf Beta-Tester...

Ich hab allerdings WD Black SN850 - wußte garnicht das es die auch als "Blue" gibt...
 
Ich frage mich nur, wie das passieren konnte. Hat sich WD sich nicht an den Richtlinien gehalten, oder lag es an Microsoft?
Laut golem ist wohl folgendes passiert:
Dies klingt jetzt erstmal, als wäre MS schuld, wie können sie einfach mehr als 64MB erlauben, aber tatsächlich sieht meines Wissens nach die Spezifikation kein Limit von 64MB vor, dies war einfach so der übliche Höchstwert den die Betriebssystem für HMB erlaubt haben. SSDs die HMB nutzen, identifizieren dafür zwei Werte, einen Mindestwert wie viel sie mindestens haben wollen und einen Optimalwert, wie viel sie am liebsten hätten. Der Host (also hier Windows) entscheidet dann ob er einen HMB mit einer Größe im Bereich dieser beiden Werte anbietet oder gar keinen HMB zuteilt.

Mit diesem Wissen wird dann klar, dass WD hier die Schuld hatte, die haben offenbar einen Bug in ihrer FW gehabt der dazu geführt hat, dass die SSD mehr als 64MB HMB als Optimalwert angefordert hat, dann aber offenbar nicht mit so viel HMB umgehen konnte, vermutlich weil sie das beim Testen nie testen konnten, da ja vor 24H2 alle Betriebssystem maximal 64MB HMB zugewiesen haben.
Ich hab allerdings WD Black SN850 - wußte garnicht das es die auch als "Blue" gibt...
Die Blue wäre die SN580. Die SN850 und SN850X haben einen DRAM Cache und nutzen daher kein HMB, sind also von dem Problem nicht betroffen.
 
..der "Bug" ist kein Bug sondern einfach nur hausgemacht:

wd hmb-bug.png


Daher auch WD Firmware Refresh. Man sollte halt nicht mehr fordern wollen als das System vorgibt nur weil man denkt: Mehr würde mehr bringen. Bringt nur mehr Bugs. (y)

Abhilfe bringt da nur, reg DW auf 0 (aus) oder 3 (FW Setup) setzen.
 
Man sollte halt nicht mehr fordern wollen als das System vorgibt nur weil man denkt: Mehr würde mehr bringen.
Mehr würde schon mehr bringen, da man ja dann einen größeren Teil der Mappingtabelle dort unterbringen kann. Man sollte aber eben dann auch so viel HMB korrekt verwalten können, wenn man schon so viel anfragt. Man darf so viel anfragen wie man will, wenn man zu viel als Minimum anfordert, wird man am Ende keinen HMB bekommen und sonst bekommt man eben einen HMB dessen Größe Minimum Size oder Preferred Size oder irgendwas dazwischen ist und muss dann damit umgehen können. Die Fikwot macht es sich einfach, denn indem bei ihr der Minimum und der Preferred Size gleich sind, muss sie nur mit einem HMB von genau dieser Größe oder ganz ohne HMB arbeiten können, die WD muss dagegen mit einer ganzen Bandbreite unterschiedlicher HMB Größen umgehen können.
 
Nur zum Teil richtig.

WD hat selbst in umfangreichen HMB Workflow studies (RU 17) die L2P Tables bei 16MB mit 98,6% Adressierung abgedeckt.
100% wurden dabei schon mit 38MB erreicht die 40MB der Fikwot ist absolut deckend. Wenn WD da 200MB adressieren möchte ist das oversized^10 und sorgt nur für Troubles wie man sieht.

The results were quite intriguing. When as little as 16MB of host RAM was allocated as HMB,
the results showed that there was almost no impact on user experience. Specifically, for all
workloads tested, 95% of all activities experienced no loss of performance. Additionally, 98% of
most typical use cases such as installing software, copying files/folders, and general
productivity for office users had no performance degradation whatsoever.
 
Zuletzt bearbeitet:
Mal zum generellem Verständnis:
Wenn die (bis zu) 200MB im volatilem Ram zwischengespeichert werden, bevor sie auf die SSD geschrieben werden, sind die doch im Falle eines Stromausfalls weg und soo ein "Cache" ohne USV oder battery backup damit reichlich unklug?
 
Machen die ja nicht. Der Fix wird den HMB @ 64MB fixen und damit ist der Bug bereinigt.

HMB Cache ist auch kein DRAM Cache. HMB speichert die Mapping Table, DRAM dazu auch Nutzerdaten.
Worstcase kann man mit beiden Caches erreichen (Stromausfall). Passiert aber so gut wie nie.

The greatest utilization of host DRAM is to cache mapping information which often only requires tens of MBs of buffer size.
 
Zuletzt bearbeitet:
WD hat selbst in umfangreichen HMB Workflow studies (RU 17) die L2P Tables bei 16MB mit 98,6% Adressierung abgedeckt.
100% wurden dabei schon mit 38MB erreicht die 40MB der Fikwot ist absolut deckend.
Das habe ich hier gefunden, aber wie vermutet, bezieht es sich auf synthetische Benchmarks:

WD_HMB_Study.png


Bei mir läuft da aber eben einiges mehr, auch VMs und nicht nur eine und gerne auch eine mit einer Datenbank. Daher gibt es bei meiner SSD regelmäßig Zugriffe über einen viel größeren Adressraum als in diesen Benchmarks und idealerweise hat der DRAM Cache 1GB RAM pro 1TB Kapazität, so dass man mit 40MB HMB dann nur einen Adressraum von 40GB abdecken kann. Gibt es regelmäßig Zugriffe über einen größeren Adressraum, wird man den Nachteil des fehlenden DRAM Cache also auch bei der Fikwot merken. Den meisten Heimanwendern mag so eine DRAM lesss NVMe SSD mit HMB ja genügen, aber wer behauptet der HMB könnte einen DRAM Cache vollständig ersetzen, der ist einfach nur unehrlich.

Anandtech hat das damals bei der BG4 mit und ohne HMB ermittelt:

BG4_HMB.png


Wie man sieht, reicht der Adressraum für den die Mappingtabelle im internen SRAM des Controllers ausreicht, gerade mal 1GB, also gerade genug für Benchmarks wie AS-SSD oder CDM in deren Defaulteinstellung. Mit HMB reicht es für einen Adressraum von 32GB, also genug für über 95% der Zugriffe der meisten Benchmark wie sie auch WD genutzt hat. Danach fallen die IOPS aber eben massiv ab, weil dann die Cache das der passende Teil der Mappingtabelle im HMB steht, halt immer geringer wird und damit immer öfter erst aus dem NAND nachgeladen werden muss. Zum Vergleich eine 970EVO mit vollem DRAM Cache:

BG4_HMB_vs_970EVO.png


Hier es eine Linie, da eben die ganze Mappingtabelle im DRAM Cache steht und es daher keinen Unterschied macht, auf welche Adresse und damit auch über welchen Adressraum zugegriffen wird. Dies wird man mit HMB so nie erreichen, außer der HMB wäre eben auch so 1GB pro 1TB Kapazität groß.
Wenn die (bis zu) 200MB im volatilem Ram zwischengespeichert werden, bevor sie auf die SSD geschrieben werden
Im HMB wird nur ein kleiner Teil der Mappingtabelle gecacht, aber keine Userdaten und HMB wird auch nur als Lesecache für die Daten der Mappingtabelle verwendet. Bei Schreibzugriffen werden die Änderungen der Mappingtabelle direkt ins NAND geschrieben und dies ist auch bei den SSD mit DRAM Cache so üblich, außer wenn sie eine Full-Power-Loss Protection haben und damit diese Änderungen auch nach einen unerwarteten Spannungsabfällen noch ins NAND zurückschreiben können. Auch der DRAM Cache ist übrigens kein Schreibcache für Userdaten, die paar Userdaten die SSD im Schreibcache halten, meist nur bis es genug sind um eine ganze Page (meist so 16k oder 32k) vollständig beschreiben zu können, halten die Controller in aller Regel in ihrem internen SRAM.

Das war schon bei Intel X-25M so, der ersten modernen Consumer SSD mit DRAM Cache:
HMB Cache ist auch kein DRAM Cache.
Doch natürlich, denn es ist ein Teil des RAMs des Rechners und wer hat hier schon einen Rechner bei dem das RAM kein DRAM ist? Steht doch sogar in dem Zitat welches du unten in dem Beitrag gemacht hast: "The greatest utilization of host DRAM is to cache mapping information"

HMB speichert die Mapping Table, DRAM dazu auch Nutzerdaten.
Blödsinn, HMB kann nur einen kleinen Bruchteil der Mappigtabelle cachen und der DRAM Cache von SSDs ist nicht als Cache für Nutzerdaten da, anderes als bei HDDs, sondern damit der Controller eben da die Mappingtabelle cache kann. Deshalb ist die Größe des DRAM Cache ja in aller Regel auch proportional zur Kapazität, da die Größe der Mappingtabelle eben auch proportional zur Kapazität ist, wenn man die optimale Datenstruktur einer flachen Tabelle verwendet. Warum eine flache Tabelle optimal ist, wird deutlich wenn man hier liest wie es vorher gemacht wurde und auf der folgenden Seite den Hinweis: "the table itself should require roughly 100MB of DRAM per 100GB of storage space on the drive itself".

Wer also behauptet eine komplette Mappingtabelle würde in den HMB passen, der zeige bitte Belege dafür und ebenso wenn jemand behauptet, bei SSDs wäre der DRAM Cache für Userdaten zuständig! Außerdem sollte alleine die Tatsache das die NVMe SSDs entweder einen DRAM Cache oder eben HMB nutzen, doch schon deutlich darauf hinweisen, dass beide für die gleichen Daten genutzt werden, sonst würde es ja Sinn machen auch beides zu haben und nicht immer nur entweder oder!
 
Zuletzt bearbeitet:
HMB Preffered Size hat aber nur WD bei bestimmten HMB only Modellen falsch gesetzt und mit FW.-Fix nun "richtig" korrigiert:

wd forum.png


daher ja:
Machen die ja nicht. Der Fix wird den HMB @ 64MB fixen und damit ist der Bug bereinigt.

..alles andere was hier wieder themenabschweifend philosophiert ausgekaut wurde ist nur blabla..blabla..blabla.. :)


edit: und hier zu der 770 HMB nach FW.-Fix womit nun BSOD auch dort Geschichte ist:

4dc232b0cc8fb316f22c3ae75ac5a6262c0c603e.png
 
Zuletzt bearbeitet:
Wenigstens gibt es eine schnelle Lösung. Ich frage mich nur, wie das passieren konnte. Hat sich WD sich nicht an den Richtlinien gehalten, oder lag es an Microsoft?
Was ich mich frage ist, ob Mickeysoft sich nicht in einem der Keller 10 verschiedenste Desktops leisten kann wo sie testen was sie da tun. Und WD bescheid sagen kann, bevor sie mal wieder ein Update raushauen mit dem die Leute nur Probleme haben. Egal wer sich am Ende den Schuh anziehen muss.

Wenn WD SSDs so selten wären, wäre das erst zu Weihnachten so groß rausgekommen.
 
Zum Glück gibts solche Seiten! Bei mir ist ein PC "betroffen" (SN580), der zum Glück noch nicht das 24H2 bekommen hat. Wie überhaupt das Upgrade bislang auf keinem meiner Rechner angeboten wurde, obwohl es seit 1.10. draußen sein soll?

Firmware-Update lief ohne Probleme durch, Ich bin "safe"!
 
lt. Medien WD/Sandisk

habe außer zwei Samsung's auch zwei Crucial's verbaut und trotzdem diese Probleme
Was ich mich frage ist, ob Mickeysoft sich nicht in einem der Keller 10 verschiedenste Desktops leisten kann wo sie testen was sie da tun. Und WD bescheid sagen kann, bevor sie mal wieder ein Update raushauen mit dem die Leute nur Probleme haben. Egal wer sich am Ende den Schuh anziehen muss.

Wenn WD SSDs so selten wären, wäre das erst zu Weihnachten so groß rausgekommen.
... wenn einer mal an den Parametern herumschraubt oder vergisst .... :hust:
 
Kann man sich darauf verlassen, daß nicht genannte SSDs auch nicht betroffen sind?

Auf einem PC ist nämlich eine SN850 (mit SD-RAM-Cache) installiert, für die es laut dem WD-Tool auch ein Firmware-Update gibt. Allerdings wird der betreffende PC intensiv genutzt, so daß ich im Zweifelsfall da lieber kein Update der System-SSD machen möchte.
 
Zuletzt bearbeitet:
Sicher kann man sich nie sein, allerdings wäre dort schon sehr wahrscheinlich was publik gemacht worden.
Da es sich aber um einen "hausgemachten" only HMB-Bug handelt sind int_DRAM cached SSDs davon nicht betroffen.
Es gibt aber auch Fälle, wo die betroffenen Modelle sogar mit falscher HMB Zuweisung (200MB) laufen sollen.
Könte auch daran liegen, dass die User entweder HMB über Regedit (0) deaktiviert haben oder den DWord (3) geändert haben und es nicht mehr wissen.
Anders herum lese ich im WD Forum nun von Fällen, dass ein paar User nach FW.-Update zwar keine BSOD mehr bekommen dafür aber nun andere Bugs haben.
thats life. :sneaky:

nachtrag: Ich habe auch das 24er MS Update drauf und keine meiner only_HMB Mode SSDs (3 Riegel) hat diesen Bug da die HMB Settings passen.
Ich wüsste nun auch nicht was dagegen sprechen soll wenn die FW. HMB_min = HMB_max setzt. Funktioniert doch einwandfrei wie man sieht. (y)

Hat sich WD sich nicht an den Richtlinien gehalten, oder lag es an Microsoft?
Richtlinien gibt es für sowas nicht. Vieleicht wollte sich WD im Bereich HMB-Cached SSD nur kleine Wettbewerbsvorteile ermogeln und das ist in die Hose gegangen. :angel:
 
Zuletzt bearbeitet:
Kann man sich darauf verlassen, daß nicht genannte SSDs auch nicht betroffen sind?

Auf einem PC ist nämlich eine SN850 (mit SD-RAM-Cache) installiert, für die es laut dem WD-Tool auch ein Firmware-Update gibt. Allerdings wird der betreffende PC intensiv genutzt, so daß ich im Zweifelsfall da lieber kein Update der System-SSD machen möchte.
also das SN850 würde ich auf jeden Fall sofort machen, wenn die SSD in den Release Monaten gekauft wurde

E: Firmware 623000WD ist Pflicht, wenn man PCIe4 nutzt, weil sonst die Schreibgeschwindigkeit massiv einbrechen kann
 
Es gibt aber auch Fälle, wo die betroffenen Modelle sogar mit falscher HMB Zuweisung (200MB) laufen sollen.
Wo steht denn in der Spezifikation das 200MB nicht erlaubt und damit ein falscher Wert wären? Mir wäre nicht bekannt, dass dies gegen die Spezifikationen wäre. Aber WD hat natürlich den Fehler gemacht, so viel HMB anzufordern, aber dann kommt ihr Controller offenbar nicht damit klar auch so viel HMB korrekt zu verwalten. Sie hatten nun zwei Möglichkeiten das Problem zu lösen, entweder hätten sie den Bug behoben der dazu führt, dass die FW ein Problem mit so viel HMB hat, was sicher eine ganze Weile gedauert hätte, oder sie senken eben den Preferred Size auf die üblichen 64MB ab und dies Weg haben sie dann auch beschritten.

Wie ich schon schrieb:
Mit diesem Wissen wird dann klar, dass WD hier die Schuld hatte, die haben offenbar einen Bug in ihrer FW gehabt der dazu geführt hat, dass die SSD mehr als 64MB HMB als Optimalwert angefordert hat, dann aber offenbar nicht mit so viel HMB umgehen konnte
Wer meint es wäre nicht erlaubt überhaupt mehr als 64MB anzufordern, der zeige mir bitte wo dies in der Spezifikation steht! Die Spezifikationen lassen sich hier finden:

 
Wer hat denn was von "nicht erlaubt" geschrieben? :unsure: Falsch ist was anderes als nicht erlaubt.

Deiner Logik zufolge, die ich aber so nicht teile, würde eine Adressierung der Mappingtable über 200MB im Schreibzugriff für eine länger höhere IOPS Leistung sorgen.
Mag ja sein das dem theoretisch so sein "könnte", dass hat sich vieleicht auch WD so gedacht, sich einen Wettbewerbsvorteil erhofft und bei den hier erwähnten Modellen mal so "probiert"..

..ging aber leider gründlich in die Hose weil so einfach das dann doch nicht funktioniert und die User welche das mit BSOD's und OS Neuinstallation nun ausbaden dürfen werden sicher hoch erfreut darüber sein. (y)

Gegenfrage: Glaubst du nicht auch, wenn das so tricky einfach wäre via FW. einen höheren HMB Cache zu reservieren, dass auf den Dreh nicht schon längst andere Anbieter gekommen wären?
Denn WD war nun nicht der erste Anbieter am Markt der HMB SSDs im Programm hat. Die sind eigentlich nur Nachzügler die erkannt haben, dass hier ein Markt ist in dem man mit mischen sollte.
 
Interessant wäre ja mal der Beweggrund von M$, die Einstellungen für HMB zu ändern. Hat man hier den "Wildwuchs" seitens der SSD-Hersteller erkannt? Und wenn ja, ist WD als einziger betroffen, oder lauern da mit dem 24H2 noch weitere Überraschungen, etwa bei chinesischen Anbietern wie Lexar?

Ich frage, weil ich kürzlich einen BSOD beim Booten hatte, und deshalb ein wenig "sensibilisiert" bin. Möglicherweise ist hier aber die Ursache der fehlerhafte Patch, der neulich kam, und dessen Installation ich leider nicht mehr aufhalten konnte.

 
Zuletzt bearbeitet:
Wieso "Wildwuchs"? Üblicherweise setzen die (meist chinesischen) HMB Cache SSDs auf einen Cache zwischen 32 bis 64MB, je nach Kapazität und das funktioniert!
Kurioserweise betrifft es bei WD ja auch nur die 2TB Modelle, die 1TB Modelle scheinen bugfree. Meine Vermutung ist halt, WD wollte sich hier einen Wettbewerbsvorteil a'la (geht man von der These des User Holt aus) höherer HMB Cache = längerer Schreib/Kopiertransfer wo die SSD mit hohen IOPS werkelt, verschaffen um sich von der Konkurrenz abzusetzen. Theoretisch mags ja logisch klingen, praktisch ging es dann aber in die Hose und da man rein technisch von den Bauteilebestückung her nicht mehr wirklich mithalten kann (YMTC Nand gehört mit zu den modernsten mit der höchsten Dichte und MT/s), versucht man es halt mit anderen Mogeleien. Die User welche nun von diesen Bugs betroffen waren/sind oder noch werden, die sind oder werden jedenfalls hoch erfreut darüber sein und WD Hardware bestimmt besonders toll finden.
So kann man sich auch seine Kunden bei der Stange halten. Denn auch wenn man nun den Bug durch zurück rudern des Cache auf die "üblichen" 64MB (die generell funktionieren) eleminiert hat, so wird bei den Kunden dieser Modelle immer noch eine gewisse Skepsis mitschwingen bzgl. was da noch kommen mag an weiteren Bugs und es wird jede Unregelmäßigkeit zum Anlass genommen, den Fehler zuerst bei der SSD zu suchen, auch wenn diese dann nicht die Fehlerquelle sein mag.

BSOD beim booten, dass der Bootvorgang mal länger dauert usw. usf. hatte ich auch schon mal. Und das bei einer WD SN850X als OS Medium. Ist nichts dramatisches.

Fehlerhafte Patches kommen von MS ja mittlerweile in kontinuierlicher Regelmäßigkeit. Reine Gewöhnungssache.

Von diesen ganzen Qualitätsupdates die dir MS im laufe der Zeit installiert sind meist immer nur das aktuelle und maximal das davor gültig, alle anderen werden quasi überschrieben/gelöscht und via "wusa" nicht mehr auffindbar (Das Update KBxxxxxxx ist nicht auf diesen Computer installiert).

wusauninstall.png

edit:
Mal zum generellem Verständnis:
Wenn die (bis zu) 200MB im volatilem Ram zwischengespeichert werden, bevor sie auf die SSD geschrieben werden, sind die doch im Falle eines Stromausfalls weg und soo ein "Cache" ohne USV oder battery backup damit reichlich unklug?
Ist aber bei int. DRam cached SSD auch nicht anders der Fall, denn dieser Ram ist immer flüchtig. Laut NVMe Protokoll werden aber gerade bei HMB cached SSDs da sehr hohe Anforderungen gestellt um Datenverlusten vorzubeugen. Diese müssen sowohl controllerseitig als auch vom Host erfüllt werden.

...
Im Fall von Runtime D3 sollte die Hostsoftware die Hostspeicherressourcen dem Controller erneut zur Verfügung stellen und den Controller darüber informieren, dass die Bereiche vor dem RTD3-Ereignis verwendet wurden und nicht geändert wurden. Die Hostspeicherressourcen bleiben im Controller nach einem Reset-Ereignis nicht erhalten. Die Host-Software sollte dem Controller nach Abschluss des Resets die zuvor zugewiesenen Host-Speicherressourcen bereitstellen. Wenn die Host-Software dem Controller zuvor zugewiesene Host-Speicherressourcen (mit demselben Inhalt) bereitstellt, wird das Memory Return-Bit im Set Features-Befehl auf „1“ gesetzt. Der Controller muss sicherstellen, dass im Falle einer unerwarteten Entfernung während der Nutzung der Host Memory Buffer-Funktion kein Datenverlust oder keine Datenbeschädigung auftritt.
...

pps: Nicht so dröge wie in den NVMe Protokollen erklärt Phison noch einmal grafisch wie die HMB Fehlerkorrekturmethode funktioniert. Dort ist dann unter anderem auch ersichtlich, dass der Host Cache, ebendso wie der wesentlich größere DRam Cache einer SSD die diesen intern verbaut hat, ebend nicht nur, wie hier immer behauptet, aus der Mapping Table besteht sondern auch Nutzerdaten (Data Buffer) und Metadaten temporär zwischen gespeichert werden. Und auch wenn diese Folien mittlerweile 7 Jahre alt sind und nach NVMe1.2 Spezifikation erstellt sind gilt von Einführung HMB bis heute:
Der Controller muss sicherstellen, dass im Falle einer überraschenden Entfernung während der Nutzung der Host Memory Buffer-Funktion kein Datenverlust oder keine Datenbeschädigung auftritt.
 
Zuletzt bearbeitet:
Deiner Logik zufolge, die ich aber so nicht teile, würde eine Adressierung der Mappingtable über 200MB im Schreibzugriff für eine länger höhere IOPS Leistung sorgen.
Kein Wunder das du meiner Logik nicht folgen kannst, wenn du sie nicht einmal verstanden hast. Es geht nicht um Schreibzugriffe, sondern vor allem um Lesezugriffe. In den beiden unteren Bildern in Post #11 steht ja auch 4kB Random Read. Je mehr HMB man hat, umso größer ist der Adressraum für den man den passenden Teil der Mappingtabelle im HMB cachen kann und damit schneller auf diese Daten zugreifen, weil man eben nicht erst nach den passenden Teil der Mappingtabelle aus dem NAND lesen muss, um zu wissen wo die Daten im NAND stehen. Beim Schreiben muss man dies natürlich dann auch ermitteln, weil ja die ggf. vorher unter den beschriebenen Adressen gespeicherten Daten nun ungültig geworden sind und entsprechend markiert werden müssen, damit sie spätestens bei der nächsten Idle-GC gelöscht werden.

Mag ja sein das dem theoretisch so sein "könnte", dass hat sich vieleicht auch WD so gedacht, sich einen Wettbewerbsvorteil erhofft und bei den hier erwähnten Modellen mal so "probiert"..

..ging aber leider gründlich in die Hose weil so einfach das dann doch nicht funktioniert
Das ist ja das Problem, sie haben zwar in der FW hinterlegt, dass sie 200MB HMB haben wollten, aber wenn sie die dann wirklich bekommen haben, konnte der Controller damit nicht umgehen. Es gab eben bisher keinen Host der der SSD so viel HMB gegönnt hat, bisher warten maximal 64MB üblich, nun wurde das Limit beim neuste Windows 11 auf 1/64 des RAMs des Rechners angehoben,

Gegenfrage: Glaubst du nicht auch, wenn das so tricky einfach wäre via FW. einen höheren HMB Cache zu reservieren, dass auf den Dreh nicht schon längst andere Anbieter gekommen wären?
Bisher war es eben sinnlos mehr als 64MB HMB anzufragen, da Windows eben maximal 64MB gegeben hat, aber künftig dürfte es mehr SSDs geben die mehr HMB anfragen und dann auch fehlerfrei nutzen werden.

Interessant wäre ja mal der Beweggrund von M$, die Einstellungen für HMB zu ändern.
Ja, vermutlich dürfte es daran liegen, dass es immer mehr NVMe SSDs mit HMB gibt und diese auch immer größere Kapazitäten haben. Damit macht es schon Sinn, wenn sie auch mehr als 64MB nutzen dürfen, zumal die Rechner ja auch immer mehr RAM haben und damit als HMB bereitstellen können.

WD wollte sich hier einen Wettbewerbsvorteil a'la (geht man von der These des User Holt aus) höherer HMB Cache = längerer Schreib/Kopiertransfer wo die SSD mit hohen IOPS werkelt, verschaffen um sich von der Konkurrenz abzusetzen. Theoretisch mags ja logisch klingen, praktisch ging es dann aber in die Hose und da man rein technisch von den Bauteilebestückung her nicht mehr wirklich mithalten kann
Nochmal: Es geht vor allem um die Lesevorgänge, da macht HMB bzw. der eigene DRAM Cache am meisten aus, denn da steht eben die Mappingtabelle drin und aus der muss man vor dem eigentlichen Lesezugriff immer erst auslesen, wo denn die Daten im NAND stehen. Fürs Schreiben muss man erstmal nur wissen, wo denn freie NAND Pages sind und danach kann man dann rausfinden, ob unter den beschriebenen Adressen schon vorher Daten gespeichert waren die nun ungültig sind und man muss natürlich danach die Mappingtabelle im NAND aktualisieren. Dies kann aber eben passieren, nachdem das Schreiben schon begonnen hat, sollte also die Schreibperformance nicht so massiv beeinflussen wie es bei der Leseperformance ist, da man vor dem Lesen eben immer wissen muss, wo die Daten im NAND stehen und immer erst danach diese Daten lesen kann.

Ist aber bei int. DRam cached SSD auch nicht anders der Fall, denn dieser Ram ist immer flüchtig.
Das sind ja beides auch nur Lesecaches, dies hatte ich doch schon geschrieben:
Im HMB wird nur ein kleiner Teil der Mappingtabelle gecacht, aber keine Userdaten und HMB wird auch nur als Lesecache für die Daten der Mappingtabelle verwendet. Bei Schreibzugriffen werden die Änderungen der Mappingtabelle direkt ins NAND geschrieben und dies ist auch bei den SSD mit DRAM Cache so üblich, außer wenn sie eine Full-Power-Loss Protection haben und damit diese Änderungen auch nach einen unerwarteten Spannungsabfällen noch ins NAND zurückschreiben können. Auch der DRAM Cache ist übrigens kein Schreibcache für Userdaten, die paar Userdaten die SSD im Schreibcache halten, meist nur bis es genug sind um eine ganze Page (meist so 16k oder 32k) vollständig beschreiben zu können, halten die Controller in aller Regel in ihrem internen SRAM.
Sollte ein Hersteller diese nicht nur als reine Lesecaches nutzen, so steigt eben das Risiko von Datenverlust.
Dort ist dann unter anderem auch ersichtlich, dass der Host Cache, ebendso wie der wesentlich größere DRam Cache einer SSD die diesen intern verbaut hat, ebend nicht nur, wie hier immer behauptet, aus der Mapping Table besteht sondern auch Nutzerdaten (Data Buffer) und Metadaten temporär zwischen gespeichert werden.
Mag sein das Phison dort Userdaten ablegt, sie geben da ja einen noch größeren Vorteil beim Zufälligen Schreiben als beim Lesen an:

HMB_RandomWrites.png


Andererseits ist das eine Presentation aus der Anfangszeit von HMB, ob dies dann auch alles so umgesetzt wurde, ist eine andere Frage.
 
Glaubt man den letzten Einträgen im WD Forum, scheinen die betroffenen HMB WD SSDs auch unter W11 23H2 gebugt zu haben -wenn- RST VMD aktiv.
Das würde dann eher eindeutig für eine problematische Firmware sprechen und weniger für das 24H2 Update.
Dürfte wohl auch der Grund dafür sein, warum bisher ausschließlich NUR diese WD Modelle davon betroffen sind und keine anderen (HMB) SSDs anderer Marken.
 
Das würde dann eher eindeutig für eine problematische Firmware sprechen und weniger für das 24H2 Update.
Ja, dies hatte ich doch schon in Post #5 geschrieben:
Dies klingt jetzt erstmal, als wäre MS schuld, wie können sie einfach mehr als 64MB erlauben, aber tatsächlich sieht meines Wissens nach die Spezifikation kein Limit von 64MB vor, dies war einfach so der übliche Höchstwert den die Betriebssystem für HMB erlaubt haben. SSDs die HMB nutzen, identifizieren dafür zwei Werte, einen Mindestwert wie viel sie mindestens haben wollen und einen Optimalwert, wie viel sie am liebsten hätten. Der Host (also hier Windows) entscheidet dann ob er einen HMB mit einer Größe im Bereich dieser beiden Werte anbietet oder gar keinen HMB zuteilt.

Mit diesem Wissen wird dann klar, dass WD hier die Schuld hatte, die haben offenbar einen Bug in ihrer FW gehabt der dazu geführt hat, dass die SSD mehr als 64MB HMB als Optimalwert angefordert hat, dann aber offenbar nicht mit so viel HMB umgehen konnte
Die Schuld liegt klar bei WD, nicht bei MS, da die Spezifikation es eben nicht verbietet mehr als 64MB HMB anzubieten, wenn ein SSD so viel haben möchte.
 
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