Holt schrieb:
Das die FW lügt und behauptet die Daten wären schon auf dem Medium, während das in Wahrheit noch nicht der Fall ist, passiert im Alltag z.B. bei den SSDs mit Sandforce Controllern und denen mit dem Barefoot 3 (und auch denen von OCZ mit dem Everest(2), was zeigt das es auch mit dem Marvell geht, wenn die FW das möchte). Das kann man einfach testen, man entfernt hier den Haken bei "Schreibcache auf dem Gerät aktivieren":
Bencht mal dann mit dem AS-SSD und vergleicht vor allem die 4k Schreibend, so werden aus üblicherweise 50 bis 100MB/s dann keine 5MB/s mehr und wenn die SSD diese Einstellung irgnoriert, hat man eben praktisch identische Werte wie mit dem Schreibcache. Zu beachten ist, dass man bei Änderung der Einstellung für das Systemlaufwerk einen Reboot machen muss, damit die Einstellung wirksam wird!
Die Sache mit der Rückmeldung, die wir beide meinen, bezieht sich allerdings auf die zweite Checkbox (Write Cache Buffer Flushing).
Die erste aktiviert den Cache ja lediglich.
Die zweite Option sorgt nun in ihrer Standardeinstellung (nicht angekreuzt) dafür, dass Schreiboperationen
tatsächlich auf dem finalen Datenträger geschrieben wurden, bevor die Rückmeldung an das Betriebssystem erfolgt. Stellt man sie um (angekreuzt / Write Buffer Cache Flushing deaktiviert), dann wird das Schreiben der Daten an das Betriebssystem auch dann als erledigt gemeldet, wenn sich Teile des Schreibauftrags noch im Datenträger-internen Cache befinden, also noch nicht 100% gegen Stromausfall gesichert sind.
Testen ob das Laufwerk sich an diese Vorgabe (aka "Lüg mich nicht an falls du noch gar nicht engültig geschrieben hast") kann man dies meines Wissens nach nur, indem man wirklich ein Szenario mit hartem Power Outage durchführt.
Solange das Laufwerk aber die Vorgabe einhält und eine Anwendung eine Form von Transaktionalität implementiert, ist es eben tatsächlich egal, was passiert. In dem Fall brauche ich tatsaächlich
keine Cache Loss Protection.
Der Test den du vorschlägst ist natürlich auch interessant, zeigt aber, meinem Verständnis nach, "nur" den bekannten Effekt des Schreibcaches.
PS: Zu dieser zweiten Option gibt es online sehr viel Bullshit zu lesen. Eine der wenigen guten
und korrekten Beschreibungen gabs mal im Blog von einem MS-Mitarbeiter. Eventuell kann ich den Link mal raussuchen.
Holt schrieb:
Unangenehmen ist es aber, wenn die SSDs ihre Verwaltungsdaten wegen so einem unerwarteten Spannungsabfall nicht mehr korrekt vom Cache in die NANDs schreiben konnte, die Mappingtabellen, also die Verknüpfungen von LBAs auf Speicheradressen belegen nämlich vor allem im Cache dem meisten Platz. Dann bricken SSDs meist, sind unbrauchbar oder können nur über ein Secure Erease wiederbelebt werden, bei Crucial gibt es immerhin noch die Power Cycle Wiederbelebungsmethode, die zumindest seid der m4 für alle Micron und Crucial SSDs mit Marvell Controllern funktioniert und ohne kompletten Datenverlust die SSDs wiederbelebt, bei denen die Verwaltungsdaten korrupt sind.
Da weiß ich nicht genauer Bescheid, okay. Ich hätte eher getippt dass SSDs so schlau sind und zumindest ihre Verwaltungsdaten immer im Trockenen haben. In der Tat natürlich ziemlich doof, falls das, wie du sagst, nicht so sein sollte..
)
