pspierre schrieb:
Müsste die GC, die doch ständig im Hintergrund alleinig wahrscheinlich schon so 2 Jahre werkelte, nicht doch auch zumindest einen grossen Teil schon mal beschriebener Speicherzellen ebenfalls wieder glöscht , dh als direkt beschreibbar hinterlassen haben....oder hab ich hier immer noch ein Verständnisproblem ?
Ja, denn ob mit oder TRIM, wenn das EwarLeveling funktioniert, dann müssten inzwischen schon alle Blöcke mehrfach gelöscht und neu beschrieben worden sein. Aber das ist eine Sandforce SSD und da löscht der Controller die Blöcke immer erst direkt beim schreiben, selbst wenn er diese vorher aufgeräumt hat, also dort keine gültigen Daten mehr liegen. Das soll die Write Amplification verringern und die Lebensdauer erhöhen, aber wieso, das verstehe ich auch nicht, denn wenn keine gültigen Daten mehr in einem Blöck liegen, dann erzeugt das Löschen auch keine WA mehr. Es muss also einen anderen Grund haben, denn der Nachteil ist ja in der Praxis eine, je nach NAND so um 20 bis 40% geringer Schreibrate (Normalzustand). Außerdem räumt der Sandforce im Idle nie die ganze freie Kapazität auf, sondern immer soviel, wie der ab Werk vorhandenen freien Kapazität entspricht. Das kann es natürlich immer, denn weniger kann ja nie frei sein.
Schreibt man dann mehr bevor er wieder aufgeräumt hat (was bei dem Stunden dauert), so fällt er in den Recovery Modus und muss nun vor dem Schreiben auch noch erst die Blöcke auswählen und aufräumen, die er beschreiben will, was eine normal geringere Schreibrate zur Folge hat, die sich dann aber nach einigen Stunden im Idle wieder erholt. Auch hier ist wieder die Frage, warum er nicht mehr aufräumt wenn eigentlich viel mehr möglich wäre nicht logisch zu beantworten und wohl nur mit Limitationen des SF-Controllers zu erklären.
Andere SSD räumen im Idle so viel Platz frei und Löschen die Blöcke, wie es unter Berücksichtigung der WA möglich ist, aber der Sandforce eben nicht.
pspierre schrieb:
Ich dachte Trim und GC streben letzlich das gleiche an..... nämlich mit toten Informationen zugeschriebene Speicherressourcen auch physikalisch schon mal zu Löschen, um effizientere Schreibzugrife zu ermöglichen ....Trim halt nur mit höherer, vor allem gezielterer Effizienz ......?
Dann solltest Du noch mal den ersten Beitrag hier lesen, denn TRIM löscht die Blöcke nicht, das macht die GC. TRIM gibt nur zusätzlich die Information, dass Daten ungültig geworden sind, was der Controller sonst eben nur erfährt, wenn ein LBA überschrieben wird. Es würde aber für eine zu hohe WA sorgen, wenn man wirklich immer gleich einen ganze Blöck auch löschen würde, nur weil eine Page drin getrimmt wurde und deren Daten nun gelöscht werden können. Stattdessen wird einfach der Verweis der getrimmten LBAs auf die Flashadresse gelöscht und damit kann an dann auch diese Daten auch nicht mehr zugreifen und bekommt nur Nullen zurück, wenn man den getrimmten LBA wieder ausliest, selbst wenn die Daten eigentlich noch im Flash stehen.
Und wie oben schon geschrieben, wird das "physikalisch schon mal zu Löschen, um effizientere Schreibzugrife zu ermöglichen" beim Sandforce eben nicht gemacht, bei anderen Controllern aber eben schon. Das ist ein klares Argument gegen den Sandforce, da die Schreibrate dadurch geringer, aber ein wirklicher Vorteil für den User trotzdem nicht zu erkennen ist. Über die Gründe kann man nur Vermutungen anstellen, aber da der SF mit aktivem RAISE ja intern als RAID 5 und nicht wie die anderen als RAID 0 arbeitet, würden sonst bei den gelöschten Bereichen die Partity Informationen nicht mehr stimmen und wenn man die Blöcke eben erst beim Schreiben löscht, dann kann man die Parity konsistent halten, weil ja auch gleich neue Parity Informationen geschrieben werden.
Das hätte man sicher auch anders lösen können, aber dafür sind offenbar die Resourcen zu knapp, denn der SF macht ja auch noch eiine Datenkompression und -verschlüsselung und das alles ohne ein externes RAM zu haben. In meinen Augen wurde hier versucht ein sehr anspruchsvolles Konzept mit zu wenig Mitteln zu realisieren und dafür wurden eben auch faule Kompromisse in Kauf genommen. Deswegen vermute ich auch, dass eine dritte SF Generation entweder deutlich aussehen wird oder aber auf den Enterprise Bereich beschränkt bleibt, wo man mehr Resourcen unterbringen und Strom verbrauchen kann.
pspierre schrieb:
Wenn Bei einer Platte nur mit GC der Kontroller beim schrieben auf Bereiche mit nicht physikalisch gelöschten Informatioenen (egal ob benötigt oder nicht benötigt) trifft
Der Controller trifft beim Schreiben nicht auf solche Bereiche, denn er verwaltet ja die Flashbereiche und weiß daher, wo Blöcke frei sind deren Pages beschrieben werden können und wenn geschrieben wird, dann landen die Daten genau dort und die Flashadressen werden den geschriebenen LBAs zugewiesen. War diese LBAs vorher anderen Flash Adressen zugewiesen, so werden die Daten in den anderen Adressen nun als ungültig markiert.
pspierre schrieb:
...simpel statistisch gedacht müsste die GC eigenlich auf Dauer in etwa fähig sein etwa die Häfte der vom System als syteminhaltlich "beschreibar " gemeldeten Kapazität in GB, auch auf physikalisch gelöschtem, und somit schnell beschreibbaren Zustand zu halten
Wenn man es wollte, wäre die GC in der Lage die ganze Kapazität die nicht mit gültigen Daten belegt ist zum schnellen Schreiben bereit vorzuhalten. Aber das würde bedeuten, dass man einen Block schon dann löschen (und vorher die noch gültigen Daten kopieren) müsste, wenn auch nur die Daten von einer Page darin ungültig geworden sind. Da ein Block so 256/512 oder gar 1024 Pages hat, wäre eine sehr hohe Write Amplification die Folge und das will man auch wieder nicht.
Die Write Amplification und die Güte des Wear Levelings sind ja alleine das Ergebnis des Algorithmus der die Blöcke zum Löschen (egal ob in der GC oder der Idle-GC) auswählt und keine eigenständigen Funktionen, weshalb es auch echt lächerlich ist, wenn ein Hersteller denen sogar noch Namen gibt!
pspierre schrieb:
....so in etwa hab ichs für mich bisher in etwas mit der GC verstanden.........
Bitte korrigiere mich, wenn ich voll daneben liegen sollte.
Die GC ist einfach nur der Name für die Funktion, die dafür sorgt, dass Flash Blöcke gelöscht werden. Ohne die könnte man Flash nur einmal beschreiben, weshalb es schon total falsch ist, wenn jemand behauptet, eine SSD hätte keine GC. Der verwechselt schon mal mindesten die GC mit der Idle-GC, was eigentlich das Gleiche ist. Als Idle-GC bezeichnet man aber, wenn der SSD Controller im Idle ist und dann schon mal vorsorglich Blöcke freiräumt und löscht, damit hinterher so schnell geschrieben werden kann, als wäre die SSD neu. In diesem Sinne hat der Sandforce keine Idle-GC, obwohl gerade der im Idle gewaltig ackert und auch Blöcke aufräumt, aber eben nicht löscht.
Die GC kommt aber nicht nur im Idle zum Einsatz, sondern eben auch immer dann, wenn während des Schreibvorgangs die leeren Pages auszugehen drohen und daher neue Blöcke gelöscht werden müssen. In der Situation bricht bei jeder SSD die Schreibrate ein und das ist eben bei SSDs die getrimmt wurden etwa nach einem Datenvolumen der Fall, was dem lauf Filesystem freien Platz entspricht. Wurde die SSD eben eben nicht getrimmt dann eben schlimmstenfalls schon wenn wenige % der Kapazität geschrieben wurden. Hat sie einen Sandforce Controller der ja nur einen Teil von der Größe der OP Area aufräumt, dann eben sobald ein entsprechenden Datenvolumen in die NANDs geschrieben wurde (Recovery Mode). TRIM hilft also das Datenvolumen zu vergrößern, welches am Stück und schnell geschrieben werden kann und minimiert das Datenvolumen, welches intern umkopiert werden muss, wenn die GC Blöcke löscht, was die WA und den Einbruch der Schreibrate wenn dies während des Schreibens passiert, mindert.
pspierre schrieb:
Noch was anderes frag ich mich, in dem Zusammenhang:
Was meinst Du wohl, hat der Vorbesitzer mit der Platte am Schluss gemacht, um sie für den Verkauf von seinen Daten zu befreien...was bietet sich da an, wenn man sicher sein will, das man die nicht ggf doch irgenwie in Teilen wieder auslesen könnte ?
Manch einer löscht nur seine Daten und vergisst sogar den Papierkorb zu leeren, andere machen eine Schnellformatierung, beides reicht definitiv nicht. Andere machen wenigstens eine Vollformantierung, was ausreicht, weil ja dabei alle LBAs überschrieben werden und damit nicht mehr über die LBAs auf die alten Daten zugegriffen werden kann, selbst wenn diese noch im NAND stehen. Noch sicherer ist ein Secure Erease, was beim SF obendrein den Vorteil hat, dass die Schreibrate wieder in den Neuzustand versetzt wird, weil ja alle Blöcke gelöscht wurden und dies nicht mehr vor dem Schrieben passiert. Hier gibt es
eine Anleitung zum Secure Erease mit gparted.
pspierre schrieb:
Und welchen Einfluss hat solch eine Massnahme auf den ggf jetzigen Zustand meier Platte nach so einer Aktion
Wenn es ein Secure Erease war, dann schreibt die solange schneller, bis alle NAND Pages einmal beschrieben sind.
pspierre schrieb:
mit der angeblich aus heutiger offiziell hier vertretener Sicht "untolerierbaren" FW 1.33
Als ich schrieb, dass dazu ja
NicoOCZ im OCZ Forum schon geantwortet hat, sollte das keine Wertung seiner Antwort oder Meinung sein. So würde ich z.B. die Meinung 2.3TBW wären bei 3900 Stunden eine normale Nutzung nicht teilen, sondern finde das ehr wenig, aber zu Apple kann ich da sowieso nichts sagen, da ich nicht weiß wie viel deren Betriebssysteme so schreiben.
pspierre schrieb:
Kaputt im Sinne von "ist jetzt für die Tonne" , oder im Sinne von: muss neu formatiert oder sonstwas mit gemacht werden, von dem ich nur noch nichts ahne,weiss,kann...... ?
Im Sinne von RMA oder Tonne, denn ich wüsste nicht, wie man die wiederbeleben kann. Es gibt zwar ein paar Rezepte mit Idlen und für x Stunden nur an eine Stromversorgung hängen und was weiß ich, aber oft klappt das wohl auch nicht.
pspierre schrieb:
Was kann mir schlimmstenfalls aufgrund zu vieler "Experimente", wie du sagst, bezüglich Trimm ,usw mit dem Teil passieren ?
S.o.! Aber das kann Dir bei einer SF-1200 sowieso passieren, da müssen die Experimente nicht einmal mit zu tun haben.
....und das auch noch mit der angeblich aus heutiger offiziell hier vertretener Sicht "untolerierbaren" FW 1.33 , von ich weiss nicht wann (von wann ist sie eigentlich?) ....sollte ich entsprechend auch die dann nicht vlt besser so lassen wie sie ist ?
Was mich aber doch noch interessieren würde: 
