Sprichst was gegen eine SSD unter WinXP an einem H61 Board?

[etheReal]

XP und SSD? = Schlechte Idee!

Warum? Explodiert dann der Rechner?

Nein, ist keine schlechte Idee. Die Performance sinkt u.U. gegenüber einem System mit TRIM etwas ab, wenn aber noch genug Platz frei bleibt, und man auf der Systemplatte nicht viel schreibt (Office System!) dann merkt man das überhaupt nicht.
Ich habe es eine Zeit lang auf einem Notebook so gemacht, und es war überhaupt kein Problem!

P.S.: allerdings gäbe es für mich 1000 andere Gründe, weshalb ich sofort von XP auf Win 7 umsteigen würde. Wenn also kein triftiger Grund für die Beibehaltung von XP da ist: weg damit!

 

[micha2]

er hat nur getrollt

 

[powerfx]

Holt, ja eben. Die Möglichkeit über die LBAs ist fragwürdig bis nutzlos, denn es können nur die LBAs gelöscht werden, die vom System überschrieben worden sind, nicht die, die gelöscht wurden. Wurde die SSD mit einer solchen GC einmal vollgeschrieben, wird es nie wieder freie Blöcke geben, da sie nicht erkannt werden. Und dann werden die ganzen bereits gelöschten Daten in diesem Prozess über die ganze SSD geschoben. Ohne TRIM ist das also ziemlich sinnlos und mit TRIM irgendwie auch, denn da können die Blöcke ja sowieso als gelöscht markiert werden.

D.h. echten Nutzen hat man nur mit einer GC über das Dateisystem und deswegen ist es auch so zumindest in Firmware von RBB, Barefoot und Postville implementiert. Bei Samsung läuft es nur automatisch ab, bei den beiden anderen muss/kann es manuell angestoßen werden. Und die fehlende Unterstützung für andere Dateisysteme ist auch der Grund wieso weder Intels SSD Optimizer noch das Wiper-Tool von OCZ auf FAT-Partitionen läuft.

Der JMicron 602 hatte weder GC noch Cache. Wurden alle Blöcke einmal beschrieben, mussten entsprechende davon bei ankommende Daten sofort gelöscht und die Daten anschließend geschrieben werden. Das führte zu den bekannten Rucklern.

 

[Holt]

Alle Daten die auf eine HDD oder SSD geschrieben werden, sind einer LBA zugeordnet. Bei HDDs wird daraus direkt der Zielsektor berechnet und angesprochen. Bei SSD werden die Daten in eine freie Page geschrieben und die Adresse der Page mit dem LBA verlinkt. Ab diesen Zeitpunkt sind das für den Controller günstige Daten.

Wenn diese Adresse vorher vorher schon auf Daten im Flash gezeigt hat, so sind diese Daten ab jetzt ungültig. Ohne TRIM ist das der einzige Weg, auf dem Daten ungültig werden. Kommen TRIM Befehle an, so werden die Daten die zu den darin genannten LBAs gehören ebenfalls ungültig.

Jeder Controller von Flash NAND hat eine GC, sonst könnte man je nur einmal die Kapazität beschreiben, aber nicht jeder hat eine Idle-GC. Wenn ich schon irgendwo lesen, ein Controller hätte keine GC, dann hat der Schreiber entweder keine Ahnung oder er hat die GC mit der Idle GC verwechselt. Im Prinzip ist das aber das gleiche, der Unterschied ist nur der Zeitpunkt, wann es ausgeführt wird.

Die GC muss vorhanden sein, weil das der Name für den Algorithmus ist, der das Recycling der Flash Blöcke vornimmt. Dazu werden Blöcke ausgewählt, die entweder bisher noch sehr selten gelöscht wurden (gutes Wear-Leveling) und/oder aber die viele Pages mit ungültigen Daten enthalten (geringe WA). Wie man sieht, gibt es da schon einen Zielkonflikt, das ganze ist also alles andere als einfach. Dann werden alle noch gültigen Pages in dem Block in andere, freie Pages kopiert (weil man eben nur in gelöschte Pages schreiben kann) und der Block wird gelöscht. Das nennt man GC und wenn man mehr am Stück schreibt als freier Platz für die Daten verfügbar ist, dann passiert das auch während des Schreibens.

In diesem Bild sieht man auch sehr deutlich, ab wann das passiert:



Das Bild ist von Anandtechs TRIM Test der Crucial m4 mit der 0009er FW. Bei dem Test wird die SSD voll geschrieben, 20 Minuten mit 4k Randomwrite bei QD32 gefoltert und dann wird die Schreibrate beim seq. Überschreiben gezeigt. Da erkennt man auch, dass der Controller eine gut funktionierende Idle-GC hat, die die etwa 7% (abzgl. der Verwaltungsdaten) Free Area freigeräumt hat. Deshalb können die ersten GB auch mit der vollen Performance geschrieben werden und erst dann geht dem Controller der freie Platz aus und die GC muss während des Schreibvorgang arbeiten, was die Schreibrate natürlich mindert und zwar sehr deutlich.

Bei der Octane ist es anders, da hat die Idle-GC praktisch nichts aufgeräumt und die Schreibrate bricht sofort zusammen:



Bei so einer SSD bringt es dann natürlich auch nichts, etwas Kapazität unpartitioniert zu lassen, denn der Controller verteilt die Daten eben, wie Du richtig schreibst, über den gesamten NAND Beeich. Bei der m4 wäre der Abfall aber erst später eingetreten, wenn man ein zusätzliches Overprovisionung betrieben hätte.

Ansonsten empfehle ich Dir auch noch mal in diesen Thread zu schauen, wo es um das gleiche Thema geht. Wenn Du immer noch glaubst, dass die FW einzelner SSDs das Filesystem auswertet, dann solltest Du Dich mal fragen, wie es dann wohl funktioniert, wenn man das Filesystem softwaremäßig verschlüsselt (z.B. mit Truecrypt) oder die SSD in einem RAID einsetzt. Gerade letzteres wäre der Anfang einer Katastrophe, denn aufgrund des Strippings werden die LBAs in den Metadaten nicht mit denen der einzelnen Platten übereinstimmen und der Controller würde die falschen Daten löschen. Da auch jeder RAID Controller und jedes SW-RAID eine andere Struktur für die Verwaltungsdaten verwendet, könnte der Controller die kaum alle kennen.

 

[powerfx]

Das, was du als Non-Idle-GC bezeichnest, ist offensichtlich das Funktionsprinzip von MLC. Ist aber auch nicht so wichtig, das Thema ist nicht die fehlende GC der alten Controller, sondern die Dateisystem-basierende GC (und genau genommen ist selbst das schon OT).

Liegt ein TrueCrypt-Container auf der Partition, verhält er sich logischerweise wie eine normale Datei. Ist die ganze Partition verschlüsselt, ist von außen keine gültige MFT sichtbar und die Partition wird ignoriert. Gleiches bei Membern eines RAID 0-Verbunds.
WA und WL lasse ich außen vor, haben beide nichts damit zu tun.

Aus den Screenshots lässt sich nicht erkennen, dass sie auf einem anderen Dateisystem als NTFS ausgeführt wurden. Ich bin sogar relativ sicher, dass das Gegenteil der Fall war. Und genau dieses Gegenteil beweist auch zumindest das erste Bild, wo man mit zunehmender Performance die Arbeit einer GC orientiert am Dateisystem sieht.

Allyn Malventano von PC Perspective schreibt:

Samsung controllers with recent firmware take an entirely different approach. Without any interaction from the OS, the Samsung firmware is able to 'read' the drive data in the background. When the drive has been idle for a period of time, the firmware reads any NTFS volume bitmaps present and automatically frees up flash blocks not allocated by that partition. The end result is similar to using the Indilinx tool, but Samsung has the advantage in that it does not suffer from controller / driver incompatibilities and other OS-related issues. If a Samsung drive with auto-trim firmware contains an NTFS partition and is idle, it will automatically auto-trim itself in the background.

me&er von OCZ schreibt:

The Nand Laundering/Idle Time Garbage Collection will indeed be OS independent imo.. but the embedded commands in the FW that link it to the OS API (Application Programming Interface) must travel via the File System. So it must also be File System 'dependant'.

Und hier ist ein User bei dem die GC angeblich auf HFS+ nicht arbeitet.

Ich freue mich immer über Beiträge von dir, wenn du fundierte Begründungen hast. Ansonsten muss ich fast schon nach der Devise DNFTT gehen.

 

[Holt]

Das sind alte Artikel und selbst wenn das damals in der Zeit vor TRIM irgendwo von Indilinx oder Samsung implementiert war (ich haben keine von denen, kann das also nicht testen), so kann ich Dir doch sicher sagen: Keiner der aktuellen SSDs macht sowas heute noch.

Das Testen ist übrigens garnicht so schwer. Zuerst muss TRIM deaktiviert werden, logisch! Dann kopiert man ein paar größere Archive (zip, rar, 7z) drauf oder kann auch mit h2testw einfach einige größere Dateien darauf anlegen. Diese löscht man dann und nach einigen Stunden (soll ja angeblich 8 Stunden Idle brauchen, also Geduld) und versucht sie später mit Recoverytools wie Testdisk wieder her zu stellen. Dann prüft man, ob die noch heil sind und wenn ja, dann gibt es da keine Auswertung des Filesystems. Stehen nur noch Nullen drin, dann schon. Natürlich sollte es nicht die Systempartition sein und man dürfen auch keine anderen Schreibzugriffe oder Defragmentierung oder sowas auf der Partition stattfinden!

Ist Dir übrigens aufgefallen, dass alle Deine Links um OCZ SSDs gingen? Die haben angeblich schon so viele Sachen implementiert und am Ende hat von denen nichts auch nur annährend die vollmundigen Versprechen erfüllt. Nimm nur mal die „NDurance Technology“ in dem als eigenen Everest bezeichnete umgelabelten Marvell und vergleiche die Haltbarbeit der Octane oder Vertex 4 (mit Ndurance 2.0) im Dauerschreibtest auf xtremesystems.org mit der von anderen SSD ohne diese tolle Technik. Dazu musst Du aber die geschriebenen Datenvolumen durch die Kapazität teilen und dann sieht man, was an deren Versprechen dran ist.

 

[Hallo32]

@powerfx

Bei aktuellen SSDs findet kein Filesystem GC statt.

Deine Quellen beziehen sich auf sehr alte SSDs, deren Controller eine relativ geringe CPU Leistung hatten, welches in Kombination mit diversen Firmware Versionen zu einen nicht so positiven Ergebnis führte. Das Posting von Me&er bezieht sich darauf, dass sich eine Trim Funktion, wie sie es heute gibt, nur in Kombination mit der Unterstützung des Filesystem realisieren lässt, wobei dieses nicht bedeutet, dass die SSD das FS interpretiert.

Die ersten SSDs waren einfach zu früh auf dem Markt und von Seiten der Betriebssysteme, Treiber und Filesystemen fehlte noch die Unterstützung für Trim und die GC auf Basis von LBA hat ihre bekannten Nachteile.

Die heutigen Controller der letzten SSD Generation haben soviel Rechenleistung, dass diese parallel zu den seq. schreiben noch ihre GC ausführen können.

Unter Linux kann man diverse SSD Tests auch auf der unpartitionierten SSDs laufen lassen.

 

[powerfx]

Wenn es HD Tach so anzeigt (und es auch stimmt), ist es evtl. einfacher es damit zu überprüfen.

Da muss ich mal demnächst bei Gelegenheit schauen.

 

[Hallo32]

HD Tach is read only.

 

[Holt]

Hallo32, wie kommst Du auf die Idee? Hast Du die gleiche Version wie Anand sie benutzt und diese auch licensiert? Das Problem ist, dass die Bandbreite die HD Tach messen kann, für moderne SSD nicht mehr reicht und man daher nie mehr als so 360MB/s messen kann. Das Tool ist eigentlich echt ungeeigent für SSDs, aber für den Zweck für den Anand den einsetzt, geht es. Wer aber nur einen Lesetest macht, der bekommt damit nur Müll, weil eben vielen LBAs dann vermutlich keine Flashadressen zugewiesen sind.

 

[Hallo32]

Hey,

ich habe die Demo/Shareware Version genutzt. Das Studio Simpli Software scheint nicht mehr zu existieren, somit wird ein registrieren schwerer.

Oder muss das Testobjekt ohne Partitionstabelle sein?

 

[Holt]

Das es nur bei Platten ohne Partitionstabelle geht ist denkbar. Wenn die LBAs direkjt beschrieben werden, dann würden die Daten ja sowieso verloren gehen und dann wäre es eine Art Sicherung, wenn das nur bei Platten ohne Partitionstabelle geht.