Aber bisher hatte ich den Eindruck, dass in diesem Forum der überall zu findende Ansatz 'SSDs bloß nicht defragmentieren' gilt.
Nicht bei mir, ich da anderer Meinung.
eine ab-und-zu Defragmentierung als durchaus sinnvoll empfinde
So ist es auch.
im Web über einige Artikel gestolpert, die sich der üblichen Defragmentierungs-bloß-nicht Welle entgegen stellen.
Den haben ich nun nur ganz kurz überflogen, aber ich meine des Pudels Kern hat er auch nicht getroffen.
Also habe ich da was verpasst? Oder darf man nun auch mal eine gelegentliche Defragmentierung empfehlen?
Ja.
Zunächst mal folgendes, was viele oder alle nicht zu wissen scheinen die sich gegen eine Defragmentierung von SSD aussprechen, weil es nichts bringen würden und die SSDs ja die Daten intern sowieso anders anordnen und quer über die NANDs verteilen, als es von außen scheint. Weder SSDs noch HDDs kennen Partitionen, Filesystem, Dateien, Verzeichnisse oder auch eine Fragmentierung! Das alles sind Geschichte die auf einer logischen Ebene darüber passieren, nämlich im Betriebssystem und dessen Routinen zu Verwaltung der Datenträger, zu denen auch das Filesystem gehört, denn ein Filesystem ist mehr als seine Datenstrukturen auf dem Datenträger, es gehört auch eine Menge Software dazu!
HDDs wie SSDs stellen nur eine Menge LBAs zu Verfügung, die i.d.R. je 512 Byte verwalten und es werden dann ATA Befehle benutzt, die fast immer einen LBA X und Y folgende LBAs auslesen oder beschreiben. Bestimmte Daten an bestimmten Adressen werden dann vom Betriebssystem eben entsprechend interpretiert, die selben Bytes am Anfang im MBR die Partitionstabelle ausmachen, könne an anderer Stelle die Pixel in einem Bild darstellen, das weiß weder eine HDD noch eine SSD. Es stimmt das die Controller von SSDs die Daten quer über die NANDs verteilen, aber das hat einen Sinn, denn so können bei langen Zugriffen wegen der internen Parallelität die sequentiellen Transferraten gesteigert werden, aber die maximalen Transferraten erreichen SSDs eben erst, wenn die Zugriffe auf über viele aufeinanderfolgende LBAs erfolgen und ein ATA EXT Befehl kann bis zu 2^16 LBAs adressieren denn es ja wird nicht LBA für LBA gelesen, was bei 512 Byte pro LBA dann 32MiB sind. Moderne SATA SSDs erreichen oft erst bei Zugriffe von 512 Kilobyte ihre vollen Transferraten und PCIe SSDs brauchen dafür sogar noch längere Transfers. Im IDE Modus werden nur ATA Befehle unterstützt, die maximal 2^8 LBAs adressieren können, also 128k, was nicht reicht und daher haben die SSDs im IDE Modus dann auch immer deutlich geringere sequentielle Transferraten, meist knapp über 300MB/s.
Was hat das nun mit der Fragmentierung zu tun? Filesysteme bemühen sich die Dateien in einem Fragment abzulegen, also die Dateien ab einem bestimmten LBA (bzw. Cluster, aber das ist für das Thema egal, denn ein Cluster lässt sich nach der Formel "Offset der Partition + Clusternummer * LBAs pro Cluster" fix in LBAs umrechnen und das muss das Betriebssystem auch machen, da die Platten eben nur LBAs und keine Cluster verwalten) und dann auf allen folgenden zu legen. Nur wachsen eben Dateien wie Logdateien oder auch der Aufsatz über Fragmentierung an dem man scheibt und der immer länger wird während er zwischendurch immer mal gespeichert wird oder es gibt keine Lücke im Filesystem um die Datei aufzunehmen. Lücken im Filesystem sind Bereiche von LBAs die nicht von Dateien belegt sind, wo also neue Dateien abgelegt werden können.
Ist es nun nicht möglich eine Datei in einem zusammenhängenden LBA Bereich zu speichern, spricht man von Fragmentierung, weil Dateien dann eben nicht mehr nur in einem Fragment abgelegt sind, Fragmentierung betrifft also auch immer nur einzelne Dateien, mal mehr mal weniger auf einer Partition, denn es ist ein Problem des jeweiligen Filesystems und nicht das muss nicht mit der Platte identisch sein, es kann über mehrere Platte gehen so wie eine Platte mehrere Partitionen und damit Filesystem haben kann, aber wie gesagt ist dass nur eine logische Aufteilung des Betriebssystems und der Controller der Platte, egal ob SSD oder HDD, weiß nichts davon.
Was passiert nun wenn eine Datei fragmentiert ist? Nun ein Befehl kann bis zu 32MiB adressieren und ab etwa 512k erreichen moderne SSDs ihre volle Performance. Bei 4k (8 LBAs) sind es viel weniger (ein Blich auf die 4k Ergebnisse von AS-SSD oder CrystalDiskMark zeigt das auch deutlich), 4k sind die kleinste Clustergröße bei den meisten aktuellen Filesystemen, ein Cluster ist auch die kleinste mögliche Größe eines Fragments. Nun liest ein Betriebssystem beim Lesen einer Datei mit einem Befehl immer nur bis zur Grenze eines Fragmentes und dann mit einem weiteren Befehl ab dem Anfang des nächsten Fragmentes bis zur Länge des Puffers oder bis zum Ende des Fragmentes.
Dann müssen bei einer HDD die Köpfe an die neue Position fahren, wo das nächste Fragment anfängt und fast alle die über Fragmentierung fahren, was länger dauert und das ist der einzige Aspekt an fast alle bei Fragmentierung denken. Das hört man oft auch, das dauert, da spürt man die Fragmentierung. Das ist aber nicht die Fragmentierung, es ist nur ein Ergebnis der Fragmentierung und das fällt bei SSD in der Tat weg, da diese sehr kurze Zugriffszeiten haben, aber deswegen bleiben sie von Fragmentierung nicht unberührt, denn durch die Fragmentierung werden mehr Zugriffe nötig und die Länge der Zugriffe, also wie viele LBAs mit einem Befehl adressiert werden, wird dadurch kürzer und das beeinflusst eben auch bei SSD die Performance, wenn auch längst nicht so massiv wie bei HDD!
Um die Einflüsse von Fragmentierung besser zu zeigen, sollte man sich einen Extremfall ansehen, den kann man auch mit etwas Programmiererkenntnissen leicht nachstellen: Man erstellt eine Partition, formatiert sie mit 4k pro Zuordnungseinheit (Cluster), bencht mit AS-SSD, formatiert noch mal und beschreibt diese Partition mit 4k großen, durchnummerierten Dateien. Dann löscht man z.B. alle Dateien mit gerader Endziffer (oder alle mit einer 0 hinten, das verschärft den Test noch, da moderne NAND durchaus 16k Pagesize haben) und bencht erneut. Man darf dann auch der SSD Zeit für die Idle CG lassen und nochmal benchen, damit die Effekte der internen Datenorganisation keine Rolle spielen. Die sequentiellen Transferraten (vor allem Lesend) werden schlechter sein, mindestens um 100MB/s bei SATA SSDs im AHCI Modus und bei einer schnellen PCIe SSD wie der SM951 oder im IDE Modus noch viel deutlicher!
Was passiert bei dem Test? Nun statt weniger Zugriffe mit 1MB (oder weniger, je nachdem was der Treiber darauf macht) werden viele Zugriffe mit 4k erfolgen und selbst wenn diese parallel erfolgen, sind die Transferraten deutlich geringer, schon weil mehr Overhead nötig ist. Die Befehle und Bestätigungen etc. müssen ja auch über den SATA Kanal mit seinen maximal 600MB/s und pro FIS (Übertragungspaket, je mit Overhead wie z.B. eigner CRC) werden maximal 8k übertragen und bei nur 4k pro Befehl gehen eben auch über SATA 6Gb/s maximal so 400MB/s.
Fragmentierung hat also auch auf SSDs einen Einfluss, weil es die Art und Länge der Zugriffe ändert, nicht aber den Effekt wie bei HDDs, weil eben die Zugriffszeiten von SSDs kürzer sind. Wenn ein Treiber sowieso nur 1MiB pro Zugriff liest und alle Fragmente genau ein MiB groß sind, wird es keinen Einfluss auf die Performance einer SSD haben, ist aber jedes Fragment nun genau 1028k lang, so wird für jede Fragment neben dem 1024k langen Zugriff noch ein weiterer mit nur 4k nötig und damit fällt die Performance.
Defragmentieren schaden SSDs auch nicht wirklich, sie wissen ja auch nicht was es ist. Für den Controller der SSD sind es Lese- und Schreibvorgänge wie alle anderen Lese- und Schreibvorgänge auch und die bewirken einen bestimmten Verschleiß also Verbraucht von P/E Zyklen der NANDs, aber ordentliche SSD mit NANDs in normalen Qualitätsstufen wie sie für SSDs gedacht sind, können so viele P/E Zyklen vertragen, da macht das keinen Unterscheid. In allen Endurancetests haben die SSDs viele Hundert TB bis einige PB ausgehalten, ein normaler Heimanwender schreibt kaum 10TB im Jahre, nur wenige schaffen mehr und die werden sich meist auch regelmäßig die neuste, größte, schnellste SSD kaufen. Außerdem ist der Effekt von Fragmentierung bei SSDs eben viel geringer als bei HDDs die muss man bei weitem nicht so oft defragmentieren wie HDDs.
Böse Schatten oder hat die Defragmentierung keinerlei Nachteile außer ein wenig Verschleiß? Doch, es gibt noch einen Aspekt, das Schattenfilesystem, welches viele SSD Controller führen. Die kennen ja nun einmal keine Dateien und verteilen die Daten so über die NANDs, dass diese möglichst schnell geschrieben und gelesen werden können. Daher können sie das nur aufgrund der Lese- und Schreibbefehle entscheiden, welche Daten zusammengehören und das bezeichnet man als Schattenfilesystem. Werden beim Defragmentieren nun stark fragmentierte Dateien aus vielen kleinen Bereichen auf einen zusammenhängenden Bereich von LBAs kopiert, so kann der Controller der SSD dies eben nicht als eine zusammenhängende Datei erkennen und legt diese Daten so ab, als wenn es einzelne kleine Dateien werden, er rechnet also nicht damit, dass dieser neu geschaffene Bereich dann später zusammenhängend gelesen werden wird. Deshalb funktionieren ja auch Low-Level Benchmarks wie HD Tune bei SSDs nicht korrekt. Außerdem liest HD Tune in der Standardeinstellung auch nur alle paar MB mal 64k, was eben nicht reicht um bei SSDs die maximalen sequentiellen Leseraten zu erzielen.
Was macht Windows? Nun vor Win 7 kannte Windows keine SSDs. Bei Win 7 werden SSDs sofort aus dem Zeitplaner des Deframentierdienstes geworfen, man kann sie auch nicht manuell dort eintragen, Das kann man auch gleich nach dem Klonen von einer HDD prüfen, sobald der Dienst startet fliegen die SSD da raus, manuell kann man aber auch noch eine Defragmentierung für SSDs anstoßen. Ab Win 8 (oder besser bei 8 und 8.1, keine Ahnung was Win 10 da macht) ist es anders, da bleiben die SSD im Zeitplaner des Defragmentierdienstes stehen, aber es wird keine Defragmentierung für SSD mehr ausgeführt, sondern ein Batch- oder Offline TRIM wie bei Linux mit fstrim. Dabei werden alle LBAs die als unbelegt erkannt werden getrimmt. Man muss also bei Win7 den Service nicht deaktivieren und sollte es ein Win 8(.1) auch keineswegs tun.
So, das war nun einen Menge und für viele Leser dürfte auch eine Menge neu sein und vielleicht mit dem bisher geglaubten kollidieren, bitte erst noch einmal lesen, dann nachdenken und googlen und erst dann antworten!
Auf die Masse gesehen wäre das vll. ganz interessant u. evtl. irgendwas ablesbar, denke so einzeln dann eher weniger. Das mit Defrag nun nachteilig bzw. langsamer ist kann man sich aber auch nicht vorstellen. Hattest nach dem zweiten Boot nochmal vollständig runtergefahren u. das ganze nochmal wiederholt? Naja, zuviele Faktoren u. vll. wäre ja ohne Defrag beim zweiten Boot dann 15,850 herrausgekommen. Weiss man nicht u. eben recht spekulativ.
