Darstellungsversuch: TRIM-Auslösung bei USB 3.0 mit SSDoctor - Controller führt aus

[JoWe]

Hallo,

nach einigen Versuchen kann ich wohl nachweisen, dass das Programm - SSDoctor - den TRIM-Befehl auch über USB 3.0 an die im Versuch getestete SSD Samsung 830 64 GB gibt und nach dem Löschen über den Papierkorb, der Controller die im Versuch von einer bestimmten Datei zuvor belegten Zellen, löscht.

Anknüpften möchte ich hier:

1. http://www.hardwareluxx.de/communit...uer-ssd-intern-6gb-s-936130.html#post20052023

2. http://www.hardwareluxx.de/communit...uer-ssd-intern-6gb-s-936130.html#post20053555

Einige Personen werden sicherlich lächeln und meinen, dass das nicht funktioniert.

Ich aber glaube, dass meine Versuche und Analysen nachvollziehbar mit Screens belegen können, das TRIM über USB 3.0 - mittels SSDoctor ausgelöst - zur Löschung der zuvor beschriebenen Zellen über den Controller der SSD führt.

Um zu sehen in welchem Bereich der SSD eine Filmdatei durch Kopieren abgelegt wird, habe ich HDTunePro5.6 verwendet.

Den auf die SSD kopierten Film habe mir an verschiedenen Stellen angesehen und über HDTunePro gesehen mit welcher Geschwindigkeit an welchen Stellen gelesen wird.

Mittels Editor HxD habe ich danach zunächst die SSD und dann die Filmdatei geladen.

Aus der Filmdatei habe ich einen String fast am Ende der Filmdatei kopiert und über - Suchen - in der SSD diesen String gesucht und auch gefunden. Das ging innerhalb von 3 min, weil ungefähr in dem Bereich zu Suchen begonnen wurde, der durch HDTunePro 5.6 angezeigt wurde.

Danach habe ich den Film über den Papierkorb 'gelöscht'. Der Film war aber noch nicht aus den Zellen der SSD verschwunden. Mittels HexEditor habe ich den String schnell wiedergefunden.

Erst nachdem ich - SSDoctor - manuell veranlasste den TRIM - Befehl auf der SSD auszulösen, hat der Controller kurze Zeit danach, sein 'Werk' vollbracht. Der String war nicht mehr zu finden und der zuvor durch den Film belegte Bereich der SSD war sämtlichst mit NULLEN überschrieben.

Hoffe, dass einige Personen hierzu ihre Meinung schreiben, denn ich bin sehr an einer Diskussion interessiert.

Wenn entsprechende Meinungen und Fragen kommen, werde ich meine Meinungen nach und nach mit Screens untersetzen.

Wünsche ein schönes Wochenende.

 

[VelleX]

Naja, ich weiß natürlich nicht in wie weit das wirklich "Trim" ist. Eventuell schreibt das Programm nur selbst in den Bereich Nullen.

 

[JoWe]

.... Eventuell schreibt das Programm nur selbst in den Bereich Nullen.

Das Programm SSDoctor Solid State Doctor löst nur TRIM aus. Der TRIM-Befehl wurde nach manueller Auslösung so schnell auf die SSD gegeben, dass ich mit IrfanView in dieser Zeit noch nicht einmal einen Screen so erfassen konnte, das nur die Hälfte der Übertragung abgebildet ist.



Die Übertragung des TRIM-Befehls auf die SSD beträgt nur den Bruchteil einer Sekunde.

Würde SSDoctor die Zellen der SSD, in der die 2,2 GB große Filmdatei abgelegt war, sämtlichst mit NULLEN an dem 'schleichenden' USB3.0 überschrieben haben, hätte es dazu wesentlich länge Zeit benötigt. Das Programm selbst war nur sehr kurz tätig.

Es hat - wo auch immer auf der SSD - den Befehl zur späteren Ausführung von TRIM übertragen.

 

[Stefan 008]

Das SSD Doctor nur Trim auslöst kann aber irgendwie nicht sein , denn das würde voraussetzen das ein OS genutzt werden muss das den Trim Befehl weitergibt ( bei MS ab Win 7 ) . Auf der Download HP von Solid State Doctor steht aber das WinXP / Vista auch unterstützt wird ,wobei aber meines Wissens XP und auch Vista nichts mit Trim anfangen kann . Somit müsste das bedeuten das SSD Doctor selbst Hand anlegt und die SSD mit Nullen überschreibt .

Zitat von der HP Solid State Doctor

Supported Operating Systems:
Automated TRIM command supported under Windows XP SP3 32-bit, Windows Vista, Windows 7 and Server 2008 including both 32 and 64-bit versions with latest service packs on Microsoft file systems.

 

[Inzersdorfer]

Wobei es unerheblich ist, ob ein Betriebssystem etwas "mit Trim anfangen" kann, das ist ein ATA Befehl, der kann via Festplattentreiber oder einem Programm genausogut ausgelöst werden, die eigentliche Funktionalität ist ja auf dem Device selbst implementiert.

 

[Stefan 008]

Also ist es ein Tool das direkt mit den SSD's kommuniziert unabhängig vom verwendeten OS ? wie z.B. die Intel Toolbox bei Intel SSD's

 

[Inzersdorfer]

Das machen auch diverse SMART Tools, hdparm und dergl. mehr, und das auch bei USB Platten, von daher ist das möglich, ob das bei diesem Programm tatsächlich der Fall ist weis ich nicht.

 

[JoWe]

Also ist es ein Tool das direkt mit den SSD's kommuniziert unabhängig vom verwendeten OS ? wie z.B. die Intel Toolbox bei Intel SSD's

Das machen auch diverse SMART Tools, hdparm und dergl. mehr, und das auch bei USB Platten, von daher ist das möglich, ob das bei diesem Programm tatsächlich der Fall ist weis ich nicht.

Wie ist nachvollziehbar zu belegen, das die Auslösung von TRIM durch - SSDoctor - die Ursache für das Überschreiben der Zellen mit NULL (Löschen) war?

Der Controller der SSD macht die zu leerenden markierten Zellen ohne Befehl ja nicht automatisch frei. Wenn es so ist, wieso eigentlich nicht?

Der Controller würde die Zellen vor erneuter Belegung doch nur frei machen, wenn keine freien Zellen mehr da wären um beispielsweise eine Datei auf die SSD kopieren zu können. Irre ich mich etwa?

 

[JoWe]

Ja, wobei das sicher auch Controller abhängig sein könnte.

JA?? - Bitte um etwas mehr Erläuterung, denn ich möchte den Zusammenhang verstehen wenn etwas falsch ist.

Das der Controller Inhalte von Zellen 'umschaufelt' ist mir bekannt. Dies soll eine gleichmäßige Belastung aller Bereiche sichern.

Was also macht ein Controller im Detail?

 

[Inzersdorfer]

@JoWe: Wear levelling, da NAND Speicherzellen nur eine bestimmte Anzahl von Löschvorgängen aushalten, muß dafür gesorgt werden, das alle Zellen möglichst gleichmäßig abgenutzt werden. Löschen ist nur Blockweise möglich.

Das Problem hier: die vom Filesystem adressierten Bereiche werden vom SSD Controller virtualisiert. Welchen physikalischen Speicherbereich du hier nach dem "Trim" ausgelesen hast bleibt die Frage.

Vielleicht schlägt hier noch ein Experte auf, der hier etwas Licht ins Dunkel bringen kann.

 

[JoWe]

... Welchen physikalischen Speicherbereich du hier nach dem "Trim" ausgelesen hast bleibt die Frage. ...

Nach meiner Meinung in dem Bereich, der zuvor durch die noch nicht gelöschte Filmdatei belegt worden ist.

Ich hatte kurz hintereinander die Filmdatei kopiert, den Film an mehreren Stellen kurz bis zum Ende angesehen, mit HDTunePro erfasst an welcher Stelle auf der SSD gelesen wurde, vor dem Löschen und nach dem Löschen, im selben Bereich ausgelesen.

Nach HDTunePro ist die Filmdatei fast am Ende der SSD abgelegt worden. Nach dem TRIM war dieser Bereich vollkommen leer. Den Sektorenbereich habe ich mir vor dem Kopieren als auch nach dem Löschen angesehen und auch Screens davon gemacht. Es kann doch wohl nicht angenommen werden, das der Controller die Filmdatei in dieser kurzen 'Aufenthaltzeit' in andere Bereiche auf der SSD verschoben haben sollte.

Es wäre wirlich nett, wenn ein Fachmann - für Laien wie mich verständlich - darlegen könnte, was bei meinen Untersuchungen abgelaufen ist.

 

[Inzersdorfer]

Gemeint war, das die Dateien des Filmes natürlich am gleichen physikalischen Ort liegen, die entsprechenden Sektoren des NTFS aber auf einen freien Bereich der SSD zeigen. Das währe auch logisch im Hinblick auf das erwähnte Wear Levelling.

Du mußt die physische Ebene (der NAND Speicher der SSD) und die logische Ebene (das Filesystem NTFS) getrennt sehen, wo welche Sektoren des NTFS tatsächlich liegen, weis nur der SSD Controller.

 

