SSD ist ziemlich fragmentiert! - normal?

[chriscrosser]

hi
habe heute mal spasseshalber meine SSD (samsung 840) mit defraggler überprüft! (nicht! defragmentiert)
hatte ich schon ewig nicht mehr gemacht - und ich finde, das sieht schon ziemlich heftig aus! (fast 15 GB) - ist das normal?



habe nach infos hier aus dem forum inzwischen alles ausgeschaltet ("sogenannte optimierungen") inklusive dem samsung magician tool
hat jemand eine erklärung dafür!? - normal oder nicht? - einen performanceverlust habe ich noch nicht festgestellt (hochfahren / AS SSD Bench ist 24 punkte "langsamer" als vor 8 wochen)
thanx before
chriscrosser

 

[sasparilla]

liegt am wear-leveling des internen controllers der SSD-----> vollkommen normal.

 

[chriscrosser]

erst mal danke!
was bitte ist wear-leveling?


edit:
ich dachte, das durch das trimming die SSD immer optimal betrieben wird!? (gelöschte bereiche werden wieder neu beschrieben etc.)
hätte aber nicht gedacht, das hier so eine hohe fragmentierung entsteht - immerhin bis jetzt schon 15GB

 

[pinki]

und was ist daran schlimm? hast ja keine drehende scheibe von der die Daten zusammen gesammelt werden müssen.

 

[Holt]

liegt am wear-leveling des internen controllers der SSD-----> vollkommen normal.

Leider total falsch, denn das Wear-Leveling passiert intern und ist nicht von außen zu erfassen. Ein SSD Controller mappt die LBAs (also die nach außen sichtbare und angesteuerte Adressen) auf immer wieder andere Flashadressen, da man eben bei NAND Flash zwar eine Page (4k, 8k teils sogar schon 16k) lesen oder schreiben kann, vor dem Schreiben muss die Page aber gelöscht sein und man kann nur einen Block löschen, der aber typischerweise so 256 oder 512 Pages umfasst. Damit das nicht zu oft passiert, werden die Daten von LBAs die Überschrieben wurden, eben immer wieder in andere Pages geschrieben und das Mapping entsprechend aktuallisiert. Auf diese Mappingtabelle kann man aber kein Tool zugreifen oder diese auslesen, da die alleine intern vom SSD Controller verwaltet wird.

Das Wearleveling ist übrigens nur das Ergebnis des Algorithmus der auswählt, welcher Block jeweils gelöscht wird, das ist also keine eigene Funktion.

Was er da sieht ist die ganz normale Fragmentierung die bei jedem Datenträger durch das Löschen, Neuanlegen und vor allem durch das Wachsen von Dateien passiert. Je voller eine Partition ist, umso stärk tritt das und bei Windows Systempartitionen mit ihren vielen Logs und den Registrydateien die ja auch immer mehr anwachsen, ist es dort auch normal. Wenn eine Datei größer wird, so ist eben dahinter nur sehr selten genug Platz frei und die nächsten Sektoren werden dann vom Filesystem eben an eine andere Stelle geschrieben und schon hat die Datei ein Fragment mehr.

Bei HDDs ist das wirklich kritisch, weil Köpfe immer wieder auf die Anfänge der Fragmente plaziert werden müssen und das dauert eben ein paar ms. Bei SSDs gehen die Zugriffe so schnell, dass man das nicht bemerkt. Das allenfalls auftreten kann ist eine Verlangsamung wenn die Fragmente extrem klein sind, weil dann ja statt der langen sequentiellen und somit schnellen Zugriffe viel kurze Randomzugriffe erfolgen und diese sind halt langsamer. Das ist aber vergleichweise unkritisch für die Performance und wäre auch nur beim seq. Lesen einer großen Datei die in extrem kleine Fragmente unterteilt ist überhaupt spürbar.

 

[MoBo 01/04]

Dafür, dass das SSD optimal betrieben wird, sorgt der SSD-Controller mit etwas Unterstützung durch das Betriebssystem. Die Fragmentierung der Daten aus Sicht der vom Betriebssystem verwalteten logischen Blöcke ist bei jedem SSD mehr oder minder vorhanden und bedeutet nicht, dass die Daten tatsächlich derart fragmentiert im Flash-Speicher des SSD angeordnet sind. Selbst wenn es so wäre, ist das bei SSD für die Performance unbedeutend. Gängige SSD-Controller haben acht Kanäle, die parallel und nur in einem Bruchteil der Zeit, die HDD benötigen, auf die Daten zugreifen. Insofern kann man das, was HDD-Defragmentierungstools vermitteln, bei SSD getrost ignorieren.

 

[chriscrosser]

@Holt
@MoBo 01/04

danke für eure antworten!
also wenn ich das jetzt als laie richtig verstehe, heisst das, das das bei SSDs normal ist und ich nicht auf die idee kommen sollte die platte zu defragmentieren
oder?!
greetz
chriscrosser

 

[koaschten]

also wenn ich das jetzt als laie richtig verstehe, heisst das, das das bei SSDs normal ist und ich nicht auf die idee kommen sollte die platte zu defragmentieren

Richtig, SSD defragmentieren bringt nix und ist sogar abträglich für die Lebensdauer.

 

[Holt]

bedeutet nicht, dass die Daten tatsächlich derart fragmentiert im Flash-Speicher des SSD angeordnet sind. Selbst wenn es so wäre, ist das bei SSD für die Performance unbedeutend.

