Kreisverkehr, wenn Du im Forum schon länger liest, solltest Du Baumi leicht wiedererkennen können und wirst feststellen, dass alle anderen Accounts gesperrt wurden. So ging es ihm auch mehrfach in den anderen Forum. Und er reitet nicht nur seinen Feldzug gegen SSDs sondern spart auch nicht mit persönlichen Angriffen. Irgendwas hat ihn halt mal wirklich tief traumatisiert. Er erwartet offenbar die fast 100%ig Sicherheit von Enterprise HW auch im Consumersegment zu finden, was aber eben nie der Fall sein wird, weil keiner dafür bezhahlen möchte. Deswegen sind die Consumer SSDs aber eben nicht alle Schrott, wie er es sieht, sie reichen für die gewöhnlichen Heimanwender weiterhin aus.
Die ganze Consumer-HW ist immer nur so gut wie nötig um meistens zu gut funktionieren, aber trotzdem so billig wie möglich zu sein. Wäre der Anspruch an die Datensicherheit höher, hätte auch jeder zuerst einmal ECC RAM und ein System welches das unterstützt. Baumi hatte unter seinem letzten Account geschrieben, er hätte ECC RAM aber eben kein System welches das unterstützt, aber er hatte erwartet das es hilft weil es qualitativ ja besseres RAM sein müsste
Kreisverkehr schrieb:
Anders gefragt: schreibt der Controller dann im Zufallsprinzip auf den MLC, so dass im statistischen Mittel quasi abwechselnd "abgenutzt" wird oder bringt es mehr Leistung, die Entscheidung dem Controller zu überlassen?
Das nennt man Wear Leveling und das hat jeder SSD Controller mehr oder wenig gut implementiert. Es hat mit der Nutzung von MLC als Pseudo-SLC nichts zu tun, da muss das erste Bit immer zuerst programmiert werden und dann sollte man das zweite Bit schreiben, da die NAND Chips gewöhnlich intern die Schwellwerte für die Unterscheidung der einzelnen Ladungszustände speichern und dynamisch an den Verschleißzustand der Zellen anpassen.
NANDs die nicht darauf vorbereitet sind nur mit einem Bit beschrieben zu werden, bekommen die Schwellwerte dann nicht ordentlich nachgeführt und werden damit u.U. schnell unbrauchbar, vor allem wenn dann doch mal beide Bits programmiert werden. Das Risiko scheint hier nicht zu bestehen und heutige NANDs sollten auch in einem pasenden Modus geschaltet werden können, damit es nicht passiert. Diese Schwellwerte sind auch das Problem bei plötzlichen Spannungsabfällen während Schreib- oder Löschvorgängen, dann stimmen die u.U. eben auch nicht mehr und der Block wird unbrauchbar. Damit das eben nicht passiert, haben die guten Enterprise SSD alle eine Full-Power-Loss Protection, also dicke Stützkondensatoren oder gar Akkus um genau Energie zu haben die Verwaltungsdaten und die Daten im Schreibcache garantiert zurückschreiben zu können, auch wenn dabei erst noch ein paar Blöcke freigeräumt werden müssen, was dann bei den Client Lösungen Probleme macht, wiel die Kapazität der Kondensatoren u.U. dann nicht mehr reicht.
Es gab auch schon Fälle von Crucial m500, m550 und MX100 die mit der
Power Cycle Methode wiederbelebt werden musste, was belegt, dass die Verwaltungsdaten eben nicht mehr vollständig zurückgeschrieben werden konnten und die Mappingtabelle korrupt war. Die Methode geht bei den Crucials (zumindest denen mit Marvell Controllern) weil sie die LBAs nicht nur in der Mappingtabelle ablegen, sondern auch noch einmal hinter jeder Page bei den Daten. Damit kann sie rekonstruiert werden, was aber länger dauert und über die Power Cycle Methode angestoßen wird. Andere SSDs sind dann brickt, wie die Sandforce oder bei den alten Intel bis zur 320 nur noch 8MB groß und lassen sie ggf. nur über ein Secure Erease wiederbeleben, aber eben unter totalem Datenverlust. Anders geht es eben auch nicht, wenn die SSD die LBAs nicht mehr den Daten im NAND zuordnen kann.
