Sieben Mythen rund um SSDs: Was ist wahr, was ist falsch?

Rund um das Thema SSDs kursieren eine Vielzahl von Annahmen, Halbwahrheiten und regelrechten Mythen, die man besser nicht ohne Weiteres allesamt für bare Münze nehmen sollte. Wir fühlen den sieben populärsten Annahmen mal genauer auf den Zahn.

Wenn über SSDs gesprochen wird, dann geistert eine Vielzahl von Meinungen durch den Raum. Global betrachtet sind sie eine recht neue Erscheinung: Die ersten erschwinglichen Modelle erschienen ab 2008 - wenn man denn Preise von 900 Euro und mehr für ein 64 GByte großes Speicherlaufwerk als erschwinglich bezeichnen will. Aber in den letzten Jahren hat sich die Technologie schnell entwickelt (heute bekommt man eine gute 256-GByte-SSD beispielsweise schon für unter 100 Euro) und Ergebnisse aus alten Tests oder Erfahrungen aus dem Bereich der Festplatten lassen sich kaum auf die aktuellen Flash-Speicher übertragen.

Dennoch gibt es eine Vielzahl von Klischees rund um SSDs, die eine nähere Betrachtung verdienen und denen man nach wie vor immer wieder begegnet; etwa in Foren-Einträgen. Oftmals handelt es sich auch um nicht bzw. nicht richtig verstandene technische Zusammenhänge oder Wissen, dass sich noch aus den Anfangstagen der Speichertechnologie hält.

Auf den nächsten Seiten soll es um Annahmen wie "Benötigen SSDs weniger Energie als Festplatten", "Wird eine SSD über einen altenen SATA-Controller angebunden, bringt sie keinen Leistungsgewinn", "SSDs arbeiten lautlos", "SSDs müssen nicht defragmentiert werden", "Der Verschleiß bei SSDs ist ein Problem", "Bei SSDs lassen sich Daten leicht wiederherstellen" und "Das Verschlüsseln einer SSD verlangsamt den Rechner" gehen.

Auf den kommenden Seiten werden wir jeder dieser Thesen nachgehen und fragen, woher sie stammt und inwieweit sich die Annahme mit der Wirklichkeit deckt. Dabei werden wir generelle Aussagen treffen - und natürlich wird es immer Ausnahmen geben, die in einigen Punkten im Widerspruch dazu stehen. An dieser Stelle muss dann allerdings tatsächlich von einem Einzelfall ausgegangen werden, auf den wir nicht weiter eingehen werden.

Erstelle einen neuen Thread im Artikel-Forum über dieses Thema
Dieser Thread ist für Kommentare geschlossen
18 Kommentare
Im Forum kommentieren
    Dein Kommentar
  • fffcmad
    Punkt 5. Ist totaler Quatsch. Wie immer. Das Dateissystem hat Einfluss auf die Leistung. Fragmentierung frisst hier schon beim Zugriff I/O-Zeit. Und auch wenn es keine Schreiblesekoepfe gibt, so kostet das Herumspringen zu anderen Bloecken ebenfalls Zeit. Die Position der Daten ist jedenfalls nicht komplett zufaellig. (Im Groben sind die Daten alle zusammenhaengend abgelegt, wie an einer Perlenschnur, die großen Perlen sind jedoch zufaellig verteilt, macht aber bei der Groeße dann nichts mehr aus. Und hierbei handelt es sich nicht um Clustergroeßen im bereich von 4KB, sondern die Bloecke sind wesentlich groeßer, 256KByte oder 512Kbyte etc) Das Einzige was beim Defragmentieren ueberfluessig ist ist das Verteilen der Dateien in Geschwindigkeitszonen. Das Konsolidieren der Daten jedoch bringt I/O-Leistung zurueck und kann auch, je nach Leistung der SSD, wesentlich mehr Performance bringen. Wenn man eine extrem leistungsfaehige SSD hat merkt man es weniger. Da wird eher die CPU-Auslastung/ I/O-Wait ansteigen. Bei einer alten SSD jedoch kann es deutliche Geschwindigkeitsvorteile bringen, alle paar Monate mal zu Defragmentieren.

    Wie gesagt, das mit SSDs Defragmentieren beruht teilweise auf einem Artikel eines Schreiberlings, der damals einem Hersteller nur halb zugehoert hatte. Das beim Defragmentieren Schreibzyklen anfallen ist logisch. Zum Einen sollte man das natuerlich nicht alle paar Tage machen, zum Anderen halten auch moderne SSDs das locker aus. Im Prinzip ist das Defragmentieren von SSDs nur deswegen nicht von jedem Hersteller empfohlen. Das es keine Leistung bringt, ist jedoch dreckig gelogen!

    Und was hat TRIM mit diesem Thema zu tun? TRIM ist doch etwas vollkommen Anderes? Hier werden doch nur Bloecke von Altlasten befreit damit spaeter schnelller geschrieben werden kann, ohne vorher den Block auslesen und loeschen zu muessen?!

    Punkt drei ist ebenfalls nicht ganz richtig. Der SATA-Controller und sogar dessen Treiber haben ebenfalls massivenm Einfluss auf die Leistung. Das mit der Datenrate ist vollkommen richtig, aber der SATA-Controller kann sich auch negativ auf den I/O-Auswirken. Ist er traege und/ oder schlecht konzipiert kann auch der I/O-sinken. Wer will das. Den Unterschied kann man gut an Marvell/VIA/AMD und Intel-Implementationen dieses Standards sehen. Das betrifft dann auch HDDs.
    0
  • Big-K
    Ich hätte so gefragt: wenn es egal ist ob die daten verteilt oder zusammenhängend vorliegen, warum ist dann der schreibe/lese durchsatz sequenziell viel höher als bei random Zugriffen?
    Allesdings ist es schwirig zu sagen ob daten nach einer defragmentierung wirklich zusammenhängen da eigentlich nur Controller wirklich weis wo die Daten stehen und diese nach ganz anderen Vorgaben verteilt wie z.b. Abnutzung der Zellen usw.
    Also hat das etwas von einem Glücksspiel denn weder win noch die defrag Software weis wie die daten in Wirklichkeit verteilt sind.
    0
  • Mnyut
    Könnte man nicht sagen, so lange die Latenz der SSD kleiner ist als die I/O ist defragmentieren egal
    Die Samsung 840/850 SSDs haben z.B: eine Latenz von 7-11 µs. Das sollte ja für 142857 - 90909 I/O reichen?!
    Die Crucial MX10 liegt z.B. bei 29-56 µs, das reicht aber immer noch für 34482-17857 I/O.

    Ist eine SSD nicht ein Raid 0? Je mehr Chips desto besser, und sie müssen alle mit einem eigenen Kanal am SSD Controller angebunden sein. Dann kann schneller gelesen werden. Ist das so? Dann wäre Defragmentieren wirklich hinderlich -> je weitläufiger verteilt, desto besser.
    0
  • Tesetilaro
    es werden halt witzigerweise zugriffszeiten auf die linking table gespart und somit die i/o erhöht...

    beispiel: Datei 1 mit 700 MB wurde laut System FAT in 17 verschiedenen teilen der platte abgelegt, der SSD controller hat die aber real nur an 4 stellen gespeichert... Was passiert wenn die jetzt abgerufen wird?

    Der Controller muß aus dem flash, wo genau diese Verknüpfung zwischen den 17 virtuellen und 4 realen ablageorten liegen, genau 17 mal zugreifen...
    Wenn jetzt ein defrag, oder besser ein hersteller tool drüber läuft, das den anderen ansatz verfolgt wird es viel besser...

    Das Hersteller tool kann dem FAT des systems aber vorgaukeln daß die Datei jetzt an 4 orten liegt, es erfolgen also 4 zugriffe und nicht mehr 17...

    ist alles ziemlich komplex und nicht gut dokumentiert, weil solche dinge von den herstellern natürlich gut gehütet werden...

    Richtig ist aber auf jeden fall: bei einer schnellen SSD und einem sauberen window ist der Gewinn marginal bis nicht messbar, bei alten systemen sieht das anders aus...
    Weiterhin richtig ist, SSDs mit sandforce 2281 controller lassen sich datentechnisch NICHT wiederherstellen, bei vielen anderen ist es möglich...
    0
  • Tesetilaro
    Anonymous sagte:
    Könnte man nicht sagen, so lange die Latenz der SSD kleiner ist als die I/O ist defragmentieren egal
    Die Samsung 840/850 SSDs haben z.B: eine Latenz von 7-11 µs. Das sollte ja für 142857 - 90909 I/O reichen?!
    Die Crucial MX10 liegt z.B. bei 29-56 µs, das reicht aber immer noch für 34482-17857 I/O.

    Ist eine SSD nicht ein Raid 0? Je mehr Chips desto besser, und sie müssen alle mit einem eigenen Kanal am SSD Controller angebunden sein. Dann kann schneller gelesen werden. Ist das so? Dann wäre Defragmentieren wirklich hinderlich -> je weitläufiger verteilt, desto besser.


    vereinfacht ausgedrückt ist das tatsächlich so, wobei die controller üblicherweise 4-8 kanäle haben, die ssds aber 8 - 16 chips... wie dem auch sei, diese "raid" verwaltung macht die ssd auf jeden fall vollkommen unabhängig vom filesystem unter windows...

    das windows filesystem wird von der ssd mehr oder weniger als virtuelle schicht über die real ablage der daten drüber gelegt - die beiden werden mit einer linking table verknüpft... und sämtliche funktionen wie trim oder garbage collection oder wear leveling greifen auf diese linking table und die damit verbundenen mechanismen zu ;)
    0
  • fffcmad
    Anonymous sagte:
    Ich hätte so gefragt: wenn es egal ist ob die daten verteilt oder zusammenhängend vorliegen, warum ist dann der schreibe/lese Durchsatz sequenziell viel höher als bei random Zugriffen?
    Allesdings ist es schwirig zu sagen ob daten nach einer defragmentierung wirklich zusammenhängen da eigentlich nur Controller wirklich weis wo die Daten stehen und diese nach ganz anderen Vorgaben verteilt wie z.b. Abnutzung der Zellen usw.
    Also hat das etwas von einem Glücksspiel denn weder win noch die defrag Software weis wie die daten in Wirklichkeit verteilt sind.


    Zusammenhaengen im dem Sinne werden die Dateien nie. Aber man hat sie trotzdem in große Bleocke zusammengefasst bzw die Wahrscheinlichkeit ist hoeher, das alle Speicherkanaele des Controller von der SSD bei einer groeßeren Datei den Hit landen. (Was dann mehr Performance bedeutet) Einzelnde Zugriffe kosten immer mehr Zeit. Einmal bedingt durch das Dateissystem, und auch durch die Organisiation des Flash als RAID.


    Bzw. Das Defrag nicht weiß wie die Bloecke verteilt sind spielt ueberhaupt keine Rolle. (Komplett transparent) Der erste Vorteil besteht darin, das das Dateissystem weniger Aufwand hat (CPU/ I/O geringer) Der zweite darin, das bei groeßeren Dateiien eben zusammenhaengende Datenbloecke von dem SSD Controller mit mehr Performace ausgelsen werden koennen.


    Im Prinzip sind aktuelle Dateissystem komplett ungeeignet/ der Ansatz falsch. Die SSD muesste das Dateissystem verwalten und alle Schreib/ lesekommandos komplett selbst ausfuehren und verwalten koennen. Nur so kann die maximale leistung gewaehrleistet werden. Das wird aber wohl noch dauern. Obwohl es so etwas schon mit alten Diskettenlaufwerken gegeben hat. Ich sag nur Commodore 1541 &Co
    0
  • derGhostrider
    @Tese: Hast Du mal ein paar greifbare Tests, die belegen, dass "angeblich fragmentierte Dateien" tatsächlich langsamer von SSDs gelesen werden?
    Ich halte das für nicht nachvollziehbar.
    Wenn Du nämlich "defragmentierst", dann kann die Datei hinterher auf mehr reale Speicherbereiche in der SSD verteilten werden, als zuvor. Du hast einfach einen Einfluss und der Controller der SSD muss auf die Tabelle zugreifen, wo denn die Stückchen Deiner Datei rumliegen.
    Also: Defragmentieren bringt nichts.

    Und davon abgesehen: Nimm doch ein anständiges Dateisystem, welches in der Regel Dateien zusammenhängend schreibt. Dann gibt's auch keine unnötige Fragmentierung (aus der Sicht des Dateisystems! Was die SSD daraus macht, weißt Du eh nicht.)
    0
  • fffcmad
    @Ghost: Wieviel Speicher wuerde es kosten, wenn die SSD die Dateeien in so kleinen Bloecken zerschiesst sodass das Defragmentieren wirklich nichts mehr bringen wuerde... So 4K halt? Sry, Ghost, aber die Bloecke sind wesentlich groeßer, as i said: 256K, 512K usw. Du bekommst die Daten in diesen Bloecken also halbwegs zusammenhaengend. Wenn ueberhaupt muss der Controller halt nur noch ueber ein paar dieser Bloecke springen, aber kann seine Speichercontroller ausfahren und hat weniger Kommandos in der Pipeline die abgearbeitet werden muessen. Und natuerlich werden fragmentierte Dateien langsamer gelesen. Das Dateissystem erzeugt mehr AUfwand.

    Und ausserdem: Es gibt KEIN Dateissystem was die Fragmentierung der Daten bei normaler Nutzung des PC als Desktop/ Workstation ansatzweise verhindern koennt. Die Linuxer schwoeren da so gerne auf ihre 30 Stueck, aber keines davon kann das versprechen halten, die Daten zusammenhaengend zu lassen. KEINES! Schlimmer noch, dadurch das dort kein anstaendiges Defrag-Program existiert laufen diese Dateissysteme irgendwann wie der letzte Gruetz!
    0
  • derGhostrider
    Also abgesehen von ein paar Behauptungen kann ich nichts aus dem Beitrag entnehmen.
    Da auch im Dateisystem die Dateien nicht in winzigste Stücke zerteilt werden, gibt es keinen nennenswerten Mehraufwand. Natürlich kann man bestimmt eine SSD vollschreiben, dann winzige Dateistückchen löschen und den so erzeugten Flickenteppich wieder mit einer zusammenhängenden Datei auffüllen, damit man eure Befürchtungen durch einen haarsträubenden Test irgendwie unterfüttern kann.
    Aber die Dateisysteme sind nicht so dämlich, wie Du behauptest fffc. Und für den Fall, das eine Datei groß genug ist, so dass sie in Häppchen geschrieben wird: Halb so wild. Die Unterschiede werden i.d.R. im Rahmen der Messungenauigkeit liegen. Es würde mich ja nicht wundern, wenn alle Anfragen für die Datei direkt an die SSD gereicht werden und diese dann ihre Zugriffe selbst organisiert.

    Aber das müsste man erst genau testen, bevor man irgendwelche Behauptungen in den Raum stellt. Hier geht es ja schließlich nicht um sequentielle unabhängige Anfragen, von denen jede neue erst gestellt wird, wenn die vorherige abgeschlossen ist.
    BTW: Die Dateisysteme können sehr wohl ihre Versprechen halten. Solange es Zusammenhängende Kontingente gibt, in denen die Dateien geschrieben werden können, passiert das auch. Und mehr wird nicht versprochen.
    0
  • fffcmad
    @Ghost: Das Problem ist genau das, das ich das mit meinen SSDs nachvollziehen kann und konnte. Ich habe i520, i320, die Intel x25M oder wie sie alle heissen: Nach meheren Monaten Updates usw. werden die Prgrammstarts und das hochfahren traeger. Einmal grob defragmentieren: Flutscht. Die SSD kann Zugriffe natuerlich organisieren. Moderne SSDs gehen bei 4K Zugriffen bei einer hohen Queudepht ja auch gut ab.Trotzdem wird nicht die Performance erreicht, die man beim Lesen offensichtlich zusammenhaengender groeßer Bloecke hat. Ist auch vollkommen logisch. Die SSD arbeitet intern als RAID0. Und du weist wie ein RAID0 funktioniert oder? Und was soll das Dateissystem denn durchreichen? Das Dateissystem und die SSD haben voneinander keine Ahnung. Nur bei Festplatten weiß das Dateissystem grob, wo sich Daten physikalisch befinden. Bei SSDs natuerlich ueberhaupt nicht. Und genauso wenig weiß die SSD, was fuer Daten sich auf ihr befinden.

    Und wenn ich immer: im "Rahmen der Messungenauigkeit" hoere. Sry, das ist so dehn und auslegbar, da kommt mir immer was hoch bei xD
    0
  • Tesetilaro
    bleibt locker... ich habe ein paar messprotokolle gesehen, die ich aber nicht herzeigen kann und darf, die das verhalten was fffcmad beschreibt belegen, allerdings nicht in dem ausmaß, in dem er es beschreibt... weniger als 10 % Einbußen im Breich IOPs sind halt im Alltag nicht spürbar, meiner Meinung nach...

    ich selber habe es auch meßbar weder mit meinen samsungs noch mit meinen transcends reproduzieren können, liegt aber ggf. auch daran, daß meine SSDs nicht mal ansatzweise die 50 % füllgrenzen erreichen und ich mein system so sauber wie irgend möglich halte... ich bin da fast schon neurotisch...
    bevor ich was installiere wird ein image gezogen - taugt mir das programm nicht, wird es per recovery entfernt... aber wie gesagt, das ist mein privater spleen, weil ich nichts mehr hasse als ein sauber eingefahrenes system mit nem neuen win aufsetzen zu müssen *g*
    0
  • fffcmad
    Wir bleiben doch locker :D
    0
  • derGhostrider
    Ich muss mal anmerken, dass in letzter Zeit meine VM extrem träge geworden ist. Aber auch dann, wenn es nicht um IOs geht, sondern ganz primitive Dinge im Browser gemacht werden sollen...

    Vielleicht sollte ich ja auch mal defragmentieren. ;) Oder einfach einen trinken - dann ist der PC nicht schneller, aber es ist egal.
    0
  • Tesetilaro
    wenn der hersteller kein alternativtool hat, einmal ist keinmal... ;) Wobei du natürlich unbedingt checken solltest ob trimm ggf. auf der kiste nicht sauber läuft...

    wobei die idee mit dem bier auch sympathisch ist *g*
    0
  • Holt
    Natürlich hat die Fragmentierung Einfluss auf die Performance einer SSD, aber erst wenn sie extrem wird. Das hängt einfach damit zusammen, dass die Zugriffe ja nie länger als Fragment werden können und im Extremfall wird ein Fragment so kurz wie ein Cluster. Natürlich betrifft das immer nur die wirkliich fragmentierten Dateien, aber das ist bei HDDs nicht anders.

    Wer es nicht glaubt, der mache zuerst einen einfachen Test bevor er antwortet:
    1.) Eine Partition von z.B. 10GB auf einer SSD anlegen, formtieren, benchen mit z.B. dem AS-SSD Benchmark.
    2.) Die Partition mit lauter durchnummerierten 4k Dateien vollschreiben.
    3.) Jetzt jede Dateie mit einer ungreade Entziffer im Namen wieder löschen.
    4.) Erneut benchen
    5.) Defragmentieren, z.B. mit MyDefrag (vorher eine Anaylse machen) und erneut benchen.

    Wer dann alle drei Benchmarkscreenshots und den Screenshot von MyDefrags Analysen hochlädt, mit dem diskutieren ist das Thema gerne weiter, alle anderen dürfen weiter glauben, dass es ein Mythus ist.
    0
  • derGhostrider
    Natürlich kann man soetwas erreichen - aber das entspricht nicht der normalen Benutzung und ist daher irrelevant.

    Egal wie sehr / oft man "defrag" laufen lässt: Mit der Zuordnung der Speicherbereiche auf der SSD, auf die das OS und das Dateisystem keinen Einfluss haben, hat das nichts zu tun. Das wird einzig durch die Firmware bzw den Controller der SSD geregelt und dort durch Trim und automatische Reorganisation geregelt.

    ---

    BTW: Ein Defrag unter Server 2012 hat bei mir grob geschätzt 1/10s gedauert und gar nichts verändert. Abgesehen von der Anzeige, dass eine Defragmentierung nicht mehr nötig ist. ;)
    0
  • fffcmad
    Windows 2012 macht nur TRIM. Nicht so wie ich erst auch dachte eine Defragmentierung. Unter Windows 8/ 2012 kannst du nur im Abgesichertem Modus defragmentieren
    0
  • derGhostrider
    Hmmmm... Wenn mir mal langweilig ist. Aber da meine SSD nicht spürbar langsamer geworden ist, seitdem ich sie habe, sehe ich da auch keinen Grund für sinnfreie Schreibvorgänge auszulösen.
    0