WinFuture-Forum.de: SSD defragmentieren - WinFuture-Forum.de

Zum Inhalt wechseln

Nachrichten zum Thema: Hardware
  • 8 Seiten +
  • « Erste
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8

SSD defragmentieren

#61 Mitglied ist offline   Stefan_der_held 

  • Gruppe: Offizieller Support
  • Beiträge: 14.289
  • Beigetreten: 08. April 06
  • Reputation: 885
  • Geschlecht:Männlich
  • Wohnort:Dortmund NRW
  • Interessen:Alles wo irgendwie Strom durchfließt fasziniert mich einfach weswegen ich halt Elektroinstallateur geworden bin :)

geschrieben 03. Mai 2019 - 22:17

Beitrag anzeigenZitat (der dom: 03. Mai 2019 - 19:20)

Ich glaube nicht, dass MS oder Dell oder die größeren Unternehmen HDDs im DB Cluster haben - nicht mal SSHDs (wobei die auch schon einen Schwung Schub bringen).


Unterschätze mal kein >12 SAS 15k RAID 6 ;)

das geht ab wie zäpfchen.

Im Serverbereich (zumindest meine bisherige Erfahrung) sollten eigentlich nur SLC SSDs eingesetzt werden. Diese sind allerdings auch saumäßig teuer weshalb lieber auf ein SAS-RAID gesetzt wird.
0

Anzeige



#62 Mitglied ist offline   der dom 

  • Gruppe: aktive Mitglieder
  • Beiträge: 578
  • Beigetreten: 14. Juni 12
  • Reputation: 73
  • Geschlecht:Männlich
  • Wohnort:Zuhause
  • Interessen:Mein Haus, meine IT, Programmierung

geschrieben 03. Mai 2019 - 22:26

Ich sag ja -> keine Consumer-SSDs.........

Bei allem was darunter liegt könnte ich kein DB Cluster ernst nehmen. Weder Oracle noch MS-SQL. Wenn HDD dann SAS und 15K - alles andere wäre heute eh zu langsam - selbst für eine Citrix oder eine reine RDP Farm bei Usern < 50.

MariaDB bzw. MySQL ist da vollkommen raus - die laufen auf einer anderen ebene und wären auch mit HDD noch ein ticken effizienter da auf eine ganz andere Umgebung ausgelegt....
Mit allem, was du tust, machst du offenkundig, mit welcher Einstellung du durch's Leben gehst. -- Steffen Glückselig
1

#63 Mitglied ist offline   Doodle 

  • Gruppe: aktive Mitglieder
  • Beiträge: 4.769
  • Beigetreten: 09. Februar 12
  • Reputation: 865
  • Geschlecht:Männlich

geschrieben 04. Mai 2019 - 12:38

Das stimmt nicht so ganz, dass eine Fragmentierung kein Problem auf SSDs wäre. Wenn eine SSD zu stark fragmentiert ist, kann dies zu Fehlern führen, wenn neue Daten auf die SSD geschrieben werden sollen. Mehr Dateifragmente bedeuten auch mehr Metadaten, die beim Lesen oder Schreiben verarbeitet werden müssen, was logischerweise zu einer geringeren Leistung führt. Die SSD wird deshalb manchmal einer Art Defragmentierung unterzogen, dies macht Windows aber standardmäßig selbst.

Das Problem ist hier sehr gut erklärt:

"First, yes, your SSD will get intelligently defragmented once a month. Fragmentation, while less of a performance problem on SSDs vs traditional hard drives is still a problem. SSDS *do* get fragmented.

It's also worth pointing out that what we (old-timers) think about as "defrag.exe" as a UI is really "optimize your storage" now. It was defrag in the past and now it's a larger disk health automated system.

Additionally, there is a maximum level of fragmentation that the file system can handle."

Dieser Beitrag wurde von Doodle bearbeitet: 04. Mai 2019 - 12:43

0

#64 Mitglied ist offline   RalphS 

  • Gruppe: VIP Mitglieder
  • Beiträge: 8.895
  • Beigetreten: 20. Juli 07
  • Reputation: 1.126
  • Geschlecht:Männlich
  • Wohnort:Zuhause
  • Interessen:Ja

geschrieben 04. Mai 2019 - 12:46

Der Witz ist ein anderer: Es gibt schlicht keinen Zugriff auf die Speicherzellen von außerhalb der SSD. Das macht alles der Controller.

