Doch, das sind unterschiedliche geplante Erkennungszeichen für den gleichen Problemkreis.
Das nicht jede SSD die defekt zu sein scheint auch wirklich defekt ist, war wohl schon lange klar. Die mit dem Intel Controller kann man unter kompletten Datenverlust wiederbeleben und die Crucial tut das alleine, i.d.R. sogar ohne Datenverlust. Die Sandforce im Panik Lock werden sich auch irgendwie reseten lassen und gehen wenn sonst alles funktioniert danach mit zurückgesetzten S.M.A.R.T. Werten als Refurbished wieder zurück als Ersatz bei Garantiefällen.
Vllt lüftet Intel jetzt ganz vorsichtig den Mantel des Schweigens, weil sie diese SSDs haben:
intel s3700 ssd
Das glaube ich nicht, denn der Fehler war ja schon seid anfang an bei dem alten Intel Controller vorhanden, nur so extrem selten, dass er eben für und nicht als systematisch erkennbar war. Erst bei der 320er, die ja eben genau so eine "Notstromversorgung" hat, erschient er dann ausfallend oft und es wurde klar, dass die Einzelfälle der Vorgängergeneration das gleiche Muster gezeigt hatten.
Die Notstromversorung mit Kondensatoren scheint eben genau das Problem verstärkt statt gemindert zu haben, obwohl der Mechanismus ja in allen Vorgängerversionen schon drin war, aber eben nicht genutzt wurden. Die haben ja auch keine Nutz- sondern nur Verwaltungsdaten im Cache gehalten.
Derartige SSDs mit Strompuffer vermeiden diesen Problemkreis.
S.o. ich glaube nicht, denn offenbar war das genau der Schwachpunkt bei der 320er. Bei der 3700er ist das hoffentlich einerseits überwunden und zum anderen nicht so nötig, weil es eben keine Cosumer SSD ist und damit wohl nur selten ausgeschaltet wird. Für SSDs ist der Dauerberieb noch immer am Besten.
Wenn es mehr derartige SSDs im mittleren Preissegment gibt, dann werden sie mit ihrer Fähigkeit werben - und die Schwäche der Consumer-SSDs bloßstellen.
Es gibt sehr viele SSDs mit so einer Notstromversorgung, dass ist bei Enterprise SSDs üblich und wird bei den entsprechenden Versionen des Sandforce (15xx und 25xx) auch unterstützt. Bei den Cosumer SSDs hatte meines Wissens nur die Intel 320er sowas, zumindest von denen die bekannter sind.
Die SSDs stülpen über das Dateisystem des OS nochmals ihr eigenes Verwaltungssystem.
Nein, dass machen sie nicht, denn sie kennen das Dateisystem nicht und brauchen es auch nicht zu kennen. Sie haben aber i.d.R. ein Schattenfilesystem bei dem sie sich merken, welche Adressen zusammenhängend geschrieben wurden um diese Daten auch optimal über die Kanäle verteilen und somit schnell wieder lesen zu können.
IMHO hat die m4 also kein Erkennungsproblem, sondern die Entwickler haben eine Mimik eingebaut, die ihre SSD mit korruptem Verwaltungssystem _absichtlich_ (it is not a bug, it is a feature) solange nicht zu erkennen gibt, bis das Verwaltungssystem - der Index für den normalen, schnellen Zugriff - geheilt (neudeutsch Rebuild) worden ist.
Es geht nicht um das Filesystem, das verwaltet alleine das Betriebssystem und das ist auch gut so, zumindest so lange SSDs über SATA als normale Block-Devices angesprochen werden. Eigentlich wäre es sinnvoller den Controller der SSD das Filesystem verwalten zu lassen, aber dann müssten die Betriebssystem diese Arbeit abgeben, das einheitliche SSD Filesystem verwenden und man bräuchte an ganz anderes Protokoll für die SSD, weil man eben nicht mehr LBAs adressieren könnte bzw. müsste sondern Dateien und Verzeichnisse. Wann und ob das kommt, steht aber in den Sternen.
Das ist auch nicht der Punkt, die SSDs müssen ja selbst genug Daten verwalten, vor alle die Umsetzung der LBAs auf die NAND Adressen und das muss schnell gehen. Da hat Intel bei der 3700er ja massiv was verändert:
Das ist eben genau eine Form des Schattenfilesystems von dem ich sprach. Es wird ja bei jedem Befehl nicht nur ein LBA adressiert sondern i.d.R. eine ganze Reihe zusammenhängender LBAs, weshalb die Performance auch steigt, je länger die Zugriffe sind weil alleine schon der Overhead abnimmt. Deshalb kann eine einzelne SSD auch niemals bei 4k_64 mehr als etwa 200MB/s an SATA 3Gb/s bzw 400MB/s an SATA 6Gb/s erreichen.
Neben den hohen Latenzen führt das eben auch genau dann zu Problemen, wenn während des Vorgangs der Strom ausfällt. Dann weiß der Controller nicht mehr wo die Daten für einen bestimmten LBA gespeichert sind. Nun NAND aber mehr Kapazität als die nutzbare und zwar reichlich zusätzliche Bytes pro Block und noch einiges extra pro Page:
Wie Du siehst, kommen bei diesem NAND auf 8k pro Page noch 448Bytes, die üblicherweise für die ECC genutzt werden und pro Page auf die 2MB noch 112kB extra. Da kann man auch Verwaltungsdaten unterbringen, etwa zu welchem LBA die einzelnen Pages gehören, welche gelöscht sind, gültige oder ungültige Daten enthalten. Nun wäre es aber extrem langwierig die Mappingdaten aus allen Pages wieder zusammen zu tragen und deshalb steht die (auch noch mal oder nur) komplett im NAND selbst und eben gecacht im RAM. Wenn Crucial nun die LBAs wirklich dort ablegt und diese eben bei jeder Reorganisation des NANDs mitschleppt, dann kann man mit entsprechendem Zeitaufwand auch die ganze Tabellen rekonstruieren sollte sie mal korrupt sein und wenn man davon keine Kopie hat, dann sind die Daten eben verloren. Was bei welcher SSD wohl der Fall sein könnte, darf mal jeder selbst überlegen, aber die Intel geht halt in den 8MB Modus und die Crucial m4 erholt sich wenn sie eine halbe Stunde nur am Strom hängt und nicht angesprochen wird.
Bei der 3700 hat Intel das jedenfalls umgestellt:
Da die Verwaltung jetzt schneller geht, sollte es die "Notstomversorgung" hoffentlich auch immer ausreichen die Daten zurückzuschreiben. Damit wäre das Problem des 8MB Modus dann gelöst.
Das dürfte ab im Anbetracht der Kosten für die Datenrettung dann sowieso egal sein.
e
fficial&client=firefox-a
fficial&client=firefox-a