Man tauscht da Kapazität gegen Performance, das ist bei HDDs ja auch so, wenn man Short-Stroke betreibt. Wieso Berserkus da so einen Mist schreibt, kann ich deshalb überhaupt nicht nachvollziehen.
Einfach 20% freilassen ist schon ganz richtig, nur verteilt Windows mit der Zeit die Dateien über den ganze Adressraum (es versucht nur den für den MFT reservierten Bereich frei zu lassen) und das sieht man auch, wenn man eine Defrag Programm nimmt, welches auch eine Analyse hat, die die Belegung der Adressen der Platte graphisch anzeigt, so wie MyDefrag oder OODefrag. Deshalb ist es nicht so leicht 20% frei zu lassen und ohne TRIM sind für den Controller eben nur Adressen frei, auf die noch nie geschrieben wurde. Das eine Adresse nicht beschrieben wird, erreicht man am Besten, indem man sie keiner Partition zuweist.
Mit TRIM ist das für Desktopuser alles kein Thema, da löscht man eben ein paar Dateien und schon hat der Controller wieder genug Platz frei. Ohne TRIM oder wenn man Anwendungen hat, die permanente Dateien laufend Beschreiben (Datenbanken, virtuelle Maschinen), dann sollte man eben Overprovisioning betreiben, wenn man die Performance erhalten will. Denn sonst muss der Controller schon sehr bald vor dem Schreiben von Daten erst mal für den nötigen Platz sorgen, also eine Block auswählen, die noch gültigen Daten darin umkopieren, ihn löschen und dann die Daten dort rein schreiben.
Wer jetzt auch noch ein wenig mitgedacht hat, der wird sich natürlich fragen, wohin der Controller diese gültigen (aus seiner Sicht) Daten denn nun schreibt, wenn er doch keinen Platz hat. Na, wer kommt auf die Lösung?
Nun, diese Daten kommen in den gerade vorher gelöschten Block bevor die neuen Daten dort geschrieben werden. Je mehr Daten aber kopiert werden müssen, umso weniger Platz bleibt für das Schreiben neuer Daten übrig. Nomalerweise haben SSDs mit 64/128/256/512GB wie die m4,830, 840Pro. etc. aber ab Werk keine 7% mehr NAND Kapazität als Nutzkapazität (weil x GiB NAND verbaut sind aber nur x GB nutzbar sind). Davon geht noch ein Teil für Verwaltungsdaten ab, vor allem für die Tabelle die LBAs auf Flashadressen mappt. Damit stehen dem Controller vielleicht noch 5% zur Verfügung und im ungünstigsten Fall wären schon 95% eines eben gelöschten Blocks mit umkopierten Daten belegt, bevor überhaupt neue Daten dort geschrieben werden können.
Gönnt man dem Controller nun aber 25% an freiem Platz, etwa weil man eben nur 80% der Kapazität überhaupt partitioniert hat, dann hat er selbst im ungünstigsten Fall, also wenn alle Blöcke das gleiche Verhältnis von gültigen zu ungültigen Pages enthalten, immer noch 25% der eben gelöschten Kapazität für neue Daten zur Verfügung. Das ist 5 mal so viel und entsprechend ist die Schreibgeschwindigkeit auch mehr als 5 mal so hoch.