[JoWe]

... Von daher wird es wohl so sein, dass SSDoctor über USB 3 (nur 3?) trimmen kann.

Ich denke, dass ich jetzt nachweisen kann, dass das Programm - SSDoctor - tatsächlich nach manuellem Auslösen des TRIM-Befehls zur Ausführung des Löschens durch den Controller führt.

Verwendet habe ich jetzt das Programm WinHex. Es ist zu sehen, das im Root eine Filmdatei ab dem logischen Sektor 60686528 liegt.


Filmdatei ab dem logischen Sektor 60686528

Nach dem Löschen der Filmdatei im Papierkorb und neuem Einlesen der SSD war nur der Eintrag der Filmdatei im Root weg. Nach Suche des Sectors war zu sehen, das die Filmdatei ab Sektor 60686528 noch da war. Nur der normale Löschbefehl über den Papierkorb hat also nicht die Filmdatei gelöscht.


Filmdatei im Root weg aber ab Sektor 60686528 noch da

Deshalb wurde mit SSDoctor der TRIM-Befehl manuell ausgelöst.


TRIM-Befehl manuell ausgelöst

Nach erneutem neuen Einlesen der SSD im Programm WinHex und der Suche ab dem Sektor 60686528 ist zu sehen, das die Filmdatei gelöscht wurde.


die Filmdatei wurde durch den Controller gelöscht

Es scheint als würde das Programm SSDoctor nach dem Anmelden bei Win7 und bei WinXP automatisch den TRIM-Befehl an alle erreichbaren SSDs senden.

Alles was löschbar ist scheint gelöscht zu werden. Wenn später wieder gelöscht wird geschieht nichts. Man muss bis nach der nächsten Anmeldung am jeweiligen System warten oder löst bei großen Datenmengen den TRIM-Befehl manuell aus.

 

[rony12]

was mich interessieren würde, ob sich TRIM dann auch durch IDE schicken lassen würde.

Ich will eine Samsung mSATA SSD in einen laptop mit ZIF verbauen. Dafür gibt es Adapter, jedoch hat es mich bisher davon abgehalten, da ich angst hatte, dass die SSD einfach nach einiger zeit unerträglich langsam wird

 

[JoWe]

Hallo,

ob es an Ihrem Laptop funktioniert kann ich nicht sagen.

Längere Zeit hatte ich den von mir genutzten LG S510 mit WinXP_Pro noch im IDE-Modus betrieben.

Ich hatte die SSD über USB3.0 bzw. über eSATA_II angeschlossen.

Der TRIM - Befehl über - SSDoctor - ging auch im IDE - Modus durch. Nur weiß ich nicht mehr ob es über USB3.0 und/oder eSATA war.

Zu dieser Zeit hatte ich noch nicht erkannt, dass ich mit einem HexEditor das Löschen der Datei durch den Controller nach Auslösung von TRIM durch - SDDoctor - nachweisen kann.

Jetzt habe ich von IDE auf AHCI umgestellt und möchte die 'Plackerei' zurück auf IDE nicht nochmals erleben.

Möglicherweise können andere Personen genauer mitteilen ob - SSDoctor - auch im IDE-Modus den TRIM-Befehl auslösen kann.

Sie sollten sich eine SSD ausborgen, die Testversionen von SSDoctor und WinHex herunterladen und alles auszuprobieren.

Nur so lässt sich sicherer feststellen ob TRIM - ausgelöst über SSDoctor - an den genutzten Konfigurationen funktioniert.

Hier noch einer von vielen Links zu SSDs an IDE :

Frage: Fragen zum Betrieb einer SSD

Ergänzung:

Ich habe noch Screens zum Anschluß der Samsung64GB über USB3.0 im IDE-Modus am LG S510 gefunden.



Auch hier funktionierte die Auslösung von TRIM mittels SSDoctor.



Beim Anschluß der SSD im IDE-Modus über eSATA funktionierte die Auslösung des TRIM-Befehls mittels - SSDoctor - ebenfalls.

 

[Inzersdorfer]

Wie schon geschrieben sind die Winhex Screens kein Beweis, Winhex arbeitet auf Filesystemebene und hat keinen Zugriff auf den Physikalischen Speicher der SSD. Im Übrigen glaube ich mich zu erinnern, das gelöschte Zellen mit FF und leere mit 00 angezeigt werden.

 

[JoWe]

... Im Übrigen glaube ich mich zu erinnern, das gelöschte Zellen mit FF und leere mit 00 angezeigt werden.

Diesmal habe ich - SSDoctor - nicht verwendet. Ich wollte sehen welchen Inhalt die Speicherzellen der SSD haben, wenn Win7 den TRIM - Befehl ausgelöst hat. Win 7 löst den TRIM - Befehl sofort aus, wenn der Papierkorb geleert wird. Der Controller der SSD reagiert umgehend.

Die Samsung 64GB habe ich an eSATA II angeschlossen, da über einen USB3.0 - Anschluß der Win7 - TRIM - Befehl nicht beim Controller der SSD ankommt.

Prinzipiell sind die Ergebnisse von Win7 - TRIM und SSDoctor - TRIM gleich. Bei SSDoctor wird der TRIM-Befehl nur nicht nach allen Leerungen des Papierkorbes ausgelöst. Wenn viel geschrieben wird, muss man eben zusätzlich manuell den TRIM-Befehl auslösen.

Mittels WinHex und ohne SSDoctor ist nachfolgend zu sehen, das der Hauptordner - Foto_Ausschnitte - und die Unterordner beispielsweise - Urlaub - nicht mehr zu sehen sind. Ebenfalls sind die darunter mal gelegenen Dateien nicht mehr zu sehen.

Über die Sektorsuche aufgesuchte Stellen zu mehreren Dateien auf der SSD sind ebenfalls leer (mt NULLEN überschrieben).

Der über Win7 ausgelöste TRIM - Befehl hat also dazu geführt, das der Controller sofort nach der Löschung des Haupt- und der Unterordner sowie der einzelnen darunter liegenden Datein, die Zellen die zuvor belegt waren, gelöscht hat.


Ordner - Urlaub - unter Ordner - Foto_Ausschnitte -
in WinHex auf SSD (an eSATA_II angeschlossen) festgestellt.


Der Controller der SSD hat den Ordner - Foto_Ausschnitte -
und sämtliche Unterordner sofort löscht.


Der Controller der SSD hat sämtliche unter den Ordnern mal abgelegten Dateien löscht.

Sie sollten bitte den Inhalt des nachfolgenden Links durcharbeiten:

AnandTech.com - TRIM & RAID-0 SSD Arrays Work With Intel 6-Series Motherboards Too

Schlussfolgerung:

- die durch den Controller der SSD frei gemachten (gelöschten) Zellen werden mit 00 überschrieben
- SSDoctor gibt TRIM - wie weiter oben beschrieben - wirksam an die Controller von SSDs weiter

- Besonderere Vorteile von SSDoctor an den von mir getesteten Systemen:

a) auch bei an USB3.0 -Hubs angeschlossenen SSDs wird der TRIM-Befehl wirksam auf die Controller der SSDs übertragen
b) sogar in XP-Systemen wird der TRIM-Befehl auf die SSDs an SATA, eSATA und USB3.0 übertragen
c) in Win7 und XP - Systemen ist kein zeitweiliges Umstecken von USB 3.0 an eSATA mehr erforderlich

An USB2.0 habe ich nicht getestet, weil aus meiner Sicht der Anschluss einer SSD an USB2.0 wenig Sinn macht.

Der TRIM-Code - über SSDoctor abgegeben - wirkt sicherlich nicht in allen Win7 und XP-Systemen. Ab bestimmter Chip-Typen schon.

Wichtig war mir, dass ich für mich den Nachweis erbringen konnte, das mittels SSDoctor die SSDs an USB3.0 nicht mehr 'einbrechen' und sogar mit Win XP gut funktionieren.

SSDoctor funktioniert allerdings nicht bei der von mir getesten Corsair P 64. Möglicherweise auch bei einigen weiteren Typen nicht.

Wer Lust hat kann das hier Beschriebene an seinen Systemen testen.

 

[JoWe]

... Wichtig war mir, dass ich für mich den Nachweis erbringen konnte, das mittels SSDoctor die SSDs an USB3.0 nicht mehr 'einbrechen' und sogar mit Win XP gut funktionieren.

SSDoctor funktioniert allerdings nicht bei der von mir getesten Corsair P 64. Möglicherweise auch bei einigen weiteren Typen nicht. ....

Mir ließen die Ergebnisse der bisheren Tests keine Ruhe. - SSDoctor funktioniert tatsächlich bei den Samsung SSDs an USB 3.0.

Ich hatte gelesen, das O&O auch TRIM-Befehle sendet.

O&O Version 14 sendet nach dem Bericht zwar TRIM-Befehle, aber bei den SSDs am USB3.0 kommen diese Befehle nicht an. Dies habe ich mit WinHex überprüft. Im Ergebnis ist keine andere Reaktion als beim Tool von Samsung zu sehen. Die SSDs werden von Migician noch nicht einmal an USB 3.0 - Anschlüssen erkannt.

Erst nachdem ich mit SSDoctor den TRIM Befehl bei der Samsung 830 64 GB an USB 3.0 ausgelöst hatte, war mittels WinHex zu sehen, das die Zellen leer waren.

SSDoctor funktioniert aber nach dem Systemstart nicht automatisch; zumindest habe ich nach erneutem Systemstart keine gelöschen Zellen im Bereich der zuvor aus dem Papierkorb gelöschten Dateien gesehen.

Erst nachdem ich wiederum den TRIM-Befehl manuell ausgelöst habe, waren die Zellen leer.

Feststellbar ist, das SSDoctor - wenn er geöffnet bleibt - die eingestellte Zeit bzw. mehrfach hintereinandner eingestellte Zeiten 'behält' und den TRIM-Befehl dann tatsächlich automatisch auslöst.

Vielleicht weiß jemand, wie man SSDoctor dazu bringen kann die Zeit für die automatische Auslösung nach dem Systemstart 'zu behalten'?

 

[Holt]

Wobei es unerheblich ist, ob ein Betriebssystem etwas "mit Trim anfangen" kann, das ist ein ATA Befehl, der kann via Festplattentreiber oder einem Programm genausogut ausgelöst werden, die eigentliche Funktionalität ist ja auf dem Device selbst implementiert.

So ist es, aber die Befehle müssen auch zur SSD durchkommen und da sind schon bei intern verbauten SSD erst mal der Treiber und dann der SATA Host Controller im Weg. Bei beiden ist es leider nicht unüblich, dass die Entwickler ihnen unbekannte Befehle nicht weiterreichen und der TRIM Befehl ist erst später in den ATA Befehlssatz aufgenommen worden. Es hängt also letztlich davon ab, was der Entwickler sich als Reaktion auf Befehle ausgedacht hat, die er nicht kennt: Sperren oder Durchlassen.

Ja, wobei das sicher auch Controller abhängig sein könnte.

S.o. denn genauso ist es und gerade bei USB-SATA Bridges gibt es da sogar teils schon mit dem Auslesen der S.M.A.R.T. Attribute oder der Drive ID.

Das Problem hier: die vom Filesystem adressierten Bereiche werden vom SSD Controller virtualisiert. Welchen physikalischen Speicherbereich du hier nach dem "Trim" ausgelesen hast bleibt die Frage.

Nein ist es nicht, denn wenn eine LBA beschrieben wird, dann wird ihre eine Flashadresse zugeordnet, in der die Daten stehen. Selbst wenn das Wear-Levelung diese Daten umkopiert um den Block löschen zu können in dem die vorher standen, wenn wird dieses Mapping zwar aktualisiert, aber das bleibt nach außen transparent. Die Zuordnung von LBA und Daten bleibt so lange erhalten, wie der LBA nicht neu beschrieben oder getrimmt wird (mit Ausnahme einiges alten Samsung Controller, die tatsächlich die Metadaten des NTFS interpretiert und die Daten die zu gelöschten Dateien gehört haben, dann auch gelöscht haben, was aber noch vor der 470er war und bei RAIDs zu Datenverlust geführt hat).

Vielleicht schlägt hier noch ein Experte auf, der hier etwas Licht ins Dunkel bringen kann.

Gerne doch! Mit dem Thema TRIM habe ich mich lange befasst und auch ein Tool geschrieben um dessen Funktion zu testen, mich aber am Ende aus verschiedenen Gründen entschlossen es nicht zu veröffentlichen. Im wesentlichen war der Ansatz den manuellen Test zu automatisieren und dann wollte ich noch die Kommunikation auf dem Controller abfangen und auf die SATA Befehle hin prüfen, eben weil es solche Fälle wie bei den alten Samsungs gibt und wenn man ein Tool veröffentlicht, dann muss es 100%ig richtige Ergebnisse liefern und nicht das war leider nicht möglich. Alleine schon, weil die unterschiedlichen SSDs teils sehr unterschiedlich und schwer vorhersehbar lange brauchen den TRIM Befehl wirklich umzusetzen. Ich habe 13 SSD zuhause und mit allen auf unterschiedlichen Plattformen getestet, aber man bräuchte noch viel mehr um eine halbwegs komplette Datenbank mit sinnvollen Parametern für wenigsten die verbreitetsten SSDs ausbauen zu können. Wenn es länger dauert und die SSD recht voll ist, muss man dann auch noch prüfen ob nicht inzwischen ein andere Schreibbefehl für die betroffenen LBAs ausgesendet wurde, weil denen ja sonst andere Daten zugewiesen werden und die SATA 3.1 erlaubt mit queued TRIM noch mehr Zeit für die Ausführung der TRIM Befehle.

Dann verstarb meine Vertex2 und ich habe überlegt, ob es mit dem Tool zusammenhängen könnte, aber ich schreibe, lösche und lesen ja nur, dass muss eine SSD ab können, aber wenn das nun einem Nutzer passiert? Da wurden meine Kreditkartendaten missbraucht und das Tool braucht nun einmal Administratorrechte, schon um auf das Physikalische Laufwerk zugreifen zu können und wenn das nun einem Nutzer passiert? Den Stress tue ich mir dann noch nicht an, denn wofür? Wenn ich das Programm verkaufen will, bedeutet das einen gewaltigen Aufwand alleine für die nötige Programmpflege, Inkasso, Steuern, etc. und selbst wenn ich einen Kopierschutz einbaue, hackt den früher oder später doch jemand und ich kann das Programm dann auch nicht in Foren empfehlen, weil das unmoralisch wäre. Bitte ich im Senden kommt doch nichts zusammen, denn jeder will es ja nur einmal kurz ausprobieren. Also wofür soll ich mir das Risiko eine Menge Ärger zu bekommen aufhalsen? Deshalb bleibt das bei mir auf dem Rechner und gut ist.

Ich hatte die SSD über USB3.0 bzw. über eSATA_II angeschlossen.

Es lassen nicht mal alle USB/eSATA Gehäuse die TRIM Befehle durch, selbst wenn diese über den eSATA Port angeschlossen sind. Da eine pauschale Aussage zu treffen ob es geht oder nicht halte ich für unmöglich, erst recht wenn die TRIM Befehle auch noch über USB gehen müssen.

Der TRIM - Befehl über - SSDoctor - ging auch im IDE - Modus durch. Nur weiß ich nicht mehr ob es über USB3.0 und/oder eSATA war.

Der IDE Modus von SATA steht den TRIM Befehlen nicht im Wege, Windows 7 trimmt auch SSD die im IDE Modus betreiben werden. AHCI sollte man wegen NCQ bei SSD verwenden, wegen TRIM ist das nicht nötig.

Nur so lässt sich sicherer feststellen ob TRIM - ausgelöst über SSDoctor - an den genutzten Konfigurationen funktioniert.

Sicher ist das auch nicht, denn es gibt einfach zu viele unbekannte in der Geschichte, s.o.

Wie schon geschrieben sind die Winhex Screens kein Beweis, Winhex arbeitet auf Filesystemebene und hat keinen Zugriff auf den Physikalischen Speicher der SSD.

Zu Winhex kann ich nichts sagen, da ich immer direkt von Physikalischen Device gelesen haben, aber das Filesystem sollte da nur Einfluss haben, wenn es die LBAs entweder gleich wieder überschriebt, was Windows i.d.R. nur im Notfall macht oder die LBAs der gelöschten Daten geändert wurden, wofür es keinen Grund gibt. Für die gängigen Filesysteme ist das Löschen einer Datein zunächst einfach nur das Setzen eines Flags in den Verwaltungsdaten und erst später wird das was überschrieben.

Im Übrigen glaube ich mich zu erinnern, das gelöschte Zellen mit FF und leere mit 00 angezeigt werden.

Das stimmt so nicht, es ist der SSD freigestellt, welche Daten sie zurück liefert, aber in alle Tests habe ich immer 00 bekommen. wenn TRIM funktioniert hat und den Inhalte der gelöschten Datei, wenn das nicht der Fall war. Oder halt was ganz anderes, wenn die LBAs zwischenzeitlich überschrieben worden sind. FF gab es aber nie zurück.

 

[JoWe]

... Es lassen nicht mal alle USB/eSATA Gehäuse die TRIM Befehle durch, selbst wenn diese über den eSATA Port angeschlossen sind. Da eine pauschale Aussage zu treffen ob es geht oder nicht halte ich für unmöglich, erst recht wenn die TRIM Befehle auch noch über USB gehen müssen. ...

... Zu Winhex kann ich nichts sagen, da ich immer direkt von Physikalischen Device gelesen haben, aber das Filesystem sollte da nur Einfluss haben, wenn es die LBAs entweder gleich wieder überschriebt, was Windows i.d.R. nur im Notfall macht oder die LBAs der gelöschten Daten geändert wurden, wofür es keinen Grund gibt. Für die gängigen Filesysteme ist das Löschen einer Datein zunächst einfach nur das Setzen eines Flags in den Verwaltungsdaten und erst später wird das was überschrieben. ....

... aber in alle Tests habe ich immer 00 bekommen, wenn TRIM funktioniert hat und den Inhalte der gelöschten Datei, wenn das nicht der Fall war. Oder halt was ganz anderes, wenn die LBAs zwischenzeitlich überschrieben worden sind. FF gab es aber nie zurück.

Vielen Dank für Ihre Erläuterungen!

Schauen Sie sich bitte meine Ausführungen mit den Screens zu WinHex weiter oben an.

Es ist zu sehen, dass die vorher belegten Zellen auf der SSD nach dem Auslösen von TRIM durch SSDoctor und in dessen Folge dem Regieren des Controllers der SSD - Löschen der Zelleninhalte - der TRIM-Befehl auch an USB 3.0 durchgekommen sein muß.

Wenn der TRIM-Befehl nicht durchgekommen wäre, hätte der Controller nicht regiert. Was soll sonst die Ursache für das Löschen sein?

Der Platz - der vorher noch durch Daten belegt war - ist kurz nach Auslösung des TRIM- Befehls mittels SSDoctor - auch über USB3.0 - durch den Controller der SSD freigemacht worden.

Die noch vor einem erneuten Überschreiben frei gemachten Zellen werden bei neuen Kopieren von Dateien auf die SSD mit neuen Werten überschrieben.

TRIM - ausgelöst durch SSDoctor - funktioniert demzufolge an USB 3.0 in Win7 und XP-Systemen mit entsprechenden Intel-Baugruppen.

Für die Foto, Film- und Dokumentenbearbeitung (pdf) ist diese Feststellung wichtig.

Man braucht die System SSD für solche Arbeiten - noch dazu wenn diese sehr häufig sind - nicht zu verwenden. Diese Arbeiten lassen sich extern an USB 3.0 erledigen und schonen die System-SSD.

Der eSATA_II - Anschluss ist so für anderweitige Arbeiten frei.

 

[BerndH]

http://www.hardwareluxx.de/community/f227/ssd-ultradrive-supertalent-ocz-vertex-ssd-indilinx-barefoot-controller-part-8-2-a-687982-43.html#post13797616



TRIM-Tools gibt es schon lange.

 

[JoWe]

... TRIM-Tools gibt es schon lange.

Hat das jemand bezweifelt?

Seit wann ist aber bekannt, dass es 'fremde' TRIM-Tools gibt, mit denen man an SSDs über USB 3.0 den TRIM-Befehl geben kann, dieser wirksam durchgeht und in dessen Folge der Controller das Löschen von Zellen tatsächlich vornimmt?

Beispielsweise kann das Samsung eigene Tool selbst mit Samsung - SSDs an USB 3.0 nichts anfangen!

Weshalb ist das so?

Soll man etwa an Notebooks mehrere SSDs für verschiedene Arbeiten extern ohne die Vorzüge von TRIM nicht einsetzen können?

 

[Holt]

Es ist zu sehen, dass die vorher belegten Zellen auf der SSD nach dem Auslösen von TRIM durch SSDoctor und in dessen Folge dem Regieren des Controllers der SSD - Löschen der Zelleninhalte - der TRIM-Befehl auch an USB 3.0 durchgekommen sein muß.

Das TRIM USB nie funktioniert, habe ich nicht behauptet, aber es muss vom USB Host Controller und dem USB-SATA Bridgechip unterstützt werden. Windows 7 schickt eben keine TRIM Befehle an SSDs die über USB angebunden sind, sofern MS das nicht inzwischen nachgerüstet hat.

Wenn der TRIM-Befehl nicht durchgekommen wäre, hätte der Controller nicht regiert. Was soll sonst die Ursache für das Löschen sein?

Das Nullen für die LBAs ausgelesen wurden, zeigt dass entweder die TRIM Befehle angekommen sind oder der Controller das Filsystem selbst auswertet, was Du mit der Gegenprobe schnell herausfinden kannst (Löschen, nicht trimmen und prüfen ob die Daten auch noch nach Stunden im Idle dort bleiben).

Der Platz - der vorher noch durch Daten belegt war - ist kurz nach Auslösung des TRIM- Befehls mittels SSDoctor - auch über USB3.0 - durch den Controller der SSD freigemacht worden.

Das ist eine zu weitreichende Schlußfolgerung, denn ob die Daten im Flash gelöscht sind oder nur die Verknüpfung der LBAs zu den Daten im Flash aufgehoben wurde, kann man nun beim besten Willen nicht feststellen. Das ist aber auch egal, denn es zeigt so oder so an, dass die TRIM Befehle angekommen sind.

Die noch vor einem erneuten Überschreiben frei gemachten Zellen werden bei neuen Kopieren von Dateien auf die SSD mit neuen Werten überschrieben.

Nicht die selben Zellen, aber die LBAs und auch die nur, wenn das Filesystem diese wieder als Ablageort für die neuen Dateien auswählt.

 

[JoWe]

Das TRIM USB nie funktioniert, habe ich nicht behauptet, aber es muss vom USB Host Controller und dem USB-SATA Bridgechip unterstützt werden. Windows 7 schickt eben keine TRIM Befehle an SSDs die über USB angebunden sind, sofern MS das nicht inzwischen nachgerüstet hat.

Bezüglich der Durchreichung von TRIM auch an USB3.0 hatten Sie sich so deutlich aber nicht bekannt.

Das Win7 an SSDs, die an USB3.0 angeschlossen sind, keine TRIM-Befehle schickt, ist nachgewiesen.

Deshalb habe ich ja nach Tools gesucht, die das können. Leider habe ich nur eines gefunden, welches TRIM-Befehle an verschiedene SSDs an USB3.0 schicken kann.

... Das Nullen für die LBAs ausgelesen wurden, zeigt dass entweder die TRIM Befehle angekommen sind oder der Controller das Filsystem selbst auswertet, was Du mit der Gegenprobe schnell herausfinden kannst (Löschen, nicht trimmen und prüfen ob die Daten auch noch nach Stunden im Idle dort bleiben).

Das habe ich alles getestet. Auch nach Stunden der Ruhe waren die Zellen noch beschrieben. Erst nachdem ich manuell mit SSDoctor TRIM auslöste, hat der Controller die Zellen frei gemacht.

 

[Holt]

Diese Auswertung des Filesystems machen nach meinem Wissen auch nur einige alten Samsung Controller mit der passenden FW noch aus der Zeit vor TRIM und bevor Samsung selbst am Retail Markt aktiv war. Die sind aber in alten SSDs u.a. von Corsair und OCZ zu finden. Da diese alten SSDs dann gerne noch mal in einem USB Gehäuse verwertet werden, sollte man darauf also auch achten, bevor mal sich über ein funktionierendes TRIM freut.

 

[JoWe]

Danke für den Hinweis!

Ich habe nur eine neuere Samsung SSD 830 128 GB und eine Samsung 830 64GB, sowie eine neuere Kingston SVP100S2 128GB und eine alte Corsiar 60 GB getestet.

Bis auf die Corsiar, bei der kein TRIM-Zugang über SSDoctor möglich war, obwohl diese TRIM unterstützt, kann ich mich also über ein funktionierendes TRIM an zwei verschiedenen Systemen (Win7Pro und XP Pro) an eSATA II und USB 3.0 freuen.

MfG
JoWe

 

[JoWe]

Hallo,

im Beitrag 24 - http://www.hardwareluxx.de/communit...ontroller-fuehrt-aus-938853.html#post20180622

hatte ich noch geschrieben, dass das Samsung eigene SSD - Tool an USB 3.0 die eigenen SSDs nicht erkennt. Das war das Tool in der Version 3.2.

Das neue Samsung Tool 4.0 erkennt jetzt aber eigene und andere SSDs an USB 3.0 Anschlüssen.

An USB 3.0 dauert die Ermittlung der Benchmarks - wegen der fehlerhaften Hardware USB 3.0 am DELL - sehr lange.

Dieses Samsung Megician - Tool 4.0 kann an SSDs (auch eigene) am USB 3.0 - Hub aber immer noch nicht den TRIM - Befehl senden.

Da bleibt bisher nur der SSDoctor.

 

[GVR797TO]

SSDoctor

sicher dass es eher nazimäßig SSDoktor und nicht SSDDoktor heißt?

 

[JoWe]

Wie kommen Sie auf diese Verbindung? - Da muss man schon weit und verquere um die Ecke denken.

Richtig heißt die Software SSD Utility. Irgendwo habe ich noch den Hinweis auf den 'Doctor' gelesen.

Wer es genau wissen will, kann in den anderen Beiträgen von mir, die Links zur Software anklicken und dort lesen.

Um Fehlinterpretationen vorzubeugen kann man das Utility gerne SSDDoctor nennen.

 

[GVR797TO]

Wie kommen Sie auf diese Verbindung? - Da muss man schon weit und verquere um die Ecke denken.

ich wollte das tool googlen und was da kommt sind SS-Doktoren, also relativ naheliegend