Push-Nachrichten von MacTechNews.de

Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?

Journals>Journals von xnor>Howto: Langsam gewordene SSDs wieder auf ursprüngliche Geschwindigkeit bringen - ohne die SSD zu löschen

Howto: Langsam gewordene SSDs wieder auf ursprüngliche Geschwindigkeit bringen - ohne die SSD zu löschen

Alle SSD leiden mehr oder weniger an dem Problem, dass sie mit der Zeit immer langsamer werden, insbesondere beim Schreiben. Das ATA-TRIM-Kommando kann dem abhelfen, aber Mac OS X unterstützt diesen Befehl (im Gegensatz zu Windows 7 und Linux) nicht.

Da ich in letzter Zeit immer größere Probleme mit der Schreibrate meiner Intel Postville 160GB SSD bekam, habe ich mich jetzt dem Problem angenommen.

Eine Möglichkeit ist es, die SSD komplett zurückzusetzen, wodurch alle Sektoren der Platte wieder als "leer" markiert wurden. Die Schreibrate ist nun wieder so schnell wie bei einer neuen SSD. Allerdings hat diese Methode natürlich den Nachteil, dass sämtliche Daten zuvor in Sicherheit gebracht werden müssen, was bei einer Boot-Platte ja auch nicht ganz einfach ist.

Eine weitere, deutlich einfachere Möglichkeit ist die neueste Version von hdparm 9.36 (http://sourceforge.net/projects/hdparm/), die mittlerweile auch das TRIM-Kommando für Apples HFS+-Partitionen unterstützt. Damit kann man auch ohne Datenverlust SSDs, die TRIM unterstützen (also mittlerweile fast alle) wieder auf ihre volle Geschwindigkeit bringen.

Warnung: Dies ist absolut nichts für Sissi-Macianer.

1. Schritt: Backup.
Da auch diese Methode die Gefahr birgt, dass sämtliche Daten über den Jordan gehen, braucht man auch hier ein Backup. Time Machine, SuperDuper, CarbonCopyCloner, egal. Hauptsache, der Migrationsassistent bietet das Backup als Wiederherstellungsquelle an (bei den drei genannten Möglichkeiten ist das der Fall).

2. Schritt: Ubuntu laden, brennen und booten.
Ubuntu gibt's auf http://www.ubuntu.com, momentan ist 10.10 aktuell; 32Bit reicht. Das ISO kann man mit den Festplattendienstprogramm brennen. Danach bootet man von der CD (oder DVD) durch Halten der Alt-Taste beim Booten und Auswahl der CD/DVD (auch wenn "Windows" druntersteht).
Wenn Linux gebootet hat, wählt ihr im Menü "Deutsch" und dann "Ubuntu testen".

3. Schritt: Root-Shell.
Im Menü findet man unter AnwendungenZubehör das Terminal. Führe dort erst

sudo bash

danach

wget http://share.tobibook.de/ssdtrim.sh

und schließlich

bash ssdtrim.sh

aus. Letzteres ruft mehrere Kommandos aus, was eine Weile braucht.

4. Schritt: TRIMmen
Am Ende des vorigen Schrittes wird der Befehl

./wiper.sh /dev/sda2

vorgeschlagen. Ich nehme hier an, dass das Device unter /dev/sda2 (erste Platte im System, zweite Partition (Standard bei Mac OS X)) zu finden ist.
Führe das entsprechende Kommando aus. Kommen keine Fehlermeldungen, kann man die Platte endgültig mit

./wiper.sh --commit /dev/sda2

TRIMmen.

5. Schritt: Neustart und warten
Nach einem Neustart sollte Mac OS X sollte wie üblich booten. Für die anderen Fälle haben wir ja noch ein Backup.
Lass dann der SSD etwas Zeit, damit sie sich in Ruhe neu organisieren kann - am besten über Nacht.

Fertig.

Meine Intel Postville 160GB vor der TRIM-Operation:

und danach:

---
Idee aus http://www.overclockers.at/apple/mac_os_x_und_ssd_215033?postid=3103851#post3103851 übernommen, die aktuelle Version hdparm 6.36 kommt aber auch ungepatcht mit Intel SSDs klar.

Kommentare

lenn109.12.10 09:53

Vielen dank ! Werde das mal testen:)

