Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Hey,
Ich hätte noch eine Frage, die hier anschließt. Geht es auch wenn ich bei der Pationierung einfach 10% nicht zuweise? Dann sind die ja aufjedenfall frei. Oder werden diese 10% dann nicht zum entlasten anderer Speicherzellen genutzt?
Ich glaube ihr habt mich nicht ganz verstanden, weil ich euch dei Info vorenthalten habe, dass ich eine 1b SSD in ein neues System bauen werde. Und da ich sie soweiso nicht vollballern werde, kann ich auch gleich 100GB einfach garnicht zuweisen, sprich es bleibt eine partition mit 900GB fürs System. Hat dies nun den selben positiven Effekt, wie wenn ich die SSD voll Nutzen würde, aber einfach darauf achte, 10% nicht zu beschreiben?
Steht bereits aber in diesem Thread was du wisssen willst.
OP hast du nur mit einem unpartitionierten Bereich.
Ob du nun eine 128GB oder eine 1000GB SSD hast spielt keine Rolle.
Das ist immer das Problem mit der Aufteilung in Partitionen statt über Unterverzeichnisse: Auf der einen Partition geht der Platz aus, während auf der anderen noch reichlich Platz frei ist.
visionbrasil schrieb:
Werden die "10%" für die jeweils erstellten Partitionen berechnet
Ja und nein, aus Sicht der SSD ist es egal wo der Platz frei ist, aber fürs jeweilige Fileystem nicht und gerade Windows braucht auf C: Platz für Updates.
Ein festes OP in Form eines nicht partitionierten Bereiches ist bei Systemen wo TRIM funktioniert, übrigens unnötig.
Das hat nichts mit trim zu tun. Bei einer HDD wird die logische Adresse in der Regel auf den gleichen physischen Bereich aufgelöst; Die einzige Ausnahme dieser Regel ist, wenn ein reallocate sector count event aufgetaucht ist, dann wird dieser eine Sektor durch einen spare Sektor ersetzt. SSDs haben begrenzte Schreib/loesch -zyklen. teilweise hält eine QLC-nand-zelle nur 150 Zyklen. Deswegen macht jeder SSD controller wear leveling. logische Adressen werden immer wieder auf andere physische Bereiche zeigen. um die Schreib Zyklen über die gesamte SSD zu verteilen. wenn 99% der SSD belegt ist. kann der controller nur die letzten 1% für wear-leveling verwenden. diese 10% Overprovisioning sollen der SSD helfen nicht nur wenige Zellen kaput zuschreiben. Moderne SSDs haben aber die Möglichkeit selbst beschrieben Zellen für ihr wear-leveling zu benutzen in den sie die Daten von einer wenig beschrieben Zellen in eine andere Zelle schreiben und intern haben sie auch reserve blocks die genau diese 10% Overprovisioning die du machen willst schon ersetzen. klare Empfehlung von mir ist benutzt den gesamten platz der SSD. der Controller einer Moderen SSD ist intelligent genug.
Deswegen macht jeder SSD controller wear leveling. logische Adressen werden immer wieder auf andere physische Bereiche zeigen. um die Schreib Zyklen über die gesamte SSD zu verteilen.
Das Wear Leveling ist ein Nebeneffekt, der Hauptgrund warum die SSD Controller eine Mappingtabelle haben und die logischen Adressen auf immer wieder andere NAND Adressen übersetzen müssen, ist das man bei NAND die Pages nicht überschreiben kann. Man kann jede Page nur einmal beschreiben kann und muss dann erst einen ganzen NAND Block löschen, der Hunderte Pages umfasst.
Multivac schrieb:
wenn 99% der SSD belegt ist. kann der controller nur die letzten 1% für wear-leveling verwenden.
Man kann bei keiner SSD 99% des NANDs belegen, denn die haben alle intern deutlich mehr NAND- als Nutzkapazität. Eine 512GB (512*1000^3 Byte) SSD hat immer mindestens 512GiB (512*1024^3 Byte) NAND verbaut, also rund 7% mehr!
Multivac schrieb:
Moderne SSDs haben aber die Möglichkeit selbst beschrieben Zellen für ihr wear-leveling zu benutzen in den sie die Daten von einer wenig beschrieben Zellen in eine andere Zelle schreiben
Beschrieben Zellen müssen erstmal gelöscht werden, bevor sie neu beschrieben werden können und das Löschen passiert immer in ganzen NAND Blöcken, woher auch der Name Flash kommt. Das Wear Leveling ist auch nichts anderes als der Algorithmus zur Auswahl welche Pages beschrieben und welche Blöcke gelöscht werden.
Multivac schrieb:
und intern haben sie auch reserve blocks die genau diese 10% Overprovisioning die du machen willst schon ersetzen.
Ob das 10% sind oder nicht, hängt davon ab wie viel NAND- und wie viel Nutzkapazität die SSD jeweils hat, bei 512GiB NANDs hat eine mit 480GB Nutzkapazität sogar mehr als 10%.
Wie holt bereits geschrieben hat verfügt eine 512GB SSD bereits 7% OP weil sie 512GiB NAND verbaut hat, also ~549GB.
Dazu kommt dass das gängigste Dateisystem NTFS es nicht mag, wenn man Partitionen randvoll knallt und Windows zickt wenn C: voll ist.
Wenn man also die unsichtbaren 7% + ein paar GB Luft fürs Daeisystem lässt reicht das völlig, man muss keine 10% Platz verschwenden.
Ja manche SSDs schreiben dann langsamer weil sie nicht mehr so gut cachen können, aber wenn nur noch 50GB auf der SSD frei sind braucht man jetzt keine unglaublichen Schreibraten da man ja max. 50GB drauf schreiben kann.
Bei SSDs mit 480GB oder 960GB ist oftmals zusätzlich zu den ersten 7% nochmal bereits weitere 7% OP eingerichtet, also etwa 14% OP ab Werk. Das ist natürlich von der verwendeten NAND Die Size abhängig, aber bei den 2er Potenzen passt das i.d.R. so.
Wenn Du die mit den oft extrem großen, dynamischen Pseudo-SLC Caches wie z.B. die Intel 660p meinst, so müsste man da schon reichlich viel freilassen um noch von einem dynamischen Pseudo-SLC Cache statt nur des kleinen statischen Teils profitieren zu können:
