Win10 20H2 19042.450 defragmentiert SSD

Deine Frage passt nicht in die anderen Bereiche, dann stelle sie hier.
Javora
Superhirn
Superhirn
Beiträge: 1045
Registriert: 24.04.2016, 20:33
Hat sich bedankt: 10 Mal
Danke erhalten: 33 Mal

Re: Win10 20H2 19042.450 defragmentiert SSD

Beitrag von Javora » 05.10.2022, 23:31

Captain_Chris hat geschrieben: 23.08.2020, 14:09
lightman hat geschrieben: 22.08.2020, 18:05 bin kein IT Profi, hatte die Dferag natürlich sofort gestoppt, gehen die wirklich nicht zu Schrott ? :rofl:

Etwas Offtopic vielleicht
...

Als Beispiel nehmen wir eine 500 GB SSD. Und stellen uns vor, darauf täglich durch Optimierung/Defragmentierung einen Datenverkehr (eine "Beschreibung") von 50 GB zu verursachen...

1000 Schreibzyklen von 50 GB : 365 (Tage/Jahr) = 2,7 (Jahre)

Nun wird die SSD aber nicht ständig nur an einer Stelle (bzw. ständig auf den gleichen Zellen) beschrieben, sondern quasi "Ganzflächig". Also auf den gesamten 500 GB...

500 GB : 50 GB = 10 | x 2,7
= 27 Jahre
...

Ist eine Weile hier, ich weiß. Da kürzlich in einem Thread im Allgemeinen darauf Bezug genommen wurde,
aus eben diesem Anlass:


Könnte es sein, dass die reine Berechnung hier, alles Übrige außen vor (!), womöglich hinkt?

Bei Input Schreibzyklen ist vielfach folgende Formel publiziert:
(Schreibzyklen x Kapazität) / (SSD-Faktor x Datenmenge pro Jahr) =
Zeit (Jahre) bis zum Erreichen der Schreibzyklen


Als SSD-Faktor wird angegeben, es handle sich um
das Verhältnis der echten Datenmenge zu den tatsächlich geschriebenen Daten.
Ist dieses nicht angegeben/ bekannt, sei auf einen hohen Wert von 5 abzustellen.


Fragte mich, wie sich die Differenz von echter Datenmenge zu den tatsächlich geschriebenen Daten hier konkret definiert.
Zumindest ad hoc explizit wurde ich im Web dazu nicht fündig.
Der Formel nach muss die tatsächlich geschriebene Datenmenge höher sein als die echte.
Datenmenge.
Vorstellen könnte ich mir, dass dies mit der Art und Weise der Beschreibung auf der SSD im Zusammenhang steht (der Technologie) bzw. dazu gehört.
Vgl. bspw. knapp https://www.elektronik-kompendium.de/si ... 312261.htm

Wird nach obiger Formel mit den gewählten Ausgangsdaten und einem SSD-Faktor von 5 gerechnet, ergibt sich nicht ein Ergebnis von 27,40 Jahren, sondern von 5,48 Jahren (also 1/ 5).

Im Zähler: 1000 x 500 = 500 000
Im Nenner: 5 x 50 x 365 = 91 250
500 000 / 91 250 = 5,48


Bei der Gelegenheit, soweit es nunmehr bei den Inputs um TBW dgl. handelt, mögen für den privaten Anwender ggf. Online – Rechner nützlich sein.

Tante Google

Re: Win10 20H2 19042.450 defragmentiert SSD

Beitrag von Tante Google » 05.10.2022, 23:31


Benutzeravatar
Purgatory
★ Team Blog ★
Beiträge: 623
Registriert: 27.09.2018, 18:52
Hat sich bedankt: 9 Mal
Danke erhalten: 73 Mal
Gender:

Re: Win10 20H2 19042.450 defragmentiert SSD

Beitrag von Purgatory » 06.10.2022, 21:09

