Eine SSD in Windows wird nicht defragmentiert? Doch wird sie!

Eine SSD hat nur bestimmte Anzahl Lese- und Schreibzyklen. Deshalb sollte man sie schonen. OK, dass war in der Anfangszeit der SSD die Regel Nummer 1. Die heutigen SSDs sind so robust, dass man täglich die SSD im höheren Gigabyte Bereich beanspruchen müsste, um die Lebensdauer zu verringern.

Auch wurde immer wieder gesagt, eine SSD soll man nicht defragmentieren. War ich bis dato auch der Meinung. Mit Windows 8 wird der Trim-Befehl gesendet und das war es. Aber ich wurde nun eines besseren Belehrt.

Denn wie ich bei Scott Hanselman gelesen hab, defragmentiert Windows einmal im Monat auch eine SSD, wenn der Dienst Volumenschattenkopie aktiviert ist. Der ist für die Systemwiederherstellungspunkte und auch Sicherungen zuständig.

Keine Panik, Windows regelt dies sehr intelligent. Denn wenn die SSD defragmentiert wird, werden die Meta-Daten von Dateien neu geordnet. Dies trifft dann zu, wenn Dateien nicht erweitert werden können und somit fragmentiert auf der SSD liegen. Auf gut deutsch: Auch eine SSD leidet unter Fragmentierung. Somit kommt es zu Leistungseinbußen beim lesen und schreiben.

Durch die Defragmentierung wird also die Lebensdauer und die Leistung der SSD maximiert. Eine Deaktivierung der Defragmentierung schadet einer SSD also mehr, als dass es etwas gutes bringen würde.

Die Antwort die Scott auf eine Anfrage an das Entwickler-Team Windows storage bekam lautet:

[stextbox id=”zitat”]

Actually Scott and Vadim are both wrong. Storage Optimizer will defrag an SSD once a month if volume snapshots are enabled. This is by design and necessary due to slow volsnap copy on write performance on fragmented SSD volumes. It’s also somewhat of a misconception that fragmentation is not a problem on SSDs. If an SSD gets too fragmented you can hit maximum file fragmentation (when the metadata can’t represent any more file fragments) which will result in errors when you try to write/extend a file. Furthermore, more file fragments means more metadata to process while reading/writing a file, which can lead to slower performance.

As far as Retrim is concerned, this command should run on the schedule specified in the dfrgui UI. Retrim is necessary because of the way TRIM is processed in the file systems. Due to the varying performance of hardware responding to TRIM, TRIM is processed asynchronously by the file system. When a file is deleted or space is otherwise freed, the file system queues the trim request to be processed. To limit the peek resource usage this queue may only grow to a maximum number of trim requests. If the queue is of max size, incoming TRIM requests may be dropped. This is okay because we will periodically come through and do a Retrim with Storage Optimizer. The Retrim is done at a granularity that should avoid hitting the maximum TRIM request queue size where TRIMs are dropped.

[/stextbox]

Hört sich im ersten Moment verwirrend an, oder? Da hat man die ganze Zeit gedacht, oh Samthandschuhe raus, ich will etwas mit der SSD machen. Aber so ist es gar nicht.
Nachdem ich das Bild von meiner Anzeige gemacht hatte, hab ich ganz einfach mal die Optimierung angeschmissen. Nach knapp 3 Sekunden war auch schon wieder alles vorbei.

Auch interessant:
▪ Automatisches Defragmentieren wenn eine SSD und HDD eingebaut ist