Bei 5% Fragmetierung lohnt es sich mit Sicherheit nicht, aber wenn es Dich so sehr stört, kannst Du es natürlich machen, davon geht die SSD nicht kaputt. Ich würde es aber lassen und nur defragmentieren, wenn es wirklich extrem geworden ist. Der Effekt der Fragmentierung ist halt ungleich geringer als bei HDDs, denn während bei SSDs eben nur z.B. zwei kürzere statt einem langen Zugriff erfolgen, muss bei einer HDD auch noch der Kopf auf die neue Position gebracht werden, was realtiv lange dauert. Da das bei einer SSD weg fällt, macht sie die Fragmentierung da eben praktisch allenfalls bemerkbar, wenn sie extrem geworden ist.
Win 7 möchte SSD defragmentieren
- Ersteller YTF
- Erstellt am
xxMuahdibxx
Fleet Admiral
- Registriert
- Juli 2011
- Beiträge
- 35.683
Informier dich nochmal was TRIM bedeutet ...
Die SSD verwaltet ihre Speicherblöcke selber da kannst du defragmentieren wie du willst sie schreibts doch wo anders hin.
Die SSD verwaltet ihre Speicherblöcke selber da kannst du defragmentieren wie du willst sie schreibts doch wo anders hin.
Das spielt aber keine Rolle, wenn es um die Fragmentierung geht. Da Fragmentierung eine Sache des Filesystems ist und die Zugriffe nie länger als ein Fragment sein kann, kommt bei SSDs vor allem die Länge der Zugriffe ins Spiel, wenn es um Fragmentierung geht. Die kurzen Zugriffe sind langsamer, was man an den Werten bei synthetischen Benchmarks wie AS-SSD oder CrystalDiskMark gut sehen kann.Hallo32 schrieb:
Bei 4k Zugriffen schaffen die SSD lesend vielleicht so 20 bis 30MB/s, bei de langen sequentiellen Zugriffen über 4MB oder 16MB sind es dann 500MB/s. Nun werden die Fragmente kaum alle nur 4k kurz sein und schon bei 128k sind meist über 300MB/s, teils über 400MB/s drin, aber die Fragmentierung geht irgendwann auch bei SSD auf die Performance, nur bei weitem nicht so dramatisch wie bei HDDs.
Die Fragmentierung des Filesystems hat aber rein gar nichts mit der internen Verwaltung der Daten des Controller zu tun und damit, dass er die Daten intern sowieso ganz anders ablegt, weil es so die Performance optimiert und das Wear Leveling realisiert.
Das Ziel wird es immer sein die identische Datenmenge zu lesen.
Ob du nun mit einer Operation 128K liest oder in 32 parallelen Operationen mit 4k macht keinen spürbaren Unterschied.
Außerdem ist es noch ein Unterschied, wie die Daten vom Filesystem gelesen werden und welche IOPS endgültig bei der SSD ankommen.
Ob du nun mit einer Operation 128K liest oder in 32 parallelen Operationen mit 4k macht keinen spürbaren Unterschied.
Außerdem ist es noch ein Unterschied, wie die Daten vom Filesystem gelesen werden und welche IOPS endgültig bei der SSD ankommen.
Doch, wenn auch längst nicht wie bei HDDs. Schau Dir die Werte mit IOMeter in den Reviews an, die sind meist mit 128k ermittelt und die von CDM bei 4kQD32. Wobei 128k für eine moderne SSD ein kurzer Zugriff ist, der ATA Befehlssatz erlaubt bis zu 32MB, aber nicht jede SSD unterstützt das auch. Dann kann ich Dir nicht sagen, ob Windows schon so weit ist die Fragmente auch parallel zu lesen, was bei HDDs natürlich totaler Murks wäre. Wenn nicht, dann hast Du eben nur 4kQD1 und damit deutlich weniger. Aber selbst bei 4kQD32 kommt man über SATA 6Gb/s nie weit über 100.000IOPS bzw. 400MB/s, weil einfach der Overhead zu hoch ist, denn pro Befehl werden nur 4k gelesen, aber der Overhead eines Befehls und der Antwort sind der gleiche wie bei 32MB.Hallo32 schrieb:
Eben und daher kann ich Dir auch nicht sagen ob Windows die Fragmente wirklich parallel lesen kann. Die üblicherweise vom Treiber verwendeten ATA Befehle können bis zu 2^16 LBAs adressieren, also 32MB. In den Drive -Ident Daten gehen die Laufwerke an, wie viele LBAs sie pro Befehle maximal erlauben, das können also weniger als 2^16 sein und mehr darf der Treiber dann auch nicht in einem Befehl adressieren. Dann hängt es noch davon ab, wie viel Puffer der Treiber sich gönnt, denn mehr kann er auch nicht adressieren und vielleicht hat noch SATA Host Controller ein Pufferlimit, was zu berücksichtigen ist. Nun hat sich der Treiber aber nicht immer gleich den ganzen Puffer voll um den nicht gebrauchten Rest wegzuwerfen, sondern nie mehr als Windows von ihm fordert. Windows wird aber nie mehr verlangen als die Länge des Fragmentes, denn die Daten der nachfolgenden LBAs sind ja von einer anderen Datei die nicht interessieren. Die kleinste Einheit ist dabei üblicherweise ein Cluster, die größer eben die kleinste aus den oben genannten, wobei eben bei kurzen Fragmenten dann die Länge des Fragmentes bzw. der Rest davon bestimmend wird.Hallo32 schrieb:
Erlaubt der Treiber also nur 128k pro Zugriff und eine Datei ist genau in Fragmente von 128k Länge unterteilt, so macht die Fragmentierung nichts aus. Sind aber die Fragmente nun alle genau 132k groß, umfassen also einen Cluster mehr als am Stück gelesen werden kann, so müssen für jedes Fragment zwei Zugriffe erfolgen, eines über die erste 128k weil der Treiber, die Platte, der Hostcontrller oder war auch immer halt nicht mehr zulässt und eine zweit für die restlichen 4k. Wäre nun eine Datei 256k groß und läge in einem Fragment vor, also komplett in aufeinander folgenden Clustern und damit LBAs, so wäre nur zwei Zugriffe nötig. Ist nun das erste Fragment 132k und das zwei 124k groß, so erfolgt ein Zugriff auf die erste 128k des ersten Fragmentes, ein zweiter auf die letzten 4k und ein dritter auf die 124k des nächsten Fragments. Da kann man diesen 4k Zugriff auch nicht mit dem nächsten 124k Zugriffe zusammenlegen, weil eben keine aufeinanderfolgenden LBAs sind und die ATA Befehle erlauben nur die Adressierung eines LBAs und eben einer Anzahl der nachfolgender LBAs, aber eben nicht 8 LBAs ab X und dann noch noch 992 LBAs ab y, solche Befehle gibt es nicht.
Hoffentlich verstehst Du jetzt, wie sich die Fragmentierung des Filesystems auch auf die SSDs auswirken und wenn nicht, dann informiere Dich noch mal genauer, wie denn die Zugriffe auf SATA Laufwerke vom Programm bis zur Platte genau ablaufen.
NCQ kann es ermöglichen, aber dafür müsste Windows I/O System die Befehle zum Lesen der Fragmente auch parallel stellen, sonst nutzt NCQ gar nichts. Eine Datei zu lesen oder zu schreiben ist aber klassischerweise immer eine serielle Vorgehensweise, die Daten müssen ja auch wohin oder woher kommen und dann müsste man beim Lesen so viel Puffer haben, dass man die Teile dann wieder in der richtigen zusammenbauen kann, denn bei NCQ kommen die Daten ja nicht zwangsläufig in der Reihenfolge an, wie die Befehle abgeschickt wurden. Andererseits muss Windows dem Programm das sie angefordert hat, aber die Daten in der korrekten Reihenfolge liefern, denn Du willst ja Deinen Film von Anfang bis Ende so sehen wie er ist und nicht das der Player dauernd zwischen den Szene hin und her springt, so wie die Daten gerade von der Platte kommen. NCQ ist da also u.U. sogar kontraproduktiv, wenn die als nächstes benötigten Daten dadurch erst als letztes eintreffen. NCQ wird erst hilfreich, wenn parallel auf verschiedene Dateien zugegriffen wird und daher vermute ich auch mal, dass Windows die Fragmente überhaupt nicht parallele einliest.
Bei HDDs wäre das parallele Lesen der Fragmente auch deswegen Mist, weil es selbst mit NCQ natürlich nur um die Performance gehen darf, sondern ja auch kein Befehl ewig auf seine Abarbeitung warten soll. Sonst wäre zwar die durchschnittliche Antwortzeit besser, die maximale aber viel schlechter. Wie genau das gemacht wird, hängt natürlich von der FW der Platte ab und da würde sich eine normale Desktopplatte von einer für AV-Aufzeichnungen auch deutlich unterscheiden. Es könnte also im Prinzip passieren, dass dann bei dem Beispiel von vorhin mit de 132k und dem 124k Fragment erst der Befehl eingeht, die 128k des ersten Fragmentes zu lesen, dann der die 124k des zweiten und zuletzt der die restlichen 4k des ersten. NCQ würde sie natürlich so umsortieren dass dritte nach dem ersten abgearbeitet wird, entweder vor oder nach dem zweiten. Wäre das Beispiel nun größer und die Fragmente wären länger, so könnte es aber auch sein, dass der Controller nach dem abarbeiten des 1. Befehls entscheidet, dass der 2. schon zu lange wartet und den abarbeiten.
Wenn sowas nicht vorgesehen ist oder wäre, könnte es Dir aber z.B. passieren, dass Du im Hintergrund eine große Datei die Ende der Platte liegt z.B. auf die SSD kopierst und derweil eine kleine Textdatei die am Anfang liegt mit dem Editor öffnen möchtest und darauf warten muss, dass der Kopiervorgang beendet wird, weil sonst ja unnötige Kopfbewegungen entstehen. Der gesamte Vorgang des Kopieren und Öffnens der Dateien geht das mit NCQ schneller, aber wärst Du darüber dann auch wirklich glücklich?
Bei HDDs wäre das parallele Lesen der Fragmente auch deswegen Mist, weil es selbst mit NCQ natürlich nur um die Performance gehen darf, sondern ja auch kein Befehl ewig auf seine Abarbeitung warten soll. Sonst wäre zwar die durchschnittliche Antwortzeit besser, die maximale aber viel schlechter. Wie genau das gemacht wird, hängt natürlich von der FW der Platte ab und da würde sich eine normale Desktopplatte von einer für AV-Aufzeichnungen auch deutlich unterscheiden. Es könnte also im Prinzip passieren, dass dann bei dem Beispiel von vorhin mit de 132k und dem 124k Fragment erst der Befehl eingeht, die 128k des ersten Fragmentes zu lesen, dann der die 124k des zweiten und zuletzt der die restlichen 4k des ersten. NCQ würde sie natürlich so umsortieren dass dritte nach dem ersten abgearbeitet wird, entweder vor oder nach dem zweiten. Wäre das Beispiel nun größer und die Fragmente wären länger, so könnte es aber auch sein, dass der Controller nach dem abarbeiten des 1. Befehls entscheidet, dass der 2. schon zu lange wartet und den abarbeiten.
Wenn sowas nicht vorgesehen ist oder wäre, könnte es Dir aber z.B. passieren, dass Du im Hintergrund eine große Datei die Ende der Platte liegt z.B. auf die SSD kopierst und derweil eine kleine Textdatei die am Anfang liegt mit dem Editor öffnen möchtest und darauf warten muss, dass der Kopiervorgang beendet wird, weil sonst ja unnötige Kopfbewegungen entstehen. Der gesamte Vorgang des Kopieren und Öffnens der Dateien geht das mit NCQ schneller, aber wärst Du darüber dann auch wirklich glücklich?
Zuletzt bearbeitet:
Holt schrieb:
Die Dateien werden in der Regel in größeren Blöcken gelesen und geschrieben. Das Office Programm liest nicht jeden Buchstaben des Dokuments einzeln ein bzw. speichert jeden Buchstaben einzeln. Die Parallelisierung der Zugriffe kann auf die Anzahl der Segmente der Datei erfolgen. Der notwendige Arbeitsspeicher für die Sortierung sollte bei einem aktuellen System kein Problem sein.
Wobei man dieses evtl. durch den DMA Modus des Sata Controllers umgehen könnte. Naja, müsste man mal in der Spezifikation nachlesen.
Holt schrieb:
Siehe oben.
Holt schrieb:
Solange die maximale Anzahl an Rückstellung eines Befehls limitiert ist, sollte es zu keiner spürbaren Verzögerungen kommen. Wir gehen hier immer von Consumer Anwendungen aus.
Holt schrieb:
Das „viel“ müsste man genauer definieren. Wobei es in vielen Fällen eher darauf ankommt, dass die Summe der benötigten Zeit bis zum Abschluss des Vorgangs möglichst gering ist. Bei einer HDD dürfte die Zugriffszeit den größten Anteil an der Antwortzeit beitragen und diese kann mit einer optimierten Reihenfolge der Zugriffe reduziert werden und als Folge reduziert sich die benötigte Zeit des Vorgangs. Die maximale Antwortzeit für einen Zugriffe spielt bei Consumern eine geringe Rolle. Im Enterprise Bereich sieht es wieder anders aus.
Holt schrieb:
Die Personen, die bei den HDD Herstellern angestellt sind, werden solche Sachen schon bedacht haben und in der Firmware maximale Grenzen für das Zurückstellen eines Befehls integriert haben.
Vollkommen klar und selbst wenn das Programm nur Byteweise liest, puffert das Betriebssystem die Daten und liest sie bei Bedarf in größeren Blöcken. Das passiert z.B. über die C-Libs, wo früher 32k der Default waren.Hallo32 schrieb:
Das ist alles uralter Code und das I/O Subsystem in Windows ist auch nicht das aktuellste. Außerdem macht es auch keinen Sinn die Zugriffe zu parallelisieren, wenn ein Programm eine Datei seq. einliest. Nur weil es bei SSD ggf. etwas bringen würde, wird das aber so bald nicht eingebaut werden. Denke dran, die SW hängt den Möglichkeiten der HW meist um viele Jahre zurück!Hallo32 schrieb:
Wie Du selbst sagst:Hallo32 schrieb:
Da greift ein Prozess meist nur sequentiell auf eine Datei zu, wo parallele Zugriffe auf einzelne Teile eben kein Vorteil bringen würden, da der Prozess die Daten sequentiell haben will, man also immer das nächste Segment auch als nächstes liefern muss. Wann liest ein Programm schon mal eine größere Datei am Stück ins RAM und macht dem Bibliotheksfunktionen dafür einen so großen Puffer auf, dass da die ganze Dateien rein passen würde und parallele Zugriffe möglich wären? Und die wären dann auch nur bei SSDs sinnvoll.Hallo32 schrieb:
Theoretisch ist vieles denkbar, praktisch müsste der Programmierer das aber für den Spezialfall selbst so schreiben, denn standardmäßig arbeiten die Funktionen so wie immer und wie sie es schon seid langem machen. Da passt keiner aufwendig die Codes an, nur weil es in bestimmten Sondersituationen Vorteile geben könnte.
Wenn wirklich mal Random quer auf die Datei zugegriffen wird, wie bei Datenbanken oder VM Images, dann spielt die Fragmentierung der Datei ja sowieso keine Rolle.
Das hängt wieder sehr davon ab, wie viele Fragmente es gibt und wie groß die sind. Ist eine 1GB Datei in nur 2 Fragmente unterteilt und die liegen auch noch fast direkt hintereinander, so wird die Zugriffszeit praktisch keine Rolle spielen.Hallo32 schrieb:
Doch natürlich, es darf ja kein Zugriffe wegen eines Timeouts abgebrochen werden, nur weil im Hintergrund noch andere Zugriffe erfolgen.Hallo32 schrieb:
Da habe ich nie das was anderes behauptet, sondern genau das ja als Beispiel gebracht, warum es sich auch ist Gegenteil wenden könnte, wenn man da parallel lesen würde.Hallo32 schrieb:
Das die Hersteller sowas durchaus berücksichtigen, sieht man auch an der Vielzahl der Varianten von HDDs für unterschiedliche Einsatzgebiete. Auch wenn die sich teils nur durch die FW unterscheiden, so kann genau das schon einen großen Unterschied machen, auch wenn genau das viele User hier im Forum nicht wahrhaben wollen.
xxMuahdibxx
Fleet Admiral
- Registriert
- Juli 2011
- Beiträge
- 35.683
Hallo32 schrieb:
Die Festplatte die gleichzeitig 50 Fragmente auf 10 Verschiedenen Spuren gleichzeitig lesen kann muss noch erfunden werden.
Denn die meisten haben 1 Lese und Schreibkopfarm und der kann nur in 2-3-4 Platten gleichzeitig arbeiten an einer Spur.
Ne SSD arbeitet wie RAM da ist es egal wo es steht.
NCQ
Dort steht extra das die Festplatte entscheidet was sie macht um Kopfbewegungen zu vermeiden ... aber sie kann trotzdem nichts parallel machen !
Naja, die haben schon einen Kopf pro Plattern, bzw. pro Seite, aber parallel können sie die ganz offensichtlich trotzdem nicht nutzen, denn die Platten mit mehr Plattern sind ja nicht schneller als die kleineren Modelle der gleichen Baureihe mit weniger Plattern, sondern meist genau gleich schnell. Warum das so ist, kann ich auch nicht sagen, entweder weil man die Feinjustierung nicht für die Spuren auf mehreren Plattern gleichzeitig hinbekommt (vermute ich mal) oder weil man sich die zusätzliche Elektronik einfach sparen will.xxMuahdibxx schrieb:
Nicht ganz, in einer Dies bzw. Planes kann immer nur eine Page zur Zeit adressiert werden, weshalb SSD mit kleinen Kapazitäten und damit weniger NAND Dies auch langsamer sind als die gleichen Modelle mit größerer Kapazitäten also auch mehr NAND Dies.xxMuahdibxx schrieb:
Wie gesagt, bringt das nur bei gleichzeitigen Zugriffen auf verschiedene Dateien etwas, verlängert aber dadurch auch die Antwortzeit für den einen oder anderen konkreten Zugriff, weshalb man da Kompromisse machen muss.xxMuahdibxx schrieb:
