Wieviel Platz sollte man auf einer 120GB SSD freilassen?

Die einzelnen Zellen sind nach dem Partitionieren fix zugeteilt. Der Controller kann weiterhin auf unpartitionierte Bereiche (Spare Area) zugreifen, aber nicht auf Zellen, die einer anderen Partition zugeteilt sind.
Die Partitionsgröße und die Anzahl der zugeteilten Zellen ist nicht variabel.

Nochmal: Das Partitionsübergreifende ansprechen von Zellen ist nicht möglich. (z.B. : Die Zellen 0-49 sind fix der Partition A und die Zellen 50-100 fix Partition B zugeteilt; wird auf Partition A geschrieben, werden auch nur die Zellen 0-49 und eventuell die Spare Areas angesprochen)
 
Zuletzt bearbeitet:
Bei den SSDs mti Sandforce ist das unpartitioniert lassen von Kapazität weniger wichtig als bei anderen SSDs, denn sie hat dank der Datenkompression bei normalen Daten sowieso immer mehr freien Bereich an Flash als die anderen. Dazu müssen die Daten natürlich komprimierbar sein und man darf natürlich nicht schon die Datenkompression des Filesystems aktivieren oder die Daten verschlüsseln, dennn dann bleibt für den Sandforce nichts mehr zum Komprimieren. Im Laufenden Betieb sollte man sich dann an die Anzeige des Windows Explorers halten und vermeiden, dass der Balken der den Füllstand des Laufwerks anzeigt rot wird.
 
Nachdem empfohlen wird 5-10% zusätzlich zur internen OP-Area freizulassen, hätte ich noch eine Frage - inwieweit hat TRIM oder nicht TRIM darauf einen Einfluß? Dachte eigentlich, daß bei funktionierendem TRIM eigentlich gar kein zusätzlicher Bereich frei gelassen werden muß?
 
Im Gegenteil - die Funktion von Trim wird durch eine sehr volle Platte stark eingeschränkt. (Trim verteilt die Schreibanfragen auf die verschiedenen Zellen, sodass alle Zellen in etwa gleich oft beschrieben werden und nicht einige wenige sehr oft)
 
Dachte eigentlich daß TRIM die gelöschten Pages sofort (also keine aufwendige GC) freigibt. Aber das hab ich dann vermutlich mit Wear-Leveling verwechselt.
 
Nein Du hast nichts verwechselt.

Mit dem TRIM-Kommando teilt das BS der SSD mit, welche LBAs zum Löschen freigegeben werden. Die SSD kann dann die entsprechend zugeordneten Flash-Zellen löschen.
Vorteil 1: die freien Bereiche stehen für das Wear Leveling zur Verfügung
Vorteil 2: leere Pages können sofort beschrieben werden und müssen nicht erst gelöscht werden, was auf Dauer die Leistung der SSD hoch hält.

Wear Leveling sorgt für die (möglichst) gleichmäßige Abnutzung der Flash-Zellen.
Ihm stehen dazu alle freien Flash-Bereiche zur Verfügung, unabhängig von Dateisystem und Partitionierung. Je mehr frei ist, um so besser.

Auf einem TRIM-fähigen System braucht damit auch nichts unpartitioniert bleiben.
Auf der Systempartition muss für den fehlerfreien Betrieb für Temp-Dateien, wachsende Logs, Systemwiederherstellung, etc... sowieso immer ausreichend Platz frei sein.
Braucht man kurzzeitig (z.B. zum Entpacken eines großen Archivs) mehr Platz, kann damit bei Bedarf der gesamte Platz der SSD genutzt werden und läuft damit weniger Gefahr, das es wegen eines unpartitionierten Bereiches zu Platzmangel und damit evtl. zu Fehlern kommt.

Zur ursprüngliche Frage: Bei einem TRIM-fähigen System bzgl. Partitionen nichts, für das Betriebssystem soviel, dass es fehlerfrei läuft.
 
juenger, TRIM hat schon einen Einfluss, denn mit TRIM erfährt der Controller ja durch das TRIM Kommando immer, wenn eine Datei gelöscht wird und kann den Platz, der von dieser belegt war, wieder für die GC verwenden. Jede SSD hat eine GC, sonst wären die Speicherplätze nicht wieder beschreibbar! Ohne TRIM erfährt der Controller auch, wann Daten ungültig geworden ist, aber erst dadurch, dass die logische Adresse erneut beschrieben wird. Ist eine SSD also einmal vollständig beschrieben und werden alle Daten danach gelöscht, so bleibt sie für den Controller weiterhin voller gültiger Daten, wenn keine TRIM Kommandos beim ihm ankommen.
 
Sherman123 schrieb:
Die einzelnen Zellen sind nach dem Partitionieren fix zugeteilt. Der Controller kann weiterhin auf unpartitionierte Bereiche (Spare Area) zugreifen, aber nicht auf Zellen, die einer anderen Partition zugeteilt sind.
Die Partitionsgröße und die Anzahl der zugeteilten Zellen ist nicht variabel.
Danke für die Erläuterung. Ich habe mir das immer anders vorgestellt. Ich dachte, der Controller nutzt jede einzelne Speicherzelle wie er will und zeigt sie so dem Betriebssystem.

HDScratcher schrieb:
Auf der Systempartition muss für den fehlerfreien Betrieb für Temp-Dateien, wachsende Logs, Systemwiederherstellung, etc... sowieso immer ausreichend Platz frei sein.
Braucht man kurzzeitig (z.B. zum Entpacken eines großen Archivs) mehr Platz, kann damit bei Bedarf der gesamte Platz der SSD genutzt werden und läuft damit weniger Gefahr, das es wegen eines unpartitionierten Bereiches zu Platzmangel und damit evtl. zu Fehlern kommt.
Schön ausgeführt! Also bei einer 120 GB einfach nichts aufteilen, C:\ über alles laufen lassen, mit Ordnern statt Partitionen arbeiten und die Füllstandsanzeige im Auge behalten.
 
Wilhelm14, Sherman123 bringt hier alles durcheinander, vergiss bitte schnell wieder, was er da geschrieben hat. Die Flashadressen werden ständig dynamisch anderen logischen Adressen zugewiesen und die logischen Adressen sind den Partititonen fest zugeteilt. Was er in #24 beschreibt ist auch nicht TRIM sondern das WearLeveling.
Ergänzung ()

Wer da nochmal mehr über die Funktionsweise, sowieso TRIM und GC wissen, will: Das habe ich mal zusammengestellt.
Ergänzung ()

Sherman123 schrieb:
Nochmal: Das Partitionsübergreifende ansprechen von Zellen ist nicht möglich. (z.B. : Die Zellen 0-49 sind fix der Partition A und die Zellen 50-100 fix Partition B zugeteilt; wird auf Partition A geschrieben, werden auch nur die Zellen 0-49 und eventuell die Spare Areas angesprochen)

Ein SSD Controller kann also die Partitionstabelle lesen und auswerten. Welche Formate unterstützt der denn und was passiert, wenn keine vorhanden ist und man einfach so Daten auf die SSD schreibt, etwa in einer Industrieumgebung wo sie in einem Embedded Controller als Speichermedium für Logdaten dient?
 
Zuletzt bearbeitet:
Ups, Trim mit Wear Leveling verwechselt.:/

Die Flashadressen werden ständig dynamisch anderen logischen Adressen zugewiesen und die logischen Adressen sind den Partititonen fest zugeteilt.
Ja, da stimme ich dir doch auch zu. Es weiß doch jeder hier, dass die Sektoren nicht der physikalischen Reihenfolge entsprechend beschrieben werden müssen (zusätzliche schieben die Controller die Daten von Zeit zu Zeit selbständig herum). Ich schreibe lediglich, dass einmal einer Partition zugeteilte Zellen auch in dieser fix verbleiben - das schreibst du doch auch.

Ein SSD Controller kann also die Partitionstabelle lesen und auswerten. Welche Formate unterstützt der denn und was passiert, wenn keine vorhanden ist und an einfach so Daten auf die SSD schreibt, etwa in einer Industrieumgebung wo die in einem Embedded Controller als Speichermedium für Logdaten dient?
Wenn es kein Dateisystem gibt, wie soll dann jemals wieder auf eine irgendwo abgespeicherte Datei zugegriffen werden? Irgendeine Art von Dateisystem gibt es immer; ich erkenne aber auch nicht, was das Beispiel eines eingebetteten Systems mit dem Thread hier zu tun hat.
Der Controller weiß eben durch das Partitionieren, dass nur die ersten xTausend Zellen zur Partition 1 gehören. Woher? Keine Ahnung.

Controller sind sehr komplexe Dinger und besitzen ein gewisses Maß an Intelligenz:
https://wiki.archlinux.org/index.php/Solid_State_Drives schrieb:
Firmwares and controllers are complex. They occasionally have bugs. Modern ones consume power comparable with HDDs. They implement the equivalent of a log-structured filesystem with garbage collection. They translate SATA commands traditionally intended for rotating media. Some of them do on the fly compression. They spread out repeated writes across the entire area of the flash, to prevent wearing out some cells prematurely. They also coalesce writes together so that small writes are not amplified into as many erase cycles of large cells. Finally they move cells containing data so that the cell does not lose its contents over time.


EDIT: Achso: Du meinst, die logischen Adressen sind fix zugeteilt und ich meine, die physikalischen sind partitionsweise fix zugeteilt. Okay. Vielleicht mach ich Mal vor dem nächstne Neuaufsetzen Versuche: Platte Partitionieren, eine Partition anfüllen und parallel Benchmarks machen. Ich finde im Internet zumindest keine Infos diesbezüglich.
 
Zuletzt bearbeitet:
Sherman123 schrieb:
Ich schreibe lediglich, dass einmal einer Partition zugeteilte Zellen auch in dieser fix verbleiben - das schreibst du doch auch.
Nein, das schreibe ich nicht, denn es ist klar zwischen logischen Adressen und Flashasdressen zu trennen. Die logischen Adressen sind die Adressen die von dem Rechner verwendet werden und die Flashadressen sind die Adressen, in die der Controller die Daten legt. Von logischen Adressen wird auf Flashadressen gemappt (über eine Tabelle umgewandelt) und dieses Mappung ändert sich eben ständig, da sonst schonmal kein Wear Leveling möglich wäre, die Write Amplification und die Random Schreibperformance wären fürchterlicht. Man dann beim Überschreiben einer Page den ganez Block vorher lesen, löschen und mit einer veränderten Page neu schreiben. Bei einem MB Blocksize und 4k Pagesize.....
Du schriebt es doch selbst:
Sherman123 schrieb:
Es weiß doch jeder hier, dass die Sektoren nicht der physikalischen Reihenfolge entsprechend beschrieben werden müssen (zusätzliche schieben die Controller die Daten von Zeit zu Zeit selbständig herum).
Bei HDDs ist das anders, da werden logischen Adressen fest in Kopf, Zylinder und Sektor umgerechnet.
Sherman123 schrieb:
Wenn es kein Dateisystem gibt, wie soll dann jemals wieder auf eine irgendwo abgespeicherte Datei zugegriffen werden? Irgendeine Art von Dateisystem gibt es immer; ich erkenne aber auch nicht, was das Beispiel eines eingebetteten Systems mit dem Thread hier zu tun hat.
Der Controller weiß eben durch das Partitionieren, dass nur die ersten xTausend Zellen zur Partition 1 gehören. Woher? Keine Ahnung.
Aber ich weiß es, denn die Filesystem ist eine Ebene höher und dient genau dazu, die Daten wiederzufinden. Das Laufwerk ist alleine eine Ansammlung von Speicheradressen hinter der sich gewöhnlich immer 512 Byte Daten verbirgen. Das Filesystem ist Teil des Betriebssystem und das legt eben die Daten an einer bestimmen Adresse ab, davon weiß das Laufwerk, egal ob SSD oder HDD aber nichts. Das Laufwerk erhält nur den Befehl, schreibt diese Daten ab dieser Adresse oder lese soviele Daten von der Adresse an. Ob die Daten jetzt eine Partitionstabelle oder eine Urlaubsfoto sind, davon weiß der Datenträger nichts.
Sherman123 schrieb:
Controller sind sehr komplexe Dinger und besitzen ein gewisses Maß an Intelligenz:
Da steht doch Deutlich "They implement the equivalent of a log-structured filesystem", also etwas ähnliches wie ein log strukturiertes Filesystem. Es wäre schon sinnvoll das Filesystem auf die SSD auszulagern, aber soweit sind wir leider noch nicht, denn das müsste dann auch für alle Betriebssystem funktionieren. Bisher werden SSDs nur als Ersatz für HDDs angesehen und eingesetzt, womit das Filesystem weiterhinSache des Betriebsystems bleibt.

Sherman123 schrieb:
EDIT: Achso: Du meinst, die logischen Adressen sind fix zugeteilt und ich meine, die physikalischen sind partitionsweise fix zugeteilt. Okay. Vielleicht mach ich Mal vor dem nächstne Neuaufsetzen Versuche: Platte Partitionieren, eine Partition anfüllen und parallel Benchmarks machen. Ich finde im Internet zumindest keine Infos diesbezüglich.
Stelle Dir die logischen Adressen wie den Domainnamen vor und die Flashadresse wie die IP, der Domain Name Server übersetzt den Namen in die IP. Die Partitionen sind sowas wie die Rootleveldomain und auch wenn Computerbase eine de Domain ist, so kann der Server trotzdem außerhalb Deutschlands stehen und es muß auch nicht immer der gleiche sein und es müssen auch nicht alle Webserver mit de Topleveldomain im gleichen Land stehen.

Da ein SSD Kontroller keine Partitionen kennt, werden die Daten aller Partitionen überall auf die Flashadresssen verteilt. Jedes Laufwerk stellt nur eine bestimmte Anzahl logischer Adressen zur Verfügung und durch die Partitionierung werden diese auf bestimmte Partitionen aufgeteilt und damit darf es zwischen den Partitionen keine Überschneidung der Adressen geben, sonst werden die Daten korrupt.
 
Vielleicht findest du noch eine Antwort auf diesen Gedankengang: Ich gehe davon aus, dass die physikalischen Zellen 0-49 fix Partition A und 50-100 fix Partition B zugeteilt sind.
Du sagst ja, dass diese auf der logischen Ebene passiert und nichts mit den tatsächlich zugeteilten Zellen zu tun hat.

Wenn der Controller die physikalischen Zellen frei zuteilt, dann muss das bedeuten, dass für jede Zelle, die A weggenommen wird gleichzeitig B größer wird oder es wird gleichzeitg 1 Zelle aus A mit einer aus B getauscht. Ist das möglich?

Oder stehen die physikalischen Zellen nach dem Partitionieren quasi auf Abruf und die Partitionsgröße ist rein auf der logischen Ebene - eigentlich macht das auch Sinn.:)
 
Du musst gar nichts frei lassen weil Sandforce schon von Haus aus 7% fürs Overprovisioning, also für alle Schreibvorgänge reserviert.

Die Physikalischen Zellen sind keineswegs festen Partitionen zugeteilt. Selbst die Zuordnung Physikalische Zelle -> LBA erfolgt völlig dynamisch und nach Abnutzungslevel. Außerdem speichert Sandforce keine Daten, sondern nur Prüfsummen, in einem sehr komplexen Verfahren, genauer nachzulesen im OCZ-Forum.
 
Zuletzt bearbeitet:
etking, jede SSD hat etwa 7% mehr Flashkapazität als Userkapazität, denn die NAND Kapazität ist GiB (1024^3 Byte) und die Userkapazität in GB (1000^3 Byte). Nur steht nicht die ganze freie Kapazität als Reserve für Userdaten zur Verfügung, da müssen auch die Verwaltungsdaten untergebracht werden, vor allem die Mappingtabelle die von logischen Adressen (LBAs) auf Flashadressen. Zwar haben die Flashbausteine mehr Kapazität als die z.B. 4096Bytes einer Page (bei Intel/Micron 25nm NAND kommen noch 224Byte dazu), aber die werden i.d.R. für ECC Daten genutzt. Legt man da aber z.B. die Mappingtabelle ab, so müsste die SSD beim Booten zuerst alle Pages einlesen, was sehr, sehr lange dauern würde und daher nicht praktikabel ist.

Der Sandforce speichert übrigens nicht nur Prüfsummen ab, sondern natürlich auch die komprimierten Daten selbst und dazu eben extra in einem eigenen Die nochmal extra Prüfsummen, weshalb die SF SSDs auch immer weniger Nutzkapazität haben und trotzdem nicht mehr freien Platz für Userdaten. Ein Mehr an freiem Platz für Userdaten schafft sie sich über die Datenkompression.

Sherman123, der SSD Controller kennt keine Partitionen und mappt jede LBA mal auf diese oder mal auf jede Flashadresse, egal zu welcher Partition diese LBA nun gehört. Partitionen teilen nur die LBAs ein, die ersten LBAs sind Verwaltungsdaten des Rechners, also Partitionstabelle und Masterbootblock, dann kommen x LBAs für die erste Partition, y für die zweite Partition etc.

Die LBAs die nicht einer Partitionen zugewiesen sind und auch nicht von den Systemverwaltungsdaten belegt sind, werden auch nicht vom Filesystem beschrieben und somit muss der Controller diese niemals auf eine Flashadresse mappen. Das geht aber nur, wenn die SSD neu ist oder mit Secure Erease gelöscht wurde, wenn man eine schon genutzte Partition verkleinert (z.B. neu partitioniert), dann könnten diese LBAs schon mal beschrieben worden sein. Wenn ja, dann werden sie niemals überschrieben und damit werden die Daten ewig als gültig im Flash stehen bleiben.
 
Wilhelm14 schrieb:
Wer manuell das "Overprovisioning" vergrößern möchte hat dazu zwei Möglichkeiten. Entweder im Arbeitsplatz gelegentlich prüfen wie voll die SSD ist oder direkt auf 100 GB partitionieren und 20 GB unformatiert lassen. Beim zweiten kann man nicht aus Versehen die gewünschte Grenze überschreiten.
Bei funktionierenden TRIM braucht man das sowieso nictht, aber die erste Methode funktioniert nicht zuverlässig. Unter Windows reserviert NFTS z.B. standartmäßig 12.5% für den MFT, der je nach Anzahl der Dateien mehr oder wenig gut gefüllt wird. Die restlichen 87.5% werden für Dateien verwendet, solange noch Platz vorhanden ist. Geht der Platz aus, werden auch Dateien in den Bereich der für den MFT reserviert ist, geschrieben. Da Windows nicht sofort den Platz oder MFT Eintrag überschreibt, der von einer gelöschten Datei belegt war, können also alle LBAs mal beschrieben worden, selbst wenn die Platte niemals voller als z.B. 80% war.

Sicher unbeschrieben bleiben nur LBAs, die nicht im Bereich einer Partition liegen.

Wilhelm14 schrieb:
Leider weiß man oft nicht, wieviel Reserve die Hersteller verbaut haben. Sie verraten es nicht.
Das tun sie leider nicht, aber im Prinzip geben sich die alle nicht viel. Jede Cosumer SSD hat gewöhnlich soviele GiB an Flash wie GB an Nutzkapazität was etwa 7% Unterschied ausmacht, ausser denen mit Sandforce Controller und der Intel 510er Reihe. Die mit dem Sandforce haben zwar nochmal so um 6.7% mehr als die anderen, aber dafür braucht die Fehlerkorrektur RAISE auch mehr Platz, immer mindestens ein ganze Die.

Man darf außerdem nicht vergessen, von den etwa 7% NAND welches für den User nicht nutzbar ist, geht immer auch einiges für Verwaltungsdaten ab und seht somit der GC nicht für Userdaten zur Verfügung.
 
Zurück
Oben