Partitionen.Physikalisch oder theoretisch?
- Ersteller WoIstDerAmiga
- Erstellt am
WoIstDerAmiga
Vice Admiral Special
Wenn ich eine HDD in 2 Partitionen teile,sagen wir mal in D: und E:,ist dann die Partition etwas physikalisches?Sind dann nur bestimmte Bereiche auf der HDD nur für D: zb. vorgesehen,oder ist eine Partition nur theoretisch und es wird geschrieben wo gerade Platz ist bis die Kapazität der Partition erreicht ist?
Wäre für mich bei einer SSD noch interessanter.Ich hab eine 120er,davon sollen 64 GB zum cachen genutzt werden.8 GB für RapidStart,der Rest ungenutzt.Werden jetzt für die 8 GB RapidStart immer nur die gleichen Zellen genutzt,oder gerade die Zellen die frei sind?
Wäre für mich bei einer SSD noch interessanter.Ich hab eine 120er,davon sollen 64 GB zum cachen genutzt werden.8 GB für RapidStart,der Rest ungenutzt.Werden jetzt für die 8 GB RapidStart immer nur die gleichen Zellen genutzt,oder gerade die Zellen die frei sind?
Antarctica
Grand Admiral Special
Bei HDDs gibts ein Hinten und ein Vorne. Da kann man eine bestimmte Stelle, wo geheime Daten liegen, hundertmal überschreiben und die Daten sind weg.
Dort hat jedes Byte seine feste Position, durchnummeriert von 0 bis x, und kann prinzipiell einzeln beschrieben werden.
Bei SSDs ist dem nicht so. Da ist die kleinste Einheit eine Speicherzelle, deren Größe der Hersteller mal gewählt hat. Wenn das Betriebssystem an einer bestimmten Byteposition einen Satz Daten schreiben will, wird - vereinfacht gesagt - geguckt, in welcher Zelle diese Position liegt, falls sie überhaupt schon in einer ist; und welche freie Zelle bisher die wenigsten Schreibzyklen abgekriegt hat. Und dann holt die SSD die Daten aus der alten Zelle, überschreibt den Teil den das Betriebssystem geändert haben will, und packt den Kram in die freie Zelle. Und dann wird in der Lookup Table gespeichert: physikalischer Platz x befindet sich in Zelle y.
Dort hat jedes Byte seine feste Position, durchnummeriert von 0 bis x, und kann prinzipiell einzeln beschrieben werden.
Bei SSDs ist dem nicht so. Da ist die kleinste Einheit eine Speicherzelle, deren Größe der Hersteller mal gewählt hat. Wenn das Betriebssystem an einer bestimmten Byteposition einen Satz Daten schreiben will, wird - vereinfacht gesagt - geguckt, in welcher Zelle diese Position liegt, falls sie überhaupt schon in einer ist; und welche freie Zelle bisher die wenigsten Schreibzyklen abgekriegt hat. Und dann holt die SSD die Daten aus der alten Zelle, überschreibt den Teil den das Betriebssystem geändert haben will, und packt den Kram in die freie Zelle. Und dann wird in der Lookup Table gespeichert: physikalischer Platz x befindet sich in Zelle y.
WoIstDerAmiga
Vice Admiral Special
Lange rede,kurzer Sinn....Bei einer SSD ist eine Partition nicht auf einen Bereich begrenzt,es wird einfach in die Zellen geschrieben die gerade frei bzw. am wenigsten genutzt wurden.
Gilt das also auch für einen ungenutzten Bereich,der bei mir ja gut 48GB beträgt?Oder anders gefragt,wenn ich eine Partition von 50 GB hätte,werden die Zellen der gesammten 120 GB genutzt?
Gilt das also auch für einen ungenutzten Bereich,der bei mir ja gut 48GB beträgt?Oder anders gefragt,wenn ich eine Partition von 50 GB hätte,werden die Zellen der gesammten 120 GB genutzt?
Eine Platte, egal ob HDD oder SSD, stellt eine bestimmte Menge an LBAs bereit und die Partition ist nur eine logische Unterteilung diese Adressbereiches. Die Platten selbst wissen davon nicht, dass ist alleine eine Sache des Betriebs- bzw. Filesystems.
HDDs rechnen LBAs fest auf Kopf, Zylinder und Sektor um und fahren diesen physikalischen Sektor dann an damit er auslesen oder beschrieben werden kann. SSDs mappen aber die LBAs auf immer wieder wechselnde Speicherbereiche und da sie ja keine Partitionen kennen, landen die Daten intern irgendwo, egal zu welcher Partition sie gehören. Nach außen bleibt aber alles wie bei HDDs, da kann man auch immer nur so viel in eine Partition schreiben, wie dort eben Platz ist.
Einmal reicht, denn bei 60% oder 80% Chance ein einzelnes Bit zu rekonstruieren, sind schon die Chancen nur ein Byte wieder korrekt rekostruieren fast 0.
Wenn man ECC Daten außer Acht lässt ja, aber praktisch kann immer nur ein physikalischer Sektor am Stück gelesen oder beschrieben werden, eben wegen der ECC am Ende.
So ist es, aber eben Page statt Zelle, dann passt es und die Daten in der Page wo die alten Daten vorher standen werden als ungültig marktiert und bei Gelegenheit von der GC gelöscht.
Ja, bei mordernen SSDs wird der ganze NAND Bereich benutzt und wenn man davon nur einen wirklich beschreibt, dann ist das für die Performance und Lebensdauer von Vorteil, weil der Controller mehr freien Platz hat wo er Daten ablegen kann und nicht so schnell etwa Löschen muss. Löschen kann er immer nur ganze Blöcke von z.B. 256 oder 512 Pages und daher muss er vorher die Daten intern kopieren, die in Pages des Blocks stehen und noch gültig sind. Das kostet eben Geschwindigkeit und erhöht die Write Amplification.
ja, soweit ich das verstanden habe (man möge mich korrigieren) sind bei SSDs die physische Anordung und die logische, die das Betriebssystem sieht, voneinander getrennt. D.h. wenn ich z.B. eine 120-GB-SSD mit einer 20-GB-, einer 10-GB- und einer 70-GB-Partition partitioniere und den Rest frei lasse, dann werden bei wiederholten Schreib- und Löschvorgängen in beispielsweise nur der 10-GB-Partition jeweils andere Zellen der ganzen SSD verwendet (ausgewählt nach mehr oder weniger ausgeklügelten Mustern in der Firmware), so daß nicht eine kleine "Stelle" schnell total runtergewirtschaftet ist und der Rest praktisch unbenutzt.
Wenn man natürlich größere Bereiche vollschreibt und die auch voll bleiben, d.h. mit validen Daten, dann können diese Zellen natürlich nicht genutzt werden. Aber ich gehe mal davon aus, daß diese besonders wenig abgenutzten Zellen, falls sie doch mal gelöscht werden, dann ganz oben in der Liste der beim nächsten Mal zu verwendenden Zellen stehen. Dieser Theorie zufolge wäre es wohl nicht falsch, ab und zu mal die SSD plattzumachen und neu zu beschreiben (also nicht alle nasenlang, sondern evtl. nach ein paar Jahren mal, je nach Schreibleistung). Möglicherweise macht eine intelligente Firmware sowas ja auch von sich aus.
Wenn man natürlich größere Bereiche vollschreibt und die auch voll bleiben, d.h. mit validen Daten, dann können diese Zellen natürlich nicht genutzt werden. Aber ich gehe mal davon aus, daß diese besonders wenig abgenutzten Zellen, falls sie doch mal gelöscht werden, dann ganz oben in der Liste der beim nächsten Mal zu verwendenden Zellen stehen. Dieser Theorie zufolge wäre es wohl nicht falsch, ab und zu mal die SSD plattzumachen und neu zu beschreiben (also nicht alle nasenlang, sondern evtl. nach ein paar Jahren mal, je nach Schreibleistung). Möglicherweise macht eine intelligente Firmware sowas ja auch von sich aus.
WoIstDerAmiga
Vice Admiral Special
DAS war mir wichtig zu erfahren.Danke.
Das mit der HDD wollte ich einfach mal nur so wissen.
@OBrian: Korrekt, für das Wear Levelling werden Daten umkopiert, um selten genutzte Cluster frei zu machen.
Das erhöht natürlich die Write Amplitude, aber sorgt letztendlich für einen homogenen Verschleiß der NAND Chips.
Das erhöht natürlich die Write Amplitude, aber sorgt letztendlich für einen homogenen Verschleiß der NAND Chips.
SPINA, wobei das aber eben von der jeweiligen SSD abhängt, also deren Controller und dessen Firmware. Beim alten Indilinx Barefoot, der ja neben dem mittleren Löschzähler auch die minimalen und den maximalen ausgibt, war das Wear-Leveling offenbar nicht wirklich gut implementiert, obwohl der eine teils extrem hohe Write Amplification (nicht Amplitude) erzeugt.
BoMbY
Grand Admiral Special
Ja, also Samsung zum Beispiel empfiehlt mittlerweile für die 840 EVO SSDs zum Beispiel 10% unformatiert/unpartitioniert zu lassen, damit das mit dem Wear Levelling immer ordentlich funktioniert. Andere SSDs haben (oder hatten zumindest früher mal) intern einen reservierten Bereich dafür, der dem Anwender gar nicht zur Verfügung steht.
Die Samsung 840 EVO hat ebenso noch eine Spare Area. Das sind 12,7 % bei der 120GB und 9,1% beim Rest.
Das ist deutlich weniger als bei der Crucial M500, aber ich denke es reicht aus um sich bemerkbar zu machen.
Das ist deutlich weniger als bei der Crucial M500, aber ich denke es reicht aus um sich bemerkbar zu machen.
Schaden tut es nicht. Und wenn die SSD fast vollständig belegt ist, ergibt sich ein Vorteil.
Antarctica
Grand Admiral Special
Wenn die 240G-Partition auf meiner 250G-SSD zu 237 GB belegt ist, ergibt sich ein Vorteil gegenüber einer 250G-Partition, die zu 237 GB belegt ist? Das wäre mir neu...
MagicEye04
Grand Admiral Special
Wirklich unPARTITIONIERT?
Das würde heißen, der Controller ist zu doof, den partitionierten, aber freien Speicherplatz dafür zu nutzen?
@Antarctica: Es ging doch um Over-Provisioning durch den User, nicht durch Controller/Firmware. Und wenn man die Spare Area durch eine nicht die gesamte Kapazität ausnutzende Partionierung sozusagen "vergrößert", hilft das dem Wear Levelling, der Garbage Collection und einigen anderen Mechanismen auf die Sprünge. Natürlich nur dann, wenn die eigentliche Spare Area häufig ausgelastet ist und das wird dann der Fall sein, wenn der Füllstand der SSD recht hoch ist. Ansonsten bewältigt die vom Hersteller eingerichtete Spare Area die Aufgabe allein ganz gut. Dank TRIM sollte Over-Provisioning durch den User eigentlich obsolet sein. Freier Bereich innerhalb einer Partition unterscheidet sich wenn er getrimmt wurde, nicht durch freien Bereich außerhalb. Eine nicht die gesamte Kapazität ausnutzende Partitionierung erzieht allenfalls den User dazu die SSD nie voll zu belegen, sondern ihr Luft zum Atmen zu lassen.
Ergänzung: Ich habe mir gerade noch einmal durchgelesen was du geschrieben hast. Wir haben aneinander vorbei geredet. Bei einer modernen SSD unter einem aktuellen Windows macht es wirklich keinen nennenswerten Unterschied. Ich persönlich habe deswegen den gesamten Speicherplatz meiner Samsung PM800 und Crucial M500 ausgenutzt bei der Partionierung. Meine M500 mit ihren 240GB ist dabei noch immer zu lediglich ~ 12 Prozent belegt.
Das Over-Provisioning durch den User macht jedoch Sinn bei manchen betagten SSDs und/oder dem Einsatz unter Windows XP sowie älteren Linux Distributionen.
Ergänzung: Ich habe mir gerade noch einmal durchgelesen was du geschrieben hast. Wir haben aneinander vorbei geredet. Bei einer modernen SSD unter einem aktuellen Windows macht es wirklich keinen nennenswerten Unterschied. Ich persönlich habe deswegen den gesamten Speicherplatz meiner Samsung PM800 und Crucial M500 ausgenutzt bei der Partionierung. Meine M500 mit ihren 240GB ist dabei noch immer zu lediglich ~ 12 Prozent belegt.
Das Over-Provisioning durch den User macht jedoch Sinn bei manchen betagten SSDs und/oder dem Einsatz unter Windows XP sowie älteren Linux Distributionen.
Zuletzt bearbeitet:
Den haben die immer noch und zwar alle SSDs! Die haben alle immer mindestens so viele GiB NAND- wie GB Nutzkapazität und da 1,024^3 eben etwa 1,0737 ergehen, hat jede SSD mindestens 7% mehr NAND- als Nutzkapazität. Ein Teil geht für FW und Verwaltungsdaten ab, aber das meiste ist Free Area.
Da ja auch noch mindestens 3GB TurboWrite vorhanden sind und das Pseudo-SLC ist, wären das eigentlich mindestens 9GB weniger TLC die zur Verfügung stehen und damit wäre die 840 Evo 120GB die SSD mit der kleinsten Free Area überhaupt, weil eigentlich nur 119GiB der 128GiB NAND zur Verfügung stehen.
Wenn TRIM funktioniert, dann dürfte das tatsächlich so sein, ja!
Nein, das interessiert den Controller nicht, der kennt keine Partitionen, die sind alleine eine Sache der Logik des Betriebs- bzw. Filesystems! Der Unterschied ist einzig, ob ein LBA aus Sicht des Controller gültige Daten enthält und das ist immer dann der Fall, wenn er beschrieben und nicht wieder überschrieben oder getrimmt wurde. Ohne TRIM reicht also eine langsame Formatierung und die ganze Kapazität der Partition ist von da an für den Controller der SSD mit gültigen Daten beschrieben!
Over-Provisioning ist vor allem bei Enterprise SSD bzw. Anwendungen wichtig, denn da werden die LBAs der SSDs immer nur überschrieben. Datenbanken wie Oracle löschen niemals eine Datei, die legen nur neue an oder vergrößern die bestehenden und VM Imagefiles werden ebenfalls nicht gelöscht, wenn die VM selbst Dateien löscht. Da wird immer nur auf (recht) volle SSD im Random Writezugriffen geschrieben und wer sich mal die Performance consistency Tests z.B. bei Anandtech ansieht, der erkennt sofort welche Unterschied das Over-Provisioning in der Situation macht. Dann wird auch klar, wieso Enterprise SSDs meist schon ab Werk so viel davon haben und was ein paar % mehr ausmachen.
Ähnliche Themen
