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

Zum Inhalt wechseln

Nachrichten zum Thema: Hardware
  • 5 Seiten +
  • « Erste
  • 1
  • 2
  • 3
  • 4
  • 5

SSD defragmentieren

#61 Mitglied ist offline   Stefan_der_held 

  • Gruppe: Offizieller Support
  • Beiträge: 13.481
  • Beigetreten: 08. April 06
  • Reputation: 584

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: 330
  • Beigetreten: 14. Juni 12
  • Reputation: 38

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: 3.219
  • Beigetreten: 09. Februar 12
  • Reputation: 358

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.676
  • Beigetreten: 20. Juli 07
  • Reputation: 1.075

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: 330
  • Beigetreten: 14. Juni 12
  • Reputation: 38

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 Mitglied ist offline   d4rkn3ss4ev3r 

  • Gruppe: aktive Mitglieder
  • Beiträge: 4.413
  • Beigetreten: 03. Januar 09
  • Reputation: 635

geschrieben 04. Mai 2019 - 13:42

Es dürfte seit einigen Jahren keine SSDs mehr geben die nicht trim beherrschen
"Jene, die grundlegende Freiheit aufgeben würden, um eine geringe vorübergehende Sicherheit zu erwerben,
verdienen weder Freiheit noch Sicherheit." (Benjamin Franklin)


ACTA] | IPRED | SOPA | PIPA | CISPA | INDECT | TPP | TAFTA | Stop CETA + Stop TTIP + Stop TiSA
> Mein Hells Toolbox CMD Script <
0

#67 Mitglied ist offline   der dom 

  • Gruppe: aktive Mitglieder
  • Beiträge: 330
  • Beigetreten: 14. Juni 12
  • Reputation: 38

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.676
  • Beigetreten: 20. Juli 07
  • Reputation: 1.075

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: 2.038
  • Beigetreten: 04. Dezember 12
  • Reputation: 192

geschrieben 09. Mai 2019 - 22:04

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

#70 Mitglied ist offline   d4rkn3ss4ev3r 

  • Gruppe: aktive Mitglieder
  • Beiträge: 4.413
  • Beigetreten: 03. Januar 09
  • Reputation: 635

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!
"Jene, die grundlegende Freiheit aufgeben würden, um eine geringe vorübergehende Sicherheit zu erwerben,
verdienen weder Freiheit noch Sicherheit." (Benjamin Franklin)


ACTA] | IPRED | SOPA | PIPA | CISPA | INDECT | TPP | TAFTA | Stop CETA + Stop TTIP + Stop TiSA
> Mein Hells Toolbox CMD Script <
0

Thema verteilen:


  • 5 Seiten +
  • 1
  • 2
  • 3
  • 4
  • 5

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