* OS schickt Anforderungen für Adresse A1.
* Der Controller übersetzt das in Adresse S8 und greift auf diese zu.
* Der Controller schickt das Datum von Adresse S8 ans OS zurück und nennt es A1.

Das OS, und darauf laufende Software, IST NICHT in der Lage, die Anordnung von Daten auf dem Datenträger direkt zu beeinflussen.

Was es machen kann, ist, einen Datenstrom von SSD zu lesen, diesen in seinem Arbeitsspeicherbereich in irgendeiner Form umzustrukturieren und dann den Datenstrom als Ganzes an die SSD zurückzuschicken.

Ergebnis wäre außer dem zusätzlichen Lese- und Schreibaufwand, daß der SSD-Controller den jetzt eingehenden Datenstrom nach *seinem* Gutdünken auf die Speicherzellen (neu) verteilen kann. Idealerweise hat er dazu 100% unbelegte Zellen zur Verfügung, wenn man also von einem vollständigen Read-Write-Vorgang ausgeht, müßte die SSD mindestens 50% leer sein.


In dem Fall könnte man mehr oder weniger trivialerweise unterstellen, daß die SSD jetzt optimiert ist in bezug darauf, was der SSD-Controller für "optimal" hält.

Wenn wir unterwegs noch ein paar TRIMs einfügen, dann muß die SSD auch nicht mehr mindestens halbleer sein.

Das wäre dann buchstäblich ein delegierter Job.

Und dann darf man auch gerne pro O&O argumentieren:
- Ungünstig geschriebene Zelleninhalte wären im Idealfall weg, ansonsten gemindert, WENN der SSD-Controller das unter "optimal" versteht.
- Wenn zwei Zellen vorher halbvoll waren, sind hinterher eine voll, eine leer, WENN der SSD-Controller das unter "optimal" versteht.
- Es würde auch auf der SSD eine Insel mit zwei Bergen wachsen, WENN der SSD-Controller das unter "optimal" versteht.


Kurz, der potentielle SSD-Optimierer würde schlicht und ergreifend den SSD-Controller zwingen, bereits vorhandene Daten neu zuzuweisen, indem mehr oder weniger buchstäblich die SSD auf sich selbst geklont wird.


Ob und was das für praktische Vorteile hat und ob und was das für negative Auswirkungen hat, das lassen wir erstmal außen vor. Dazu müßte man wirklich erstmal einen Feldversuch starten mit X vielen SSDs aus X vielen Anwendungsszenarios und müßten jeweils Vorher und Nachher gegenüberstellen.

Erwartetes Ergebnis ist, daß sich einige Parameter verändert haben werden. Gemäß O&O sind darunter zumindest einige, welche für "irgendwen" vorteilhaft sind - zur Erinnerung, "optimal" heißt immer, eine Sache ist besser auf Kosten einer anderen; an dieser Stelle also vermutlich(!) Performance auf Kosten von Haltbarkeit.

Aber exakt das gälte es nachzuweisen, denn exakt daran mißt sich die Frage, ob ein realer Vorteil herauskommt ODER ob es tatsächlich das berüchtigte Schlangenöl ist.

Dieser Beitrag wurde von RalphS bearbeitet: 04. Mai 2019 - 12:48

"If you give a man a fish he is hungry again in an hour. If you teach him to catch a fish you do him a good turn."-- Anne Isabella Thackeray Ritchie

Eingefügtes Bild
Eingefügtes Bild
1

#65 Mitglied ist offline   der dom 

  • Gruppe: aktive Mitglieder
  • Beiträge: 578
  • Beigetreten: 14. Juni 12
  • Reputation: 73
  • Geschlecht:Männlich
  • Wohnort:Zuhause
  • Interessen:Mein Haus, meine IT, Programmierung

geschrieben 04. Mai 2019 - 13:28

Beitrag anzeigenZitat (Doodle: 04. Mai 2019 - 12:38)

Das stimmt nicht so ganz, dass eine Fragmentierung kein Problem auf SSDs wäre. Wenn eine SSD zu stark fragmentiert ist, kann dies zu Fehlern führen, wenn neue Daten auf die SSD geschrieben werden sollen. Mehr Dateifragmente bedeuten auch mehr Metadaten, die beim Lesen oder Schreiben verarbeitet werden müssen, was logischerweise zu einer geringeren Leistung führt. Die SSD wird deshalb manchmal einer Art Defragmentierung unterzogen, dies macht Windows aber standardmäßig selbst.


Da kommt TRIM ins Spiel - aber das unterstützen auch nicht alle SSDs. Alles andere regelt wie RalphS es gesagt hat und ich auch schon erwähnte der Controller der SSD.
Die Fragmentierung wird durch den Controller ausgelöst und ist so gesehen auch gewollt um eine vergleichsweise gleichmäßige Nutzung der Speicherzellen zu gewährleisten.

@RalphS: Solche Feldversuche wären tatsächlich interessant. Dabei wären natürlich die unterschiedlichen Anwendungsszenarien mit von maßgeblicher Natur.
Mit allem, was du tust, machst du offenkundig, mit welcher Einstellung du durch's Leben gehst. -- Steffen Glückselig
0

#66 _d4rkn3ss4ev3r_

  • Gruppe: Gäste

geschrieben 04. Mai 2019 - 13:42

Es dürfte seit einigen Jahren keine SSDs mehr geben die nicht trim beherrschen
0

#67 Mitglied ist offline   der dom 

  • Gruppe: aktive Mitglieder
  • Beiträge: 578
  • Beigetreten: 14. Juni 12
  • Reputation: 73
  • Geschlecht:Männlich
  • Wohnort:Zuhause
  • Interessen:Mein Haus, meine IT, Programmierung

geschrieben 04. Mai 2019 - 13:59

NA da sag mal sowas :-D - jetzt hast du mich zum Nachdenken gebracht und mir ist was lustiges in den Sinn gekommen.

MacOS hat immer behauptet, dass meine SSDs nicht TRIM fähig wären

Angehängtes Bild: Bildschirmfoto 2019-05-04 um 14.44.54.png

Mal flink nachgeschaut und mit trimforce enable das TRIM aktiviert.
Schön blöd :D

Dennoch hab ich so keine großen unterschiede festgestellt :unsure: :rolleyes:
Mit allem, was du tust, machst du offenkundig, mit welcher Einstellung du durch's Leben gehst. -- Steffen Glückselig
0

#68 Mitglied ist offline   RalphS 

  • Gruppe: VIP Mitglieder
  • Beiträge: 8.895
  • Beigetreten: 20. Juli 07
  • Reputation: 1.126
  • Geschlecht:Männlich
  • Wohnort:Zuhause
  • Interessen:Ja

geschrieben 04. Mai 2019 - 15:03

Trim hat nicht viel mit Fragmenten zu tun. Es hat prinzipiell nicht mal viel mit SSDs zu tun.

Trim hat was mit Flashspeicher zu tun, insbesondere MLC (an dieser Stelle MLC wie alles-was-nicht-SLC-ist).

Hintergrund:

- Betriebssysteme und "normale" Festplatten speichern Daten binär, 1 und 0, so-oder-so polarisiert gespeichert, Loch-oder-kein-Loch bzw so-oder-so-reflektiert (ODD) und so fort.

- Flash kann aber nicht bitweise speichern, ebensowenig wie RAM.

- Und MLC speichert nochmal *mehr* als ein Bit. Deswegen auch *M*-LC.

- Wenn jetzt ein Datum geschrieben werden soll, dann wird ein Datenblock geschrieben. Sagen wir der Einfachheit halber mit einer Blockgröße von 4kB (4096 Bytes; hier geht es um Technik, nicht um die Wirtschaft).

- Dann gibt es drei Situationen:
-A- Der Speicherblock mit seinen 4kB Platz ist ganz leer.
-B- Er ist ganz voll.
-C- Er ist *anteilig* voll.

- Bei MLC kommt obendrauf, daß die 4kB sich *unterschiedlich* verteilen können. Eine Zelle ist viertelvoll. Eine dreiviertel. Eine halb. Je mehr Zustände eine Zelle halten kann, desto variabler ihr möglicher Status.

Das hat mit Dateien nichts zu tun, eher mit Paketen oder Clustern oder halt einfach Dateisegmenten, wie man's sich am besten vorstellen kann.

Will ich jetzt eine Datei auf die SSD schreiben:

Fall A und ich kann einfach schreiben.
Fall B und ich muß die Zelle überspringen.
Fall C und ich muß
** die Zelle lesen und ihren Inhalt irgendwo halten (Cache)
** bekannt leere Positionen innerhalb der Zelle suchen
** diese mit dem neuen Datum beschreiben
** die gesamte Zelle zurückschreiben (alt + neu migriert)

muß also genau DAS tun, was man mit Flashzellen NICHT machen sollte, nämlich bitweise schreiben. Läßt sich aber nicht vermeiden, wenn Datenblöcke *kleiner* sind als das, was die SSD verbaut hat, also kleinere Dateien oder jeweils das letzte Fragment.


Dazu kommt erschwerend, daß der SSD-Controller *nicht* prüft, ob Zellen leer oder nichtleer sind. Das muß er gesagt kriegen.

Dateisysteme löschen aber Dateien nicht real, sondern sie deklarieren den Inhalt im Dateisystem als fürs Lesen ungültig. DOS hat damals den ersten Buchstaben zum "?" gemacht: kein gültiger Dateiname, ergo per definitionem "Datei gelöscht".

Das erfährt der SSD-Controller noch, aber er erfährt NICHT, daß er die Zellen freigeben könnte.


Stattdessen kommt über die Zeit der Punkt, wo der SSD-Controller Zellinhalte lesen und schreiben muß (Fall C oben) OBWOHL die zugehörige Datei gar nicht mehr existiert und EIGENTLICH Fall A eingetreten ist und der SSD-Controller das aber nicht weiß.

Hier kommt TRIM ins Spiel. TRIM gleicht den logischen Zustand (Datei gelöscht) mit dem physikalischen Zustand (Segment freigegeben) ab. Entsprechend muß das OS ebenso wie der Datenträger das unterstützen, einer zum "Befehlen" und der andere zum "Verstehen".

Der SSD-Controller muß nach TRIM nicht mehr die teure Option C wählen, sondern kann die preiswerte Option A greifen => Performancegewinn.


In *keinem* Fall existiert auf SSDs eine aufsteigende, lückenlose Folge von Segmenten, die aufeinanderfolgend Dateien und Ordnereinträge ergeben. Stattdessen werden Fragmente so geschrieben, daß sie ggfs. eher parallel gelesen und geschrieben werden können. Intern funktionieren SSDs daher eher wie ein RAID0 mit sovielen Platten, wie Chips verbaut sind. (Weswegen größere SSDs performanter sind als kleinere: mehr Zellen vorhanden und damit mehr Parallelzugriffe möglich, PLUS eine größere Wahrscheinlichkeit dafür, pro Zelle Fall A zu finden (schnell) als Fall C (lahmarschig).
"If you give a man a fish he is hungry again in an hour. If you teach him to catch a fish you do him a good turn."-- Anne Isabella Thackeray Ritchie

Eingefügtes Bild
Eingefügtes Bild
1

#69 Mitglied ist offline   IXS 

  • Gruppe: aktive Mitglieder
  • Beiträge: 4.397
  • Beigetreten: 04. Dezember 12
  • Reputation: 225

geschrieben 09. Mai 2019 - 22:04

Defragmentieren einer SSD sorgt für die Fragmentierung der SSD ;)
0

#70 _d4rkn3ss4ev3r_

  • Gruppe: Gäste

geschrieben 09. Mai 2019 - 22:10

IXS du bist doof.
Ich hatte bei Updates zu diesem Thread gehofft das "HSTGM STGM" antwortet und ich wieder was zum Lachen habe.
Stattdessen antwortest du mit einem korrekten Post.
Manno!
0

#71 Mitglied ist offline   HSTGM STGM 

  • Gruppe: aktive Mitglieder
  • Beiträge: 31
  • Beigetreten: 30. April 19
  • Reputation: 1

geschrieben 05. September 2019 - 14:14

Von O&O gibt es neuen Defrag Version 23.
Da wurde SOLID Verbessert.

https://www.oo-softw...oducts/oodefrag
https://blog.oo-soft...g-solidcomplete
0

#72 Mitglied ist offline   RalphS 

  • Gruppe: VIP Mitglieder
  • Beiträge: 8.895
  • Beigetreten: 20. Juli 07
  • Reputation: 1.126
  • Geschlecht:Männlich
  • Wohnort:Zuhause
  • Interessen:Ja

geschrieben 05. September 2019 - 14:38

Der Blogpost liest sich leider wie Augenwischerei. :huh:

Weniger Zellen in Benutzung gleich SSD performanter und langlebiger? Ich sag, nein, exakt das Gegenteil ist der Fall. Plus, selbstverständlich, das Problem der *physischen* Anordnung auf dem Datenträger, die weiterhin von der logischen abgekoppelt ist (auch O&O spricht immer nur von der logischen Anordnung).

Mich würd ja tatsächlich mal interessieren, was die da treiben, aber ich schätze, mit Details wird man da nicht herausrücken mit Verweis auf Geschäftsgeheimnisse.

Ich bleibe skeptisch: Ja, es gibt sicherlich Möglichkeiten, SSDs über das aktuelle Standardverhalten hinaus zu warten. Und ja, ein paar Optionen fallen da ein, gibt's hier im Thread ja schon. Aber, wenn es diesen Durchbruch tatsächlich *gäbe*, dann würde das recht schnell weltweit in der Fachpresse verteilt werden als Meilenstein in der SSD-Optimierung und O&O tät sich das Verfahren per Lizenzen vergolden lassen.

Passiert aber alles nicht. Stattdessen ist es bezeichnend still aus allen Richtungen. Ergo, Skepsis.
"If you give a man a fish he is hungry again in an hour. If you teach him to catch a fish you do him a good turn."-- Anne Isabella Thackeray Ritchie

Eingefügtes Bild
Eingefügtes Bild
2

#73 Mitglied ist offline   XiLeeN2004 

  • Gruppe: aktive Mitglieder
  • Beiträge: 580
  • Beigetreten: 16. Juni 04
  • Reputation: 50
  • Geschlecht:Männlich
  • Wohnort:Ahrensburg
  • Interessen:Aikidō (Godan), Schwimmen, Motorradfahren ('35er Indian Four, noch von meinem Vater), Dampfmodellbau, Kino

geschrieben 05. September 2019 - 16:36

Alles Relevante in Bezug auf Tempo und Langlebigkeit regelt schon der Controller der SSD. Fertig...
Eingefügtes Bild
0

#74 Mitglied ist offline   HSTGM STGM 

  • Gruppe: aktive Mitglieder
  • Beiträge: 31
  • Beigetreten: 30. April 19
  • Reputation: 1

geschrieben 05. September 2019 - 20:30

Die Programmierer bei O&0 haben das sehr lange getestet....wenn die Experten Profis extra Defrag Optmierung für SSD das SOLID Methode gemacht haben, und es als sinnvoll rausgestellt hat, wird es schon was bringen damit die SSD noch besser zu Optimieren, die haben das auch nicht ohne gründe gemacht die SSD SOLID Methode, wenn nachteilig gewesen wäre, hätten die bei O&O nicht Optimierung Methode für SSD gemacht.
Die haben z.b hier ausfühlich beschrieben das SSDs auch Optimierungen sollte.
https://www.oo-softw...oducts/oodefrag
https://blog.oo-soft...entieren-konnen
Bei neuen O&O Defrag 23 gibt es jetzt 2 SOLID Methoden.
SOLID Quick
SOLID Complete
Und SSD ClusterView ist neu bei O&O Defrag 23.

Ihr sollt schon alle glauben und den Experten, Programmierer die länger getetet, ausprobiert haben, das auch SSD fragmentiert und man wieder Optimieren sollte, da hat O&O schon mit V22 die SOLID Methode eingeführt, und jetzt bei neuen O&O Defrag 23 haben SOLID noch weiter verbessert, gleich 2 SOLID Methoden eingeführt.

Dieser Beitrag wurde von HSTGM STGM bearbeitet: 05. September 2019 - 20:33

0

#75 Mitglied ist offline   Doodle 

  • Gruppe: aktive Mitglieder
  • Beiträge: 4.769
  • Beigetreten: 09. Februar 12
  • Reputation: 865
  • Geschlecht:Männlich

geschrieben 05. September 2019 - 21:27

Beitrag anzeigenZitat (XiLeeN2004: 05. September 2019 - 16:36)

Alles Relevante in Bezug auf Tempo und Langlebigkeit regelt schon der Controller der SSD. Fertig...

Ist klar. Alles muss für immer bleiben, wie es ist.

Innovation? Alles Spinner. Farbfernsehen verdirbt die Phantasie. Wer braucht schon das Internet? Ja, das ist Neuland ... oh man oh mann ....

Sorry, aber diese Argumentation greift echt zu kurz.

Wer von euch traut sich außer den üblichen Phrasen zu, das zu erklären, was O&O falsch macht?

Allgemeines BlaBlaBla ist leicht.

Beitrag anzeigenZitat (XiLeeN2004: 05. September 2019 - 16:36)

Alles Relevante in Bezug auf Tempo und Langlebigkeit regelt schon der Controller der SSD. Fertig...

XP wäre deine erste Wahl, oder?
0

Thema verteilen:


  • 8 Seiten +
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8

1 Besucher lesen dieses Thema
Mitglieder: 0, Gäste: 1, unsichtbare Mitglieder: 0