Die sind da sogar noch viel schlimmer fragmentiert, denn nur so lassen sie sich ja optimal über die ganzen Dies also Kanäle und Interleaves verteilen. Waren die alle schon nacheinander in einem Dies, so wäre die SSD viel langsamer, weil jedesmal die Zeit für die Adressierung anfallen würde. Dadurch das man die Daten die zusammenhängend geschrieben werden aber möglich über viele Dies verteilt, kann man möglichst viele Pages gleichzeitig adressieren und erhöht damit den Durchsatz.

Anandtech hat das hier mal gut erklärt und man sieht da schön, weshalb die Verteilung über viele Dies selbst am gleichen Kanal die Performance steigert. Das hat aber halt alles nichts mit dem zu tun, was das Filesystem sieht und damit Programme wie Defraggler zeigen.

Weiter oben habe ich was von "Daten die zusammenhängend geschrieben werden" geschrieben und das ist ja auch klar, denn wenn ich eine Datein nur in 4k großen Blöcken schreiben, dann landet jeder davon in einer anderen Page, aber der SSD Controller kann nicht beurteilen, ob diese nun zusammen gehören und daher auch zusammen wieder gelesen werden, also so verteilt werden sollten, das die möglichst schnell gelesen werden können. Da genau kann es nun beim Defragmentieren von SSD zu einem Performance Problem kommen (vor dem Haltbarkeit wegen der Schreibzugriffe mal abgesehen), denn beim Defragmentieren werden immer nur recht kleine Blöcke, teils nur einzelne Cluster, verschoben und damit geht für den SSD Controller der Zusammenhang großer Dateien kaputt und deren Daten werden u.U. nicht so performanceoptimal über die NANDs verteilt.

 

[chriscrosser]

hi!
ich nochmal!
frage: kann das eventuell damit zusammenhängen (fragmentierung) weil ich etwa alle 2 wochen ein backup einspiele (nach updates / sauberes system)???
beispiel: system ist sauber - dann kommen win updates etc. - ich installiere diese und mache ein backup - - -- kommen neue updates (andere zb: vlc, skype etc.) spiele ich das saubere backup auf, mache die updates und danach wieder ein aktuelles backup...
habe sozusagen immer eine "spielwiese" unter der ich sogar mal testen kann, was ein trojaner so macht, wenn man ihn (exe) anklickt

also: kann das mit dem zurückspielen regelmäßiger backups zu tun haben? (eigentlich macht acronis vorher alles platt auf der platte - zumindest war das bei HDD so)

thanx before
chriscrosser

ps: stöhn!!! hier in berlin sinds gerade 34 grad (in der wohnung "nur" 29)

 

[Holt]

Da die Backups ja wohl immer so zurückgespeilt werden, dass es 1:1 über die Partition gebügelt wird, hat das wohl keinen Einfluss. Die Fragmentierung entsteht auf jeder Windowssystemplatte mit der Zeit, denn es werden je eben bei den Updates immer wieder bestehende Dateien überschrieben und wenn die neue Datei größer als die alte ist, so muss sie entweder wowander gespeichert werden (was nur passieren kann, wenn die alten vorher gelöscht wurde) oder der Teil am Ende für den kein Platz mehr da ist muß eben woanders landen, was immer dann passiert, wenn man die Datei direkt überschreibt. Bei log Dateien und vor allem der Registry, die ja auch immer weiter anwachsen, ist es das gleich.

Manche Dir darum keine Sorgen, dass ist kein Problem und wenn es Dich zu sehr stört, kannst Du die ja auch einmal defragmentieren, bevor Du ein Backup ziehst. Da Du beim Zurückschrieben der Backups die Zusammenhänge der Dateien ja sowieso in gewisser Weise wiederherstellst, denn es werden dabei ja immer große Blöcke am Stück geschrieben und nicht nur ein paar kb, dürfte das zerstückeln der Dateien durch das Verschieben in kleinen Blöcken bei Dir keinen negativen Einfluss haben. Da Du ja auch öfter mal die ganze Kapazität überschreibt, fällen die mit der Defragmentierung verbundenen Schreibvorgänge auch nicht so ins Gewicht. Das ist dann aber eine rein optische Sache und die Fragmentierung wird wiederkommen.

 

[chriscrosser]

@Holt
danke dir bootsmann!
;-)))
thanx
chriscrosser (matrose)

 

[heinzl]

Da die Adressierung sich im Mikrosekundenbereich bewegt, ist es völlig egal, wo die Daten liegen, da sowieso jeder Block adressiert werden muß. Wo die Daten wirklich liegen, weiß das Betriebssystem sowieso nicht

 

[Holt]

Da die Adressierung sich im Mikrosekundenbereich bewegt, ist es völlig egal, wo die Daten liegen, da sowieso jeder Block adressiert werden muß.

heinzl, innerhalb der SSD ist das richtig, aber es werden ja mehrere LBAs mit einem Befehl angefordert. Wenn die Dateien zu sehr fragmentiert sind, dann müssen eben mehr Befehle geschickt werden und pro Befehl werden wenige Daten übertragen, es ergebt sich also mehr Overhead und kürzere Übertragungen und die sind langsamer was die Performance reduziert.

Wo die Daten wirklich liegen, weiß das Betriebssystem sowieso nicht

Das ist klar, das weiß nur der SSD Controller.