Von Sandforce! Gerade die haben doch gezeigt wie man es nicht machen soll und so viel Marketingmüll über ihren und anderen Controller verbreitet, von wegen Write Amplification 0.5 und anderen 10, 256Bit AES Verschlüsselung versprochen und nur 128Bit geliefert, etc.
Dann haben sie erst ihre komische RAISE Fehlerkorrektur als unbedingt nötig beworben und nun kommen immer mehr SSDs mit dem SF-2281 ohne RAISE aber dafür mit "der vollen Kapazität" von 128/256/512GB daher. Der Sandforce Controller ist nie auf die SSD Kunden hin optimiert worden sondern immer auf die Belange der SSD Hersteller, die ja die Kunden von Sandforce sind und denen erlaubt es eben mit Techniken wie RAISE und dem Life Time Throtteling auch SSDs mit minderwertigen NANDs möglichst über die Garantiezeit zu bringen, auch wenn die Performance total einbricht. Dafür ist auch die Datenkompression da, denn damit kann man bei vielen Benchmarks die nur mit extrem komprimierbaren Daten arbeiten gute Werte erzielen und bei vielen Leuten Eindruck schinden. Im
Dauerschreibtest auf xtremesystems.org hat aber keine der Sandforce SSDs die versprochene überlegene Haltbarkeit gezeigt, die waren alle nur im Mittelfeld. Der Nutzer hat aber die Nachteile der verschiedenen Schreibgeschwindigkeiten, weil der Controller eben nicht die ganze freie Kapazität einfach löscht um sie schnell wieder beschreiben zu können, was angeblich wegen der besseren Haltbarkeit gemacht wird.
Das solltest Du Dir dann wieder abgewöhnen, denn wenn man die Begriffe schon durcheinander wirft, bekommt man die Sachverhalte nie auf die Reihe.
TRIM wird explizit vor der neuen Verwendung der gleichen (logischen) Dateisystemadressen vom System befohlen.
Das macht ja aber nur Sinn, wenn zwischen TRIM (dem ungültig werden der alten Daten durch Löschen der Datei) und dem neu beschreiben des LBAs auch einige Zeit liegt. Das ist beim direkten Überschreiben einer Datei aber nicht der Fall und daher gibt es da auch kein TRIM, was auch in Ordnung ist.
Aber spätestens, wenn eine Schreib-Adresse neu mitgeteilt wird, "verrät" sich das System auch ohne TRIM-Kommando.
Wenn ich die Daten eines LBAs überschreibe, dann sind die Daten die vorher dort lagen natürlich ungültig, das war schon bei den HDDs nie anders.
] Da aber sowieso wegen WL immer an andere vorgeputzte physikalische Adressen geschrieben wird, juckt das die SSD nicht mehr weiter.
Das nicht wieder in die gleiche Page geschrieben wird, hat erstmal mit dem Wear Leveling wenig zu tun. Der Grund liegt primär darin, dass man NAND Flash zwar Pageweise (4k, 8k) lesen und schreiben kann, es aber nur blockweise löschen muss und so ein Block hat mal eben 256 oder 512 Pages. Wollte man hier die Daten wieder in die gleiche Page schreiben, müssten man die Daten aller anderen Pages vorher auslesen und nach dem löschen des Blocks ebenfalls wieder schreiben. Das wäre alleine schon von der Performance her totaler Wahnsinn.
Deshalb werden die Daten immer in eine anderen Flashpage, die vorher schon gelöscht wurde, geschrieben. Dadurch hat man hinterher Blöcke in denen viel oder gar alle Pages nur noch ungültige Daten enthalten und braucht andererseits ständig Blöcke die man wieder löschen kann um erneut freie Pages zum schreiben zu haben. Das Wear-Leveling ist nichts anderes als das Ergebnis des Algorithmus der die Blöcke zum Löschen auswählt. Dabei muss er berücksichtigen wie viele Pages des Blocks frei, von gültigen oder von ungültigen Daten belegt sind, wie oft der Block im Verhältnis zum Durchschnitt schon gelöscht wurde und an welchem Kanal des Controller der Block hängt.
Das Wear-Leveling und die Write Amplification sind dann das Ergebnis der Auswahl des Algorithmusses und der gewählte Block wird dann gelöscht, wobei vorher die noch gültigen Daten kopiert werden müssen und eben in einem vorher gelöschten Land landen.
Wenn ich der Controller wäre, würde ich natürlich meckern: "Hey System, das hättest du mir auch mal früher sagen können, dass es aus deiner Sicht schon länger so viele obsolete Bereiche gibt, für die du mir jetzt neue Daten schickst. Jetzt ist mein Verwaltungsaufwand viel höher."
Da muss der Controller mit leben, denn wenn z.B. wie bei Datenbanken oder Images von Virtuellen Laufwerken üblich, die Dateien nicht gelöscht sondern immer nur (teilweise) überschrieben werden, dann bekommt es sowieso keine TRIM Befehle. Der Unterschied zwischen TRIM und nicht TRIM ist eben, wie voll die SSD aus der Sicht des Controllers ist.
Unter GC verstehe ich auch mehr das Zusammenfummeln von lower und upper Pages und von einzelnen Zuordnungseinheiten von sehr kleinen Dateien, die eventuell kleiner als eine Page sein könnten. Und wenn man über all das nachdenkt, versteht man, warum ich bei MLC und besonders bei TLC beim Gedanken an plötzliche Stromausfälle die Stirne runzele.
Was Du darunter verstehst ist Deine Sache, aber man versteht unter der GC das Recycling der NAND Pages, so wie ich es oben beschrieben habe und das muss jeder Flash Controller haben, denn sonst wäre das ja nur Write-Once. Wenn also jemand behauptet eine bestimmte SSD hätte keine GC, dann kann es nur falsch sein und man hat die GC mit der Idle-GC verwechselt.
Dateien kennt der SSD Controller sowieso nicht, denn der hat einfach nur eine bestimmte Anzahl LBAs und das Filesystem verwaltet diese und ordnet die LBAs den Dateien zu. Das es da "sehr kleinen Dateien, die eventuell kleiner als eine Page" sind gibt, kommt daher nicht vor und wenn man statt Datei Daten sagt, dann passiert das nur beim Sandforce, weil nur der die Daten komprimiert. Alle anderen Controller verwalten die Daten viel einfacher, weil die eben die immer eine feste Größe haben und die interne und "externe" Größe identisch sind. Bei 4k Pages passen also immer die Daten von 8 LBAs, denn es werden ja nach außen immer 512Byte Sektoren emuliert.
Die lower und upper Pages zusammen zu fügen braucht nur, wer die auch wirklich getrennt beschreibt, so wie OCZ es beim Everest2 und Barefoot3 macht, was aber eine hohe WA und alleine schon wegen der Algorithmen zur Bestimmung der Ladungswerte eine geringere Lebensdauer bedeutet. Das macht man einfach nicht, sowas ist ein billiger Hack, denn bei MLC NANDs ist es nicht vorgesehen nur ein Bit zu schreiben. Deshalb verwenden seriöse SSD Controller diesen billigen Trick zum Pushen der Schreibraten ja auch nicht, denn die wissen zwar auch genau, dass man das erste Bit sehr schnell schrieben kann, aber die NANDs schädigt, weil sich die internen Thresholds dabei mit der Zeit verschieben weil die Logik im NAND eben versucht 4 verschiedene Ladungsmenge zu unterscheiden und nicht nur 2.
Plötzliche Stromausfälle sind bei SSDs immer ein Problem weil sie alleine schon für die NANDs ein Problem darstellen, wenn diese gerade beschrieben oder gelöscht werden, was ein komplexer und in mehreren Phasen ablaufender Vorgang ist, der entsprechend den Herstellervorgaben erfolgen und möglichst nicht unterbrochen werden sollte. Die betroffene Page bzw. der betroffene Block können dabei irreparabel beschädigt werden und entweder ganz ausfallen oder danach zumindest eine deutlich geringere Zyklenfestigkeit ausweisen. Obendrauf muss der Controller noch seine ganzen eigenen Verwaltungsdaten handhaben und nicht nur im Cache sondern auch im NAND ständig aktuell halten.
Es gab mal ein Tool, das in stundenlanger Fummelei den Index von einem zerbrochenen Dateisystem wieder neu aufgebaut hat, mcafee nuts and bolts:
https://www.google.de/search?q=mcaf...&rls=org.mozilla:de:official&client=firefox-a --- So eine Aktion machen die bei der Crucial M4, wenn die mal für 10 Minuten und länger weg ist.
Testdisk und alle anderen Datenrettungsprogramme machen das auch, aber der Controller der m4 macht das ganz sicher nicht. Nur frühe Samsung Controller aus der Zeit vor TRIM hatten mal so einen Algorithmus implementiert der die Dateisystemstrukturen analysiert hat um gelöschte Dateien zu finden und die denen zugeordneten Daten zu löschen. Das ging dann auch glatt schwer in die Hose wenn man die SSD im RAID betrieben hat.
SSDs haben sich schlicht nicht darum zu kümmern was auf ihnen abgelegt ist, denn das geht nur das Filesystem etwas an und alle aktuellen SSDs halten sich auch daran. Die guten SSDs führen zwar ein Schattenfilesystem in dem sie sich merken, welche LBAs zusammenhängend geschrieben wurden um die Daten möglichst optimal über die Kanäle zu verteilen, aber das war es dann auch.
Übrigens, oben im 2. Link, Seite 2: Everyone Knows: Declining Reliability, Retention, Performance. 3Bits per Cell NAND Makes It Worse! (Gartner). .... Aber hier darf das bei der 840 Nobody Know.
Nur die "SSD-Versteher" dürfen sich diskret zuzwinkern. lol
Das gleiche hat man beim MLC damals auch gesagt und nur SLC war gutes NAND, heute wird selbst in Enterprise SSD fast nur noch MLC verbaut und auch wenn das als eMLC oder sonstwie vermarktet wird, es ist ganz normales MLC, nur eben die besten Qualitäten. Da erreichen die 25nm NAND von IMFT (Micron + Intel) inzwischen über 30.000 P/E Zyklen.
Das TLC der Samsung 840 hat im
Dauerschreibtest auf xtremesystems.org 3556 P/E Zyklen[/U] ausgehalten, davon über
über 2600 ohne Fehler, also deutlich mehr als die von Samsung garantierten 1000 P/E Zyklen. Selbst diese 1000 P/E Zyklen reichen aus um 5 Jahre lang täglich die halbe Kapazität der SSD neu zu beschreiben, sind also mehr als genug für jeden Heimanwender. Wie es bei anderen TLC NANDs oder anderen SSDs mit TLC NANDs aussieht bzw. mal aussehen wird, steht auf einem anderen Blatt und wird sich noch zeigen müssen.
Übrigens, neulich schrieb hier jemand, dass in Samsung NBs SSDs von SanDisk sind, keine 840er. Klar, falls der absolut ausgeschlossene Fall von ärger mit TBC eintreten sollte, haben nur Endverbraucher einzelne 840er verbaut und schicken die dann einzeln zurück. Das wäre natürlich deutlich billiger als wenn komplette NBs zurück gingen und der Service die SSDs wechseln müsste. Wenn dann die Bastler diese SSDs ohne größere Probleme erprobt haben, kann man TLC auch OEMs und Enterprise anbieten.
Tolle Theorie, aber hast Du Dir mal überlegt, ob es nicht einfach sein kann, dass man in der Notebookabteilung die SanDisk U100 nimmt, weil die SSD Abteilung noch keine 840er in dem benötigten Formfaktor (mSATA) im Angebot hat? Suche mal ein Samsung Notebook das ab Werk eine 2.5" SSD hat die nicht von Samsung selbst ist.
Mit Trim hat man doch zwangsläufig sehr, sehr viel mehr freie Zellen wodurch das Wear Leveling viel effizienter arbeiten kann. Es verhindert zudem, dass die Garbage Collection Daten hin und her schiebt, die der Anwender eigentlich schon lange gelöscht hat was der SSD-Controller aber eben ohne Trim einfach nicht wissen kann.
So ist es, denn mit TRIM ist die SSD voll wie sie auch für das Filesystem ist und ohne TRIM so voll wie die Summe aller jemals beschriebenen LBAs. Es reicht also eine SSD ohne TRIM einmal normal (nicht schnell) zu formatieren und ab da ist deren gesamte Nutzkapazität für den Controller ständig mit gültigen Daten gefüllt. Mit TRIM passiert das nur deshalb nicht, weil Windows die ganze LBAs die nicht mit den Verwaltungsdaten des Filesystems belegt sind trimmt.
So ist es, nicht so wird es sein.
Wenn ich weniger als die Hälfte niemals partitioniere, dann kann eine lernfähige FW erkennen, dass ein kompletter, zusammenhängender Adressbereich gar nicht verwendet wird und wesentlich zurückhaltender und gelassener vorgehen, was der Robustheit der SSD zugute käme.
So ein Müll. Da braucht der Controller gar nichts zu merken, denn wenn man einen Bereich ab neu unpartitioniert lässt, dann kann das Filesystem diese LBAs auch nie beschreiben und somit werden schlicht keine Daten vorhanden sein die diesen LBAs zugeordnet sind und der Controller hat automatisch immer mehr freie NAND Kapazität zur Verfügung. Der Sandforce ist da vielleicht wieder das Negativbeispiel, aber bei anderen Controllern i.d.R. funktioniert das wunderbar, obwohl das natürlich auch von der FW abhängt.
Im SATA-Protokoll fehlen leider Befehle, um dem Datenträger das explizit zu sagen.
Das ist schlicht falsch.
SET MAX ADRESSS ist Teil der ATA Spezifikation und genau dafür gemacht. Damit kann man eben genau das machen, was Du vermisst und zwar dem Controller der Platte (HDDs wie SSDs) sagen, wie viel Kapazität man maximal nutzen will. Das wird auch schon wenig dafür verwendet um Short-Stroke bei HDDs zu realisieren oder eben OP bei SSDs. HDPARAM oder HDAT2 sind uralte Tools die man dafür verwendet. Damit weiß der Controller dann auch, dass die LBAs jenseits der MAX ADRESS nie mehr angesprochen werden.