lenn109.12.10 10:46

Schade drum, ich kriege die Live-CD beim besten Willen nicht zum starten.
Es bleibt bei den Punkten mit dem Ubuntu Schriftzug. Hat jemand einen Tipp?

Habe ein Macbook Pro 13" 5,5

xnor09.12.10 11:01

Bei mir hing der Linux-Bootvorgang auch einmal; es lag dabei an einem eingesteckten USB-Stick - frag mich aber bitte nicht, warum.
Ich habe den Stick entfernt und einfach nochmal gebootet.

Auch MBP13 5,5

Macwolf309.12.10 11:29

Vielen Dank endlich eine Möglichkeit um meine ssd zu trimmen ohne das komplette Löschen usw... übrigens es hat bei mir ohne Probleme Funktioniert

X-Jo09.12.10 16:51

... dass sie mit der Zeit immer langsamer werden, insbesondere beim Schreiben.

Nur beim Schreiben.
Ich kann nach ~18 Monaten noch keinen Performance-Verlust feststellen.

Oliver N.09.12.10 16:57

... dass sie mit der Zeit immer langsamer werden, insbesondere beim Schreiben.

Ich dachte immer die Intel Postille SSD's haben GC (Garage Collection) integriert in ihrer Firmware um gelöschte Blöcke von sich aus wieder freizugeben.
Das war eigentlich DER Kaufgrund für mich, da nicht zwingend die TRIM Funktion vom Betriebsystem benötigt wird. Um so mehr wundert es mich nun das dies bei Dir nichts bringt, sonst wäre die SSD nicht mit der Zeit immer langsamer geworden.

xnor09.12.10 18:43

@X-Jo: Richtig.

@Oliver N.:
Wenn die SSD vom Betriebssystem keine Info darüber bekommt, welche Sektoren mit sinnvollen Daten belegt sind und welche nicht ("Garbage"), muss die SSD - um keine Daten zu verlieren - annehmen, dass alle Daten sinnvoll sind. Dadurch entsteht erst gar kein "Garbage", den die Garbage Collection entsorgen könnte, was diese Methode wirkungslos macht. TRIM liefert genau diese Information.

X-Jo09.12.10 21:27

xnor: das stimmt so nicht (mehr?).
Laut Wikipedia:

Praxistests zeigen, dass durch weiter verbesserte Firmware seit 2010 TRIM keinen messbaren Leistungsvorteil mehr bringt. Die laufwerksinterne Garbage Collection ist mittlerweile leistungsfähig genug.

Also: SSD-Firmware-Update auf neusten Stand (Garbage Collection) hilft dauerhaft.

xnor10.12.10 01:08

Ich habe eine Intel X-25M G2 Postville 160GB, die ich auf die aktuelle "HD"-Firmware gepatched habe.
Seitdem hat sie TRIM-Unterstützung, Garbage Collection konnte sie schon vorher.

Also hätte der Effekt bei mir gar nicht auftreten dürfen, wenn es wirklich keinen Unterschied machen würde. Hat es aber (siehe die Bilder im Journal).

Möglich, dass ich eine falsche Vermutung darüber habe, was Garbage Collection wirklich macht - schließlich rücken die Hersteller nicht damit raus, weil streng geheim.
Ich interpretiere aber meine Messergebnisse so, dass bei mir die Garbage Collection nichts gebracht hat und vermute stark, dass sie deswegen nichts bringen konnte, weil kein Block mehr als frei markiert war.

Ich lasse mich gern vom Gegenteil überzeugen, aber aktuell würde ich sagen, dass meine Messergebnisse meine These bestätigen.

xaibex10.12.10 08:47

Ich hab seit monaten eine Solidata SSD mit Indilinx controller welche ich sehr intensiv nutze, und konnte noch keinerlei Leisungsverluste wahrnehmen. Habe die Firmware ab kauf nicht verändert da die ausgelieferte bereits aktives GC hatte. Meine Schreib/Leserate ist ~ 180-190/230-240

eiq11.12.10 11:03

xnor
Wie schaffst du es, einer SSD, die maximal 100MB/s schreiben kann, eine Schreibrate von 180MB/s zu entlocken?

lenn111.12.10 11:06

Hab nun mal die 64 Bit Version geladen und mit 8x geschwindigkeit gebrannt. Nun hats auch funktioniert ! Prima meine SSD schreibt nun wieder von Anfang bis Ende mit voller Geschwindigkeit und nicht nur so sprunghaft

xnor11.12.10 12:12

@eig:
Ich habe jeweils im Festplattendienstprogramm die Funktion "freien Speicher löschen" angestoßen; diese Funktion ruft ihrerseits dd auf.
Ich habe mich aber ehrlich gesagt auch gewundert.

Macwolf311.12.10 15:30

noch ein kleiner Nachtrag, als ich bei meiner ssd mithilfe des FPDP den freien Speicher überschrieben hatte, Verstand ich paar Tage Später garnix mehr.
denn es war unmöglich das der Rechner nachdem er Hochgefahren war, nicht automatisch nach paar min. neustartete.
Offenbar war das mit dem überschreiben ein Schuss nach hinten denn als ich von der Mac OS X DVD startete sagte dort das FPDP das auf meiner SSD kein platz mehr sei.
ich Formatierte darauf hin und spielte ein TM Image zurück Ergebniss es hat nix gebracht. erst nachdem ich Trim durchgeführt hatte lief alles als wäre nix gewesen.
ob dies ein Einzelfall ist weiß ich nicht aber offenbar reicht das Eingebaute Trimmen nicht aus.

michaeldorner11.12.10 21:43

Super HowTo-Beitrag, danke!

hawaiihemd12.12.10 08:15

ich hab von meiner 160gb Postville nun noch 123GB frei und laut AJA Test eine Leserate von 221MB/s und eine Schreibrate von 103MB/s

habe nix getrimmt oder ähnliches, der Test spiegelt auch das gleiche Ergebnis wieder was ich am Anfang gemacht hatte als noch nichts installiert war.

@xnor wie voll ist denn deine SSD?

Blofeld13.12.10 12:57

weiß jemand, ob OS X irgendwannmal TRIM unterstützen wird?

Pase13.12.10 16:22

Wie sieht das den mit den Festplatten im Macbook Air aus?
ich nehme an bei denen ist das nicht möglich?

wingwing13.12.10 17:24

... warum sollte es mit dem Air nicht funktionieren?

- Ubuntu (oder ein anderes Linux-Derivat) könnte man doch ebenso per externer CD oder USB-Stick installieren/starten ...

X-Jo13.12.10 19:01

Blofeld

weiß jemand, ob OS X irgendwannmal TRIM unterstützen wird?

Siehe oben (09.12.10 21:27):

Wikipedia

Applecitronaut16.12.10 14:24

Wes wegen habe ich einen MAC? Damit ich genau dies nicht tun muss oder besser will. Diese herumgefrickele nerft einfach. *sick*

Holzauge sei wachsam :-)

xnor17.12.10 16:56

@hawaiihemd: Meine SSD ist über ein Jahr alt und war schon mehrfach bis zum Brechen voll. Bei mir hat sich die Prozedur auf jeden Fall gelohnt.

@X-Jo: Ich bin versucht, den Wikipedia-Artikel zu korrigieren, weil so stimmt das definitiv nicht. Mehrfaches Zitieren macht es auch nicht richtiger.

cpx19.12.10 10:44

Wie voll muss die SSD den werden damit die "langsamer" werden ?

Von meiner 120GB SSD sind noch 5.34GB frei und ich habe diese Probleme gar nicht.

Throx19.12.10 11:17

zum Garbage Collector, ich hab mal gelesen, dass er sowieso nur mit NTFS funktioniert. Die Firmware der SSD muss ja aus dem Dateisystem die Dateien, die gelöscht werden können (per Flag wohl gesetzt) überhaupt erkennen können. Klang für mich recht einleuchtend, wild kann die ja nichts löschen. Das heißt aber dann auch direkt dass der GC unter HFS+ nicht funktioniert und man Trim wiederum benötigt

Marcel Bresink19.12.10 14:30

Zum Journal-Artikel:
Das beschriebene Verfahren funktioniert, ich halte es allerdings für zu kompliziert. Wenn die SSD mit Garbage Collector ausgestattet ist, dann kann man exakt den gleichen Effekt durch Aufrufen des Punktes "Löschen > Freien Speicher löschen > Gelöschte Dateien mit Nullen überschreiben" in Mac OS X erreichen, ohne etwas sichern oder installieren zu müssen.

Throx:
Das ist leider alles nicht richtig. Keine Festplatte kann Dateisysteme erkennen. Überspitzt gesagt müsste dazu ja in die Platte ein leistungsfähigerer Computer eingebaut sein, als der, in dem die Platte steckt ...

Richtig ist: Ein Garbage Collector kann einen gelöschten Datenblock nur daran erkennen, dass das Betriebssystem auf diesen Block ein zweites Mal schreibend zugreift. "Normale" Löschoperationen, bei dem nur ein Ordnereintrag einer Datei gelöscht wird, kann ein Garbage Collector überhaupt nicht feststellen.

Trim dagegen erkennt jede Löschoperation, weil das Betriebssystem jeden freigegebenen Block noch einmal extra an die Platte meldet. Von daher ist im allgemeinen Fall Trim immer leistungsfähiger als GC, denn die Platte "weiß" nur bei Trim mit Sicherheit, welche Blöcke frei sind. Genau wie xnor halte ich den Wikipedia-Artikel und dessen Quelle nicht für glaubwürdig.

Ob man ein Einbrechen der Schreibrate einer SSD mit Mac OS X spürt, ist wieder ein ganz anderes Problem. Das hängt von den folgenden Faktoren ab:
1) Verwendet die SDD ein GC-Verfahren und wenn ja, wie gut ist es?
2) Wieviel Overprovisioning betreibt die Platte? (D.h. wieviel Speicher ist zusätzlich versteckt in die Platte eingebaut? In einer SDD mit 64 GB können z.B. tatsächlich 80 GB eingebaut sein, wobei der überzählige Speicher für abgenutzte Blöcke und Garbage Collection verwendet wird.)
3) Wie sieht das Nutzungsverhalten aus, insbesondere das Verhältnis zwischen der Anzahl der Löschoperationen, der Anzahl der Überschreiboperationen und der Anzahl der Schreiboperationen insgesamt?

Besonders Punkt (3) kann zu starken Unterschieden führen, selbst wenn das gleiche System und SSD-Modell verwendet wird. Bei einem Software-Entwickler, wo das Schreiben und Löschen mehrerer Zehntausend Dateien pro Stunde nicht ungewöhnlich ist, dürfte der Leistungseinbruch sehr viel höher sein, als wenn die SSD nur für Büro- oder Grafikanwendungen genutzt wird.

Throx20.12.10 17:42

Mir ist nicht ganz klar, warum man dazu ein leistungsfähigeren Computer brauchen müsste? Jede Kamera muss Verständnis des zugrunde liegenden Dateisystem besitzen, sei es FAT32, exFAT, etc... oder nicht?
Weiterhin würde mich interessieren, wie du dir die Funktionsweise des GC dann vorstellst, habe das aus deinem vorherigen Post leider nicht ganz rauslesen können. Angenommen er erkennt beim erneuten Schreibversuch, dass der Sektor vorher "Müll" war, wo schreibt er dann hin? In den zuvor definierten "Reservebereich" und löscht dann später im Idle den zuvor gefundenen Müll?

Marcel Bresink20.12.10 18:49

Mir ist nicht ganz klar, warum man dazu ein leistungsfähigeren Computer brauchen müsste?

Die SSD-Platte bekommt nur Schreib- und Lesebefehle für einzelne Blöcke der Platte mit. Sie hat keine Ahnung, was diese Befehle für einen Sinn haben, da sie außer dieser Befehlsfolge absolut nichts von dem Computer mitbekommt, in dem sie eingebaut ist. Sie weiß also nichts über Partitionen, Dateisysteme, Dateien, Ordner, Journaling, Bugs des Betriebssystems, etc. Die SSD müsste daher das Kunststück schaffen, nur anhand des Beobachtens "vorbeiziehender" Daten zu "erraten", ob diese Daten irgendetwas mit einer bestimmten Datei/Ordner/Partition usw. zu tun haben. Dazu müsste die SSD die komplette Plattenverwaltung des Betriebssystems in sich selbst noch einmal vollständig nachbauen und in Echtzeit jeden Schritt sozusagen mit einem zweiten Computer nachspielen. Das ist praktisch unmöglich.

Angenommen er erkennt beim erneuten Schreibversuch, dass der Sektor vorher "Müll" war

Das ist kein "Versuch", sondern ein zweites Schreiben auf einen bereits belegten Sektor. Der Schreibvorgang ist die Bestätigung, dass der Inhalt des Sektors Müll sein muss, denn das Betriebssystem braucht ihn offensichtlich nicht mehr.

wo schreibt er dann hin? In den zuvor definierten "Reservebereich" und löscht dann später im Idle den zuvor gefundenen Müll?

Ja, so ist es. Entweder in den Reservebereich oder in einen sowieso noch leeren Bereich.

hawaiihemd21.12.10 11:09

Das beschriebene Verfahren funktioniert, ich halte es allerdings für zu kompliziert. Wenn die SSD mit Garbage Collector ausgestattet ist, dann kann man exakt den gleichen Effekt durch Aufrufen des Punktes "Löschen > Freien Speicher löschen > Gelöschte Dateien mit Nullen überschreiben" in Mac OS X erreichen, ohne etwas sichern oder installieren zu müssen.

das hab ich jetzt mal getestet und es gab doch einen positiven Effekt, meine Leserate hat sich von 221 auf 241MB/s verbessert laut AJA Test.

aber gefühlt hat sich nichts geändert
aber danke für den Tipp

xnor21.12.10 17:53

@Marcel: Du sagst, das Löschen mit dem Festplattendienstprogramm reicht aus. Habe ich ausprobiert, hat kaum was gebracht. Nur 0en sind halt doch auch Daten und nicht "frei".

Deswegen habe ich nach Alternativen gesucht und sie in der beschriebenen Maßnahme gefunden.

Marcel Bresink21.12.10 18:13

Nur 0en sind halt doch auch Daten und nicht "frei".

Jein. Falls man das Verfahren auf einer SSD durchführt, deren Leistung noch nicht eingebrochen ist, besteht eine hohe Wahrscheinlichkeit, dass das Überschreiben mit Nullen freie Sektoren trifft, die danach belegt sind, also eigentlich das, was man nicht will. In diesem speziellen Fall müsste man das Ganze zweimal machen.

Wenn jedoch auf einer stark genutzten SSD der im Dateisystem als frei gekennzeichnete Raum mit Nullen überschrieben wird, dann wird man damit Sektoren treffen, die früher einmal belegt waren. Wie schon mehrmals erwähnt, ist jeder Schreibvorgang auf einen früher belegten Sektor das Zeichen an den GC, diesen Sektor auch aus Sicht der SSD als frei anzusehen.

Weitere Kommentare anzeigen

Howto: Langsam gewordene SSDs wieder auf ursprüngliche Geschwindigkeit bringen - ohne die SSD zu löschen

Kommentare

Kommentieren

Sie müssen sich einloggen, um diese Funktion nutzen zu können.