Dieses ganze hin und her gerechne im Bezug auf eine echte Defragmentierung ist für die Katz.
Das Problem ist nämlich der verbaute Controller auf der SSD den niemand beeinflussen kann, kein User, kein Windows, und ein Defragmentierer XY sowieso nicht.
Der große Unterschied liegt hier im Trim (also der Unterschied einer Windows Defragmentierung auf einer SSD und einer echten Defragmentierung) Befehl.
Trim macht, einfach gesagt, nichts anderes als die Zellen, auf denen sich gelöschte Daten befinden (ob gelöscht oder verschoben ist hier egal) via Betriebssystem an den Controller weiterzugeben. Dieser kann die Zellen jetzt löschen (sie müssen ja erst gelöscht werden bevor ein Schreibvorgang stattfinden kann) und sie für weitere Daten frei machen. Bis hier greift Trim, also die Software.

Jetzt aber kommt die Garbage Collection, die Hardware. Sprich eine im Controller selbst programmierte Routine die dafür sorgen soll alle Zellen möglichst gleichmäßig zu beschreiben. Wird eine Zelle dreimal beschrieben und die andere nur einmal, sorgt die Garbage Collection dafür, dass die nur einmal beschriebene Zelle möglichst als nächstes beschrieben wird bevor die andere, dreimal beschriebene Zelle, wieder beschrieben wird.
So soll eine gleichmäßige Abnutzung der Zellen erreicht werden was auch gut funktioniert.

Und jetzt kommen die Defragmentierer ins Spiel. Wie kurz angerissen kann ein Betriebssystem mit dem Controller nicht effektiv kommunizieren, es kann nur aufzeigen hier wurden Daten gelöscht, die Zelle ist ergo bereit für einen Löschvorgang.
Ein Defragmentierer wirft diese ganze Logik über den Haufen. Je nach Einstellung formiert er die Daten neu, möglicht nah beieinander. Folgend der Logik von mechanischen Festplatten die in Sektoren, Spuren, Köpfe etc. aufgeteilt sind. Ergo alle Daten möglichst dicht beieinander damit der Lesekopf, ohne Sprünge machen zu müssen, die Daten lesen kann. Bei einer SSD aber ist das komplett veraltet und nicht nur nicht zielführend, sondern sozusagen tödlich.

Die gesamte Logik vom Controller wird sozusagen über den Haufen geworfen und er darf die Daten komplett neu anordnen, nach der Defragmentierung wohlgemerkt. Was der Controller jetzt macht ist die Daten wieder zu verschieben, sprich auf nicht so oft genutzte Zellen, was wieder Schreibzugriffe sind, und somit eine Abnutzung der SSD. Das macht der Controller im stillen, also wenn die SSD sozusagen im Leerlauf ist, sowieso, aber lange nicht in diesen Ausmaßen.
Und genau diese Rechnungen führen dann in Nichts, insofern man eine echte Defragmentierung anstößt und die SSD halt nicht einfach laufen lässt. Weil niemand weiß was der Controller am Ende intern noch veranstaltet.

Da der Tröt so alt ist, lasst Windows inzwischen defragmentieren, ist nur ein TRIM Befehl. Und lasst die SSD einfach in Ruhe.
Wenn ich 64 Bit intus habe, kann ich auch alles :anstossen:

Hardware:
CPU: Ryzen 9 5900x MB: GA-X570 Aorus Master RAM: GSkill Trident Z Neo 2x16GB @3800 CL14 GPU: Asus TUF Gaming 6800 OC/UV SSD/HDD: Samsung 980 Pro 1TB, Kingston KC3000 2TB, WD Black SN850X 4TB, Samsung 870 Evo 4TB, Seagate ST4000DX001 PSU: BeQuiet! Straight Power Platinum 1000W Sound: Soundblaster Z Kühlung: Corsair iCUE H150i RGB PRO XT Case: Lian-Li O11 Dynamic

Antworten