Seite 1 von 2 1 2 LetzteLetzte
Ergebnis 1 bis 25 von 33
  1. #1
    Obergefreiter
    Registriert seit
    15.01.2012
    Beiträge
    66


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

    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. Externes 2,5" Gehäuse für SSD (intern 6GB/s) ?

    2. Externes 2,5" Gehäuse für SSD (intern 6GB/s) ?

    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.

  2. Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.

  3. #2
    Bootsmann
    Registriert seit
    24.08.2009
    Beiträge
    581


    Standard

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

  4. #3
    Obergefreiter
    Registriert seit
    15.01.2012
    Beiträge
    66
    Themenstarter


    Standard

    Zitat Zitat von VelleX Beitrag anzeigen
    .... 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.

    Samsung_64GB_DELL_USB3.0_82_TRIM_JA_SSDoctor_TRIM_ausgelöst.png

    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.

  5. #4
    SSD'ler Avatar von Stefan 008
    Registriert seit
    02.08.2003
    Beiträge
    1.891


    • Systeminfo
      • Motherboard:
      • Asus Maximus V Formula
      • CPU:
      • Intel Core i7-3770K
      • RAM:
      • 16GB DDR3 G.Skill RipJaws
      • Grafik:
      • Gainward Phantom GTX680 4GB
      • Storage:
      • jede Menge SSD's, keine HDD mehr
      • Monitor:
      • LG IPS 27 Zoll TM2792
      • Netzteil:
      • SeaSonic X Series 750
      • Betriebssystem:
      • Win7 x64

    Standard

    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.
    Geändert von Stefan 008 (20.01.13 um 09:19 Uhr)

  6. #5
    Stabsgefreiter Avatar von Inzersdorfer
    Registriert seit
    25.10.2012
    Ort
    Wien
    Beiträge
    327


    Standard

    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.

  7. #6
    SSD'ler Avatar von Stefan 008
    Registriert seit
    02.08.2003
    Beiträge
    1.891


    • Systeminfo
      • Motherboard:
      • Asus Maximus V Formula
      • CPU:
      • Intel Core i7-3770K
      • RAM:
      • 16GB DDR3 G.Skill RipJaws
      • Grafik:
      • Gainward Phantom GTX680 4GB
      • Storage:
      • jede Menge SSD's, keine HDD mehr
      • Monitor:
      • LG IPS 27 Zoll TM2792
      • Netzteil:
      • SeaSonic X Series 750
      • Betriebssystem:
      • Win7 x64

    Standard

    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

  8. #7
    Stabsgefreiter Avatar von Inzersdorfer
    Registriert seit
    25.10.2012
    Ort
    Wien
    Beiträge
    327


    Standard

    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.

  9. #8
    Obergefreiter
    Registriert seit
    15.01.2012
    Beiträge
    66
    Themenstarter


    Standard

    Zitat Zitat von Stefan 008 Beitrag anzeigen
    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
    Zitat Zitat von Inzersdorfer Beitrag anzeigen
    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?

  10. #9
    Avatar von Bob.Dig
    Registriert seit
    10.05.2007
    Ort
    127.0.0.1
    Beiträge
    10.552


    • Systeminfo
      • Motherboard:
      • ASUS Z97I-Plus
      • CPU:
      • Intel Core i5-4670K
      • Kühlung:
      • Noctua NH-D14
      • Gehäuse:
      • Cooltek U2 silber
      • RAM:
      • 8 GB Kingston ValueRAM
      • Grafik:
      • Inno3D GTX 760 HerculeZ 2000s
      • Storage:
      • 2x Samsung SSD 830 Series 128GB @ RAID0
      • Monitor:
      • Dell 2407WFP
      • Netzteil:
      • be quiet! Pure Power L8-CM
      • Betriebssystem:
      • Windows 8.1 wU + ClassicShell

    Standard

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

  11. #10
    Obergefreiter
    Registriert seit
    15.01.2012
    Beiträge
    66
    Themenstarter


    Standard

    Zitat Zitat von Bob.Dig Beitrag anzeigen
    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?

  12. #11
    Stabsgefreiter Avatar von Inzersdorfer
    Registriert seit
    25.10.2012
    Ort
    Wien
    Beiträge
    327


    Standard

    @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.
    Geändert von Inzersdorfer (20.01.13 um 12:09 Uhr)

  13. #12
    Obergefreiter
    Registriert seit
    15.01.2012
    Beiträge
    66
    Themenstarter


    Standard

    Zitat Zitat von Inzersdorfer Beitrag anzeigen
    ... 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.

  14. #13
    Stabsgefreiter Avatar von Inzersdorfer
    Registriert seit
    25.10.2012
    Ort
    Wien
    Beiträge
    327


    Standard

    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.

  15. #14
    Avatar von Bob.Dig
    Registriert seit
    10.05.2007
    Ort
    127.0.0.1
    Beiträge
    10.552


    • Systeminfo
      • Motherboard:
      • ASUS Z97I-Plus
      • CPU:
      • Intel Core i5-4670K
      • Kühlung:
      • Noctua NH-D14
      • Gehäuse:
      • Cooltek U2 silber
      • RAM:
      • 8 GB Kingston ValueRAM
      • Grafik:
      • Inno3D GTX 760 HerculeZ 2000s
      • Storage:
      • 2x Samsung SSD 830 Series 128GB @ RAID0
      • Monitor:
      • Dell 2407WFP
      • Netzteil:
      • be quiet! Pure Power L8-CM
      • Betriebssystem:
      • Windows 8.1 wU + ClassicShell

    Standard

    Wenn aber nicht getrimmt wurde, hat der Controller erst recht keine Veranlassung irgendetwas zu verschieben. Die Herangehensweise hier erinnert an die Verifizierung von Fernando, dass TRIM im RAID-0 bei intel (teilweise) funktioniert. Von daher wird es wohl so sein, dass SSDoctor über USB 3 (nur 3?) trimmen kann.

  16. #15
    Obergefreiter
    Registriert seit
    15.01.2012
    Beiträge
    66
    Themenstarter


    Standard

    Zitat Zitat von Bob.Dig Beitrag anzeigen
    ... 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.

    01_TRIM_über_USB3.0_JA_oder_NEIN_Filmdatei_logischer_Sektor_60486528.png
    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.

    07_TRIM_über_USB3.0_JA_oder_NEIN_Filmdatei_auf_Sektoren_noch_da.png
    Filmdatei im Root weg aber ab Sektor 60686528 noch da

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

    08_TRIM_über_USB3.0_JA_oder_NEIN_mit_SSDoctor_TRIM_ausgelöst.png
    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.

    11_TRIM_über_USB3.0_JA_Filmdatei_auf_Sektoren_gelöscht.png 13_TRIM_über_USB3.0_JA_Filmdatei_auf_Sektoren_gelöscht.png
    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.
    Geändert von JoWe (21.01.13 um 14:18 Uhr)

  17. #16
    Matrose
    Registriert seit
    10.08.2010
    Beiträge
    20


    Standard

    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

  18. #17
    Obergefreiter
    Registriert seit
    15.01.2012
    Beiträge
    66
    Themenstarter


    Standard

    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.

    LG_PCIIDE_Samsung64_eSATA_II_33_SSDoctor.png LG_PCIIDE_Samsung64_eSATA_II_22_EVerest.png

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

    LG_PCIIDE_Samsung64_eSATA_II_34_SSDoctor.png

    Beim Anschluß der SSD im IDE-Modus über eSATA funktionierte die Auslösung des TRIM-Befehls mittels - SSDoctor - ebenfalls.
    Geändert von JoWe (21.01.13 um 20:08 Uhr) Grund: Zum Einlesen SSDs an IDE

  19. #18
    Stabsgefreiter Avatar von Inzersdorfer
    Registriert seit
    25.10.2012
    Ort
    Wien
    Beiträge
    327


    Standard

    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.

  20. #19
    Obergefreiter
    Registriert seit
    15.01.2012
    Beiträge
    66
    Themenstarter


    Standard

    Zitat Zitat von Inzersdorfer Beitrag anzeigen
    ... 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.

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

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

    32_Sektor_der_gesuchten_Datei_auf_SSD_in_WinHex_ist_leer_Win7_TRIM_gewirkt.png 33_Sektoren_weiterer_gesuchter_Dateien_auf_SSD_in_WinHex_sind_leer_Win7_TRIM_hat_schon_gewirkt.png
    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.
    Geändert von JoWe (23.01.13 um 13:32 Uhr) Grund: Nachträgliche Korrekturen und Ergänzungen

  21. #20
    Obergefreiter
    Registriert seit
    15.01.2012
    Beiträge
    66
    Themenstarter


    Standard

    Zitat Zitat von JoWe Beitrag anzeigen
    ... 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'?

  22. #21
    Flottillenadmiral
    Registriert seit
    05.07.2010
    Beiträge
    5.172


    Standard

    Zitat Zitat von Inzersdorfer Beitrag anzeigen
    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.

    Zitat Zitat von Bob.Dig Beitrag anzeigen
    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.

    Zitat Zitat von Inzersdorfer Beitrag anzeigen
    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).

    Zitat Zitat von Inzersdorfer Beitrag anzeigen
    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.

    Zitat Zitat von JoWe Beitrag anzeigen
    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.

    Zitat Zitat von JoWe Beitrag anzeigen
    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.

    Zitat Zitat von JoWe Beitrag anzeigen
    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.

    Zitat Zitat von Inzersdorfer Beitrag anzeigen
    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.

    Zitat Zitat von Inzersdorfer Beitrag anzeigen
    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.

  23. #22
    Obergefreiter
    Registriert seit
    15.01.2012
    Beiträge
    66
    Themenstarter


    Standard

    Zitat Zitat von Holt Beitrag anzeigen
    ... 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.

  24. #23
    Banned
    Registriert seit
    31.12.2011
    Beiträge
    982


    Geändert von BerndH (12.02.13 um 11:42 Uhr)

  25. #24
    Obergefreiter
    Registriert seit
    15.01.2012
    Beiträge
    66
    Themenstarter


    Standard

    Zitat Zitat von BerndH Beitrag anzeigen
    ... 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?

  26. #25
    Flottillenadmiral
    Registriert seit
    05.07.2010
    Beiträge
    5.172


    Standard

    Zitat Zitat von JoWe Beitrag anzeigen
    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.
    Zitat Zitat von JoWe Beitrag anzeigen
    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).

    Zitat Zitat von JoWe Beitrag anzeigen
    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.

    Zitat Zitat von JoWe Beitrag anzeigen
    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.

Seite 1 von 2 1 2 LetzteLetzte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •