Delphi-PRAXiS

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Klatsch und Tratsch (https://www.delphipraxis.net/34-klatsch-und-tratsch/)
-   -   Wie erkennt SSD von User eingerichtetes Overprovisioning? (https://www.delphipraxis.net/201540-wie-erkennt-ssd-von-user-eingerichtetes-overprovisioning.html)

jus 30. Jul 2019 16:15

Wie erkennt SSD von User eingerichtetes Overprovisioning?
 
Hallo,

ich habe eine Diskussion mit meinem Kollegen von der Technik laufen, da bei uns derzeit nicht viel los ist. :-D Und zwar fragen wir uns wie eine SSD Festplatte vom User eingerichtetes Overprovisioning eigentlich erkennt?
Unter Windows kann man bei Samsung Festplatten ja über das Samsung Magician Tool ein Overprovisioning einrichten. In der Datenträgerverwaltung sieht man dann, dass am Ende der SSD Platte ein freier Bereich entsteht. Die Frage ist halt, ob eigentlich ausreicht, einen freien Bereich am Ende der Platte zu definieren oder man unbedingt das Samsung Magician Tool benötigt, weil dieser vielleicht den freien Bereich der SSD irgendwie mitteilt. Wie kriegt die SSD Platte mit, dass die diesen Bereich verwenden kann?

lg,
jus

Der schöne Günther 30. Jul 2019 16:57

AW: Wie erkennt SSD von User eingerichtetes Overprovisioning?
 
Ohne die Fakten zu kennen würde ich sagen: "Gar nicht, und ein bei der Partitionierung von Hand frei gelassener Bereich ist nutzlos".

Sagt auch z.B. Kingston:
Zitat:

Dieser Over-Provisioning-Speicher ist für den Benutzer nicht zugänglich und wird im Host-Betriebssystem nicht angezeigt. Er ist ausschließlich für die Verwendung des SSD-Controllers reserviert.
https://www.kingston.com/de/ssd/overprovisioning

Codehunter 31. Jul 2019 07:36

AW: Wie erkennt SSD von User eingerichtetes Overprovisioning?
 
:lol:Ich denke der Denkfehler liegt schon in der Art, wie die Frage gestellt wurde:
Zitat:

Zitat von jus (Beitrag 1438408)
Wie kriegt die SSD Platte mit, dass die diesen Bereich verwenden kann?

SSDs sind keine Platten sondern ähneln in Aufbau und Funktion eher RAM als Festplatten. Die Partitionierung läuft betriebssystemseitig auf einer höheren Ebene als das Wear-Leveling von SSD-Controllern. Daher kannst du auf der SSD frei lassen wo und wie viel du willst, physisch packt sich der SSD-Controller die Daten da hin wo es ihm grad genehm ist.

Insofern ließe dein Overprovisioning dem SD-Controller lediglich mehr Freiraum fürs Wear-Leveling, weil er die maximale Datenmenge (Gesamtkapazität minus freigelassenen Bereich) besser in den verfügbaren Speicherzellen verteilen kann. Damit wäre auch geklärt, dass es kein Zauberwerkzeug braucht. Das ist wahrscheinlich nur ein Buntiklicki-Workaround für DAUs, die mit FDISK & Co. nicht umgehen können.

Nehmen wir eine SSD mit 240 GB Platz und geben ihr eine Partition über die Gesamtkapazität, ohne jeglichen Platz. Nun schreibst du ein Programm, das eine Datei auf der SSD erzeugt, die per FileStream aufs Byte genau die gesamte Partition mit 0 füllt. Dann pickst du dir ein beliebiges Byte in den 240 GB heraus und beschreibst das tagelang nach dem Zufallsprinzip, sodass du tausendfach über der Anzahl der maximal möglichen spezifizierten Schreibvorgänge je Speicherzelle der SSD liegst. Die Speicherzelle wird dir trotzdem nicht kaputt gehen, weil der Controller das eigentlich zu schreibende Byte in eine beliebige physische Speicherzelle schreibt.

Eine 240-GB-Festplatte verhielte sich in dieser Konstellation ganz anders. Die Magnetscheibe würde tatsächlich über die gesamte Fläche mit 0 beschrieben und anschließend die betreffende Stelle mit dem Zufalls-Byte auf dem Platter vom Schreibkopf angefahren und immer wieder gelöscht und beschrieben. Der Grund liegt darin, dass die Festplattensteuerung seit Urzeiten vom BIOS des Rechners übernommen wird und Anweisungen zur Lese-Schreibkopf-Position aus dem Betriebssystem kommen. Deshalb auch die Frage nach den Sektorgrößen beim Formatieren von logischen Laufwerken.

Theoretisch bräuchten SSDs überhaupt keine Sektoren mehr, sondern könnten wie RAM direkt adressiert werden. Versuche in der Richtung gibt es seit einiger Zeit mit SSD-optimierten Dateisystemen unter Linux.

Um es mit dem obligatorischen Autovergleich zu sagen: Weil die ersten Blinker per lastabhängiger Relaissteuerung arbeiteten, muss man heute das Klick-Klack-Geräusch per Lautsprecher erzeugen und den Laststrom der Glühbirnen elektronisch messen. Schließlich steht in irgendwelchen alten Normen drin, dass der Fahrer ein Klick-Klack hören muss beim Blinken und dass der Blinkgeber schneller takten muss wenn ein Birnchen durchgebrannt ist. Deshalb müssen Retrofit-LED-Birnchen auch einen Zusatzwiderstand haben, damit der Stromverbrauch so hoch ist wie bei ollen Glühbirnchen. Andernfalls blinkt deine moderne S-Klasse mit 120 Hertz. Vorn und hinten nur Workarounds. Möglich wäre schließlich auch, dass die LED-Birnchen ihre Funktion per Datenrückkanal digital über die Stromleitungen an den modernen Blinkgeber melden.


Alle Zeitangaben in WEZ +1. Es ist jetzt 19:19 Uhr.

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz