840 evo 1 TB ist lahm auf "alten" Daten

[klampf]

Der HD Tune Test liesst sektorenweise und scheint keine Relevanz für das lesen von Dateien zu haben. Bei mir zeigt er so 200MB/s für den Grossteil der EVO an (ist 80% voll) aber wenn ich Dateien mit meinem Tool lese (oder mit Explorer auf die 830 kopiere) dann kriege ich Leseraten zwischen 350MB/s und 480MB/s.

Vielleicht findest Du aber auch noch langsame Files, so wie es bei mir war.

Schön, dass Du Dir die Zeit nimmt für so ein passendes Tool.

Bei der 830er zeigt HD Tune Werte zw. 350MB/s und 400MB/s. Dateien werden aber immer nochmal schneller gelesen.

Das kann man aber auch anders erklären. Das sind einfach verschiedene Arten des Lesens. Buffered/Unbufferd z.B.

 

[Blublah]

Vielleicht findest Du aber auch noch langsame Files, so wie es bei mir war.

Also bis jetzt, SSD is erst 2 Wochen alt, kann ich das ausschliessen.

Schön, dass Du Dir die Zeit nimmt für so ein passendes Tool.

Ach ja, ist ganz spassig. Ausserdem lernt man ja immer etwas dabei

 

[Holt]

Was ich allerdings festgestellt habe ist, dass selbst die sequentielle Leserate recht stark vom eingestellten Energiesparmodus abhängt. Auch bei meiner Samsung 830 liegt zwischen 'Power Saver' und 'High Performance' Modus 100MB/s Unterschied.

Das ist klar, die Energiespareinstellungen gehen immer auf die Performance, aber die erklären dann nicht, warum eine Daten so deutlich langsamer gelesen wird als eine andere, zumindest nicht wenn sich das Verhalten reproduzieren lässt. Es könnte aber den Effekt der Fragmentierung durch das Filesystem verstärken, wenn die SSD schon bei den kurzen Pausen zwischen einzelnen Fragmenten in einen Energiesparzustand geht.

Daher würde ich jeden bitten der das erlebt doch mal die Fragmentierung der betreffenden Dateien einmal mit Contig -a zu analysieren.

 

[Blublah]

die Energiespareinstellungen gehen immer auf die Performance, aber die erklären dann nicht, warum eine Daten so deutlich langsamer gelesen wird als eine andere, zumindest nicht wenn sich das Verhalten reproduzieren lässt.

Innerhalb eines Modus ist die Performance auch jeweils recht konsistent. Der Screenshot zeigt das Ergebnis der Messungen während ich von 'Energy Saver', auf 'Balanced', auf 'High Performance' schalte (jeweils nach 5 Dateien).

In ein paar Tagen sollte ich auch ne 1. Version des Tools zum hochladen fertig haben. Vllt schaffe ich ja noch einen einfachen Datenexport damit man die Ergebnisse dann z.B. noch selber statistisch auswerten kann.

 

[klampf]

Es könnte natürlich ein Fehler in meinem Programm sein aber vllt. gibt es auch eine andere Erklärung. Hat da jemand eine Vermutung?

Vermutungsidee

AFIRC kann Windows nicht nur Dateien aus dem Cache laden, sondern die ggf. auch einfach mappen. D.h. im Prinzip bekommst Du einen Pointer auf den Speicher im Cache zurück und es findet nicht einmal ein Kopiervorgang Speicher->Speicher statt.

So ganz theoretisch, Du öffnest die Dateien ja vermutlich read_only, also kann Dir das System eigentlich irgendwas geben, das schon im Speicher ist. Wäre mal spannend, ob sich was ändert, wenn Du die Dateien z.B. r/w öffnest.

Noch ein Gedanke:
Verwendest Du zur Berechnung die Größe der Datei aus dem Filesystem oder guckst Du, wieviel Du wirklich lesen kannst?
Das könnte bei links evtl. interessant sein?

Es fällt schon auf, das es in Deinem Beispiel nun gerade 2 dlls sind.

 

[Blublah]

Update wegen den zu hohen Leseraten bei einigen Dateien in meinem Tool:

Hat sich aufgeklärt, war natürlich ein Programmierfehler
Hatte vergessen das Flag über das erfolgreiche Lesen der Datei in dem Hauptthread mit der Listenanzeige abzufragen.

Verwendest Du zur Berechnung die Größe der Datei aus dem Filesystem oder guckst Du, wieviel Du wirklich lesen kannst?

Die Dateigrösse die ich in dem Listview anzeige wird mit der tatsächlich gelesenen Dateimenge verglichen. Falls weniger gelesen werden konnte, wird die Datei gar nicht erst in der Liste angezeigt.

Der Code ist recht kurz:

DWORD flags = FILE_FLAG_SEQUENTIAL_SCAN;
HANDLE f = CreateFile(path, GENERIC_READ,FILE_SHARE_READ, 0, OPEN_EXISTING, flags, 0);
if (f == INVALID_HANDLE_VALUE) return 0;

long long tot = 0;
const DWORD MB = 1024*1024;
char buf[MB]; // 1MB Puffer auf dem Stack
do {
DWORD bytes = 0;
if (!ReadFile(f, buf, MB, &bytes, 0)) break;
tot += bytes;
} while (bytes == MB);

CloseHandle(f);

return tot == fs ? tot : 0;
// vergleich ob die eingelesene Datenmenge auch der Dateigrösse entspricht, wenn nicht gib 0 zurück (->Datei wird nicht gelistet)


Edit:
Hab jetzt das Flag 'FILE_FLAG_NO_BUFFERING' verwendet. Damit fallen die 4GB/s - 5GB/s weg.


Edit 2:

Ich sehe zwar nicht wo fs herkommt, aber da wird schon stimmen und den Rest kann ich nachvollziehen.

fs kommt von aussen von dem 'DirectoryWalker' und dessen FindFirst- und FindNextFile Funktionen.

 

[klampf]

Ich sehe zwar nicht wo fs herkommt, aber da wird schon stimmen und den Rest kann ich nachvollziehen.

 

[Holt]

Innerhalb eines Modus ist die Performance auch jeweils recht konsistent. Der Screenshot zeigt das Ergebnis der Messungen während ich von 'Energy Saver', auf 'Balanced', auf 'High Performance' schalte (jeweils nach 5 Dateien).

Wie viel wird direkt beim Umschalten eingestellt und wie viel erst beim nächsten Booten? Während es Tests umzuschalten halte ich für unsinnig.

Hatte vergessen das Flag über das erfolgreiche Lesen der Datei in dem Hauptthread mit der Listenanzeige abzufragen.

Welchen Timer nimmst Du? Beachte, dass die Hochauflösenden Timer nur korrekt sind, wenn man den Thread in dem man sie abfragt fest an einen Kern bindet, da es wegen des Rauf- und Runtertaktes der einzelnen Kerne zu teils massiven Abweichungen zwischen ihnen kommen kann.

Wenn man die gleiche Datei mehrfach liest, hat Windows halt normalerweise immer was im Cache.

 

[Blublah]

Wie viel wird direkt beim Umschalten eingestellt und wie viel erst beim nächsten Booten? Während es Tests umzuschalten halte ich für unsinnig.

Wieso, die Ergebnisse innerhalb eines Energiesparmodus sind sehr konsistent (3-8MB/s maximale Differenz) und verglichen mit den Unterschieden zwischen den Modi (35MB/s von sparsam auf normal und 70MB/s von normal auf hohe Performance) sehr klein. Jedesmal neu booten kostet auch Zeit von der ich eh wenig habe

Welchen Timer nimmst Du? Beachte, dass die Hochauflösenden Timer nur korrekt sind, wenn man den Thread in dem man sie abfragt fest an einen Kern bindet, da es wegen des Rauf- und Runtertaktes der einzelnen Kerne zu teils massiven Abweichungen zwischen ihnen kommen kann.

Ich benutze QueryPerformanceCounter. Probleme ohne die Core Affinity zu setzen sollten eigentlich nur bei verbuggtem BIOS bzw Mobo auftreten, zumindest laut MS:

On a multiprocessor computer, it does not matter which processor the thread runs on. However, because of bugs in the BIOS or the Hardware Abstraction Layer (HAL), you can get different timing results on different processors.

Auf meinem Board konnte ich beim experimentieren mit Thread Affinity jedenfalls keine Unterschiede feststellen. Hab es aber zur Sicherheit trotzdem gesetzt. Ansonsten scheint bei den Timern noch wichtig zu sein, dass man sie in dem gleichen Thread aufruft, was ich mache.

 

[C0B]

Bei der Defragmentierung werden Daten nach bestimmten "Optionen" aneinandergereiht und zwar von der Plattenaußenseite (schneller) hin zur Platteninnenseite (langsamer).
Mit Optionen meine Ich - Datenstrukturen.
Zum Beispiel:
Defragmentieren nach Dateityp
Defragmentieren nach Ordnername
Defragmentieren nach Dateigröße
Defragmentieren nach "Häufigkeit" der Aufrufe
usw. usf.

Das alles TRIFFT auf eine SSD nicht zu und ist komplett irrelevant!
Bei einer SSD gibt es schlichtweg keinen Lesekopf der über die Scheibe wandert.

Die Windows-Defragmentierung ist noch dazu ziemlicher Schwachsinn da die einfach nur "Löcher" füllt aber die Dateistruktur nicht berücksichtigt.
Eine sinnvolle Defragmentierung kann man nur mit zusätzlichen Tools durchführen.

Ein paar älteren Dateien in der Größe von 2 GB werden allerdings nur mit 80 MB/s gelesen

Dann wird der SSD Controller vermutlich Daten die häufiger verwendet werden "anders" ablegen bzw. intern auf der SSD "verschieben" so dass die Daten schneller gelesen werden können.
Im Sinn der SSD - Nicht im Sinn der HD!

 

[Holt]

Schwachmaten sollten den Rand halten, wenn sie die Zusammenhängen nicht verstehen. Dass die Länge der Zugriffe von der Länge der Fragmenten abhängt braucht man ebensowenig zu diskutieren wie die Tatsache, dass SSD bei kurzen Zugriffen weniger hohe Zugriffsraten erreichen wie bei langen. Mit Köpfen hat das nichts zu tun, außer mit dem grauen Zeug darin, was bei einigen Leute vor allen ein Vakuum verhindert, weil sie offenbar die Zusammenhänge nicht begreifen wollen oder können die es zwischen der Länge der Zugriffe und en Lücken in der Dateinstruktur / der Fragmentierung der Dateien - neu angelegter Dateien des Filesystems gibt.

Das nervt langsam wenn hier Leute immer nur mti dem Argument der Kopfbewegungen ankommen, welches das Problem der Fragmentierung nun wirklich nicht hinreichend abdeckt, wie ich schon auf Seite 2 dieses Threads erklärt habe. Wer also mit diesem Mist kommt, der erkläre dann bitte auch, wieso die Fragmentierung von Dateien bei SSD keinerlei Einfluss auf die Performance haben kann, wie also auch bei stark fragmentieren Dateien noch so lange Zugriffe möglich sein sollen, dass die SSD die volle Performance erreichen. Und sagt nicht weil überall steht, dass man SSD nicht defragmentieren soll / darf / braucht. Weil etwas überall steht, wird es nicht wahrer, sonst wären die Juden und nicht die Nazis von 1933 bis 1945 der wahre Feind Deutschlands gewesen, dann das stand ja auch überall.

 

[Madnex]

Holt, schalte bitte einen Gang runter und beruhige dich erst Mal.

Und sagt nicht weil überall steht, dass man SSD nicht defragmentieren soll / darf / braucht. Weil etwas überall steht, wird es nicht wahrer [...]

Dass das überall steht, ist übrigens nicht richtig. Als zur SSD-Anfangszeit, als die ersten SSD-Modelle für den Verbraucher auf den Markt kamen, haben manche Hersteller sogar empfohlen ihre SSDs gelegentlich zu defragmentieren. So z.B. Mtron.

Die Windows-Defragmentierung ist noch dazu ziemlicher Schwachsinn da die einfach nur "Löcher" füllt aber die Dateistruktur nicht berücksichtigt.
Eine sinnvolle Defragmentierung kann man nur mit zusätzlichen Tools durchführen.

Windows analysiert während des Betriebs die Zugriffsmuster und ordnet bei der Defragmentierung mit dem eigenen Tool die Daten entsprechend an. Das ist viel effektiver als die Dateien stumpf nach Dateityp, Ordnername, Dateigröße, Häufigkeit der Aufrufe usw. zu sortieren.

 

[Hallo32]

... weil sie offenbar die Zusammenhänge nicht begreifen wollen oder können die es zwischen der Länge der Zugriffe und en Lücken in der Dateinstruktur / der Fragmentierung der Dateien - neu angelegter Dateien des Filesystems gibt.

Hast du Zahlen, die die Auswirkung der Fragmentierungen wiedergeben?
Die Theorie ist mir bekannt. Mir geht es um die Auswirkungen im täglichen Einsatz.

Das Einlesen einer nicht fragmentierten 97,65625 MB großen Datei dauert 388,492 ms.
Das Einlesen einer fragmentierten Version der identischen Datei, bestehend aus 6 Fragmenten, dauert 389,557 ms.
Somit ergibt sich für diesen Fall ein Unterschied von 0,2 %.

Um ein Cachen der Dateien auszuschließen fand zwischen der Erstellung der Dateien und des Test ein Reboot statt. Bei der Verwendung des Caches befinden sich die Zeiten bei ungefähr ein Zehntel.

File size of file is 102400000 (25000 blocks of 4096 bytes)
ext: logical_offset: physical_offset: length: expected: flags:
0: 0.. 255: 236800.. 237055: 256:
1: 256.. 2047: 233472.. 235263: 1792: 237056:
2: 2048.. 4095: 231424.. 233471: 2048: 235264:
3: 4096.. 14335: 239616.. 249855: 10240: 233472:
4: 14336.. 24575: 253952.. 264191: 10240: 249856:
5: 24576.. 24999: 295988.. 296411: 424: 264192: eof
file: 6 extents found

 

[Holt]

Als zur SSD-Anfangszeit, als die ersten SSD-Modelle für den Verbraucher auf den Markt kamen, haben manche Hersteller sogar empfohlen ihre SSDs gelegentlich zu defragmentieren. So z.B. Mtron.

Die wussten auch wieso, dass kann der Controller nämlich nicht ausgleichen und SSDs ziehen die Perfomance auf der Parallelität.

Hast du Zahlen, die die Auswirkung der Fragmentierungen wiedergeben?
Die Theorie ist mir bekannt. Mir geht es um die Auswirkungen im täglichen Einsatz.

Das hängt von der jeweiligen SSD ab, die haben je eine unterschiedlichen Entwicklung der Transferraten über die Zugriffslängen. ATTO bencht das ja, wenn auch mit 4 I/O, kommt also auf ungleich bessere Werte als bei QD1. Man sieht aber trotzdem gut, dass dort meist erst bei Zugriffen über 128k die vollen Transferraten erreicht werden, bei einigen SSDs früher bei anderen später. Wenn die Fragmente natürlich immer noch weit größer sind, so kommt es allenfalls am Ende des Fragmentes, also beim jeweils letzten Zugriff zu einem der wirklich kurz ist und der spielt dann keine Rolle und sollten alle Fragmente genau Vielfache der Länge der ausgeführten Zugriffe sein, so spielt der Fragmentierung wirklich mal keine Rolle.

Wobei das auch nicht ganz stimmt, in den letzten beide SSD Reviews hat ocaholic.ch einen interessanten Test eingeführt, hier bei der OCZ ARC und wenn ich das richtig interpretiere und die keine Fehler gemacht haben, dann liest die auch bei 4k Zugriffen und QD1 seq. mit 402MB/s, was etwa Limit bei so kurzen Befehlen ist. Bei Randomzugriffen liest sie nur mit 21MB/s, es werden also offenbar intern schon die Daten der nachfolgenden LBAs bereitgestellt. Leider gibt es den Test bei älteren Reviews nicht, sondern nur bei den letzten beiden SSDs mit dem Barefoot3 Controller und so kann man nicht sagen, wie sich andere SSDs da verhalten.

Das Einlesen einer nicht fragmentierten 97,65625 MB großen Datei dauert 388,492 ms.
Das Einlesen einer fragmentierten Version der identischen Datei, bestehend aus 6 Fragmenten, dauert 389,557 ms.
Somit ergibt sich für diesen Fall ein Unterschied von 0,2 %.

6 Fragmente sind bei 97,6MB dann im Schnitt noch immer über 16MB pro Fragmente. Damit wird immer noch das allermeiste mit sehr langen Zugriffen gelesen und es kommen nur wenige kurze Zugriffe hinzu. Bei einer HDD wäre der Unterschied auch noch noch so dramatisch, da hättest Du 5 mehr oder weniger lange Kopfbewegungen zu den ersten LBAs der jeweiligen Fragmente, aber die machen dann natürlich Verhältnis schon viel mehr aus als 0,2%.

Wenn Du es ausprobieren willst, dann schreibe ein kleines Programm oder Script welches eine Partition mit 4k (Clustergröße auch 4k) großen und von 1 an durchnummerierten Dateien füllt, lösche die Dateien mit geraden Nummern und benche dann., z.B. mit dem AS-SSD. Damit müsstest Du die maximale Fragmentierung erreichen und kannst die Werte dann vergleichen.

 

[Hallo32]

Wobei das auch nicht ganz stimmt, in den letzten beide SSD Reviews hat ocaholic.ch einen interessanten Test eingeführt, hier bei der OCZ ARC und wenn ich das richtig interpretiere und die keine Fehler gemacht haben, dann liest die auch bei 4k Zugriffen und QD1 seq. mit 402MB/s, was etwa Limit bei so kurzen Befehlen ist. Bei Randomzugriffen liest sie nur mit 21MB/s, es werden also offenbar intern schon die Daten der nachfolgenden LBAs bereitgestellt. Leider gibt es den Test bei älteren Reviews nicht, sondern nur bei den letzten beiden SSDs mit dem Barefoot3 Controller und so kann man nicht sagen, wie sich andere SSDs da verhalten.

SSD: M4 256GB Sata 2

Diskcache deaktiviert:

iozone -Rb test4k3.xls -i0 -i1 -i2 -+n -r 4k -s4g -t1
Throughput report Y-axis is type of test X-axis is number of processes
Record size = 4 Kbytes
Output is in Kbytes/sec
Initial write 164392,7031
Rewrite 0
Read 1375048,75
Re-read 0
Random read 588539,4375
Random write 6299,544434

Diskcache aktiviert:

iozone -Rb test4k2.xls -i0 -i1 -i2 -+n -r 4k -s4g -t1
Throughput report Y-axis is type of test X-axis is number of processes
Record size = 4 Kbytes
Output is in Kbytes/sec
Initial write 204338,5156
Rewrite 0
Read 1312996,375
Re-read 0
Random read 560491,375
Random write 86702,42188

Der Benchmark erzeugt bei mir teilweise komische Werte und ist daher nicht sehr vertrauenswürdig.

Ergänzung (2. September 2014)

Wenn Du es ausprobieren willst, dann schreibe ein kleines Programm oder Script welches eine Partition mit 4k (Clustergröße auch 4k) großen und von 1 an durchnummerierten Dateien füllt, lösche die Dateien mit geraden Nummern und benche dann., z.B. mit dem AS-SSD. Damit müsstest Du die maximale Fragmentierung erreichen und kannst die Werte dann vergleichen.

Die Idee mit den Schachbrettmuster mit belegten und nicht belegten Clustern klingt gut. Aber wie stellst du sicher, dass beim Erstellen der Dateien im folgenden Cluster einer "geraden Datei" immer eine "ungerade Datei" folgt?
Das Windows die Cluster verlässlich in auf- bzw. absteigender Reihenfolge füllt wäre mir neu.

Ergänzung (2. September 2014)

... es werden also offenbar intern schon die Daten der nachfolgenden LBAs bereitgestellt.

Dürfte im Prinzip ein Read-Ahead wie bei den HDDs sein. Bietet sich im Prinzip ja auch an.

Ergänzung (2. September 2014)

6 Fragmente sind bei 97,6MB dann im Schnitt noch immer über 16MB pro Fragmente.

Kleinere Fragmente ließen sich ohne großen Aufwand nicht erzeugen.

 

[Holt]

Der Benchmark erzeugt bei mir teilweise komische Werte und ist daher nicht sehr vertrauenswürdig.

Die Leseraten sind zu hoch, oder was meinst Du? Entweder ein Fehler bei den Einheiten oder Windows könnte mal wieder irgendwo cachen. Aber die Schreibraten passen ja und außerdem seht man bei Random schlechtere Wert also bei seq.

Die Idee mit den Schachbrettmuster mit belegten und nicht belegten Clustern klingt gut. Aber wie stellst du sicher, dass beim Erstellen der Dateien im folgenden Cluster einer "geraden Datei" immer eine "ungerade Datei" folgt?

Sicherstellen kannst Du es nicht und das Muster wird wegen der wachsenden Metadaten hier und da Fehler haben, aber woher sollte Windows bei der Vergabe der Cluster ahnen können, dass gerade jede zweite Datei gelöscht werden wird? Wenn die Partition frisch formatiert ist, werden die Cluster auch der Reihe nach vergeben, Bereiche der für den MFT reserviert werden dabei ausgenommen, zumindest solange woanders noch Platz ist. Es sollte hinreichend gleichmäßig verteilte und kleinen Lücken erzeugen.

Das Windows die Cluster verlässlich in auf- bzw. absteigender Reihenfolge füllt wäre mir neu.

Beim ersten Beschreiben müsste das mehr oder weniger passen, auch wenn die ersten Dateien vielleicht nicht bei 0 angelegt werden, aber man kann es ja mit der Analyse z.B. von MyDefrag dann auch leicht prüfen, wo die Dateien angelegt wurden.

Dürfte im Prinzip ein Read-Ahead wie bei den HDDs sein. Bietet sich im Prinzip ja auch an.

Ja, das ergibt sich ja schon von der Pagesize, wenn eine Page 8k oder gar 16k groß ist, habe ich nach dem Auslesen ja im Prinzip schon die Daten für den nächsten oder die drei nächsten Cluster im Cache der SSD, sofern diese eben wirklich in der Page stehen, was aber wahrscheinlich ist, wenn alle zusammen geschrieben wurde. Da würde ich ja nicht auch noch Daten über NANDs verteilen, die auch in eine Page passen würden.

 

[Hallo32]

Wenn Du es ausprobieren willst, dann schreibe ein kleines Programm oder Script welches eine Partition mit 4k (Clustergröße auch 4k) großen und von 1 an durchnummerierten Dateien füllt, lösche die Dateien mit geraden Nummern und benche dann., z.B. mit dem AS-SSD. Damit müsstest Du die maximale Fragmentierung erreichen und kannst die Werte dann vergleichen.

Eine Partition dürfte nicht reichen. 25% Testpartition, 75% Windows Partition und davon 50% frei. Wenn die SSD hinreichend groß ist, dürfte der "freie Speicherplatz" der Windows Partition gebencht werden und nicht die Testpartition mit ihren Schachbrettmuster.

Ergänzung (3. September 2014)

Sicherstellen kannst Du es nicht und das Muster wird wegen der wachsenden Metadaten hier und da Fehler haben, aber woher sollte Windows bei der Vergabe der Cluster ahnen können, dass gerade jede zweite Datei gelöscht werden wird? Wenn die Partition frisch formatiert ist, werden die Cluster auch der Reihe nach vergeben, Bereiche der für den MFT reserviert werden dabei ausgenommen, zumindest solange woanders noch Platz ist. Es sollte hinreichend gleichmäßig verteilte und kleinen Lücken erzeugen.

Dass das Muster nicht absolut fehlerfrei ist, habe ich auch nicht erwartet. Beim Test heute konnte ich nur beobachten, dass die Sektoren scheinbar wahlfrei verwendet wurden und kein Muster zu erkennen war.

Ergänzung (3. September 2014)

Ja, das ergibt sich ja schon von der Pagesize, wenn eine Page 8k oder gar 16k groß ist, habe ich nach dem Auslesen ja im Prinzip schon die Daten für den nächsten oder die drei nächsten Cluster im Cache der SSD, sofern diese eben wirklich in der Page stehen, was aber wahrscheinlich ist, wenn alle zusammen geschrieben wurde. Da würde ich ja nicht auch noch Daten über NANDs verteilen, die auch in eine Page passen würden.

Zumindest beim letzten Cluster müsste man einmal gezielt den nächsten Cluster lesen. Beim Trimmen bzw, Zusammenfassen der noch gültigen Daten müsste man dieses ebenfalls beachten. Der Aufwand dürfte inverse zur durchschnittlichen Dateigröße sein.

 

[klampf]

btw.
Meine 840 evo zählt munter den Power Loss Counter hoch. Ich achte da im Moment drauf und hatte definitv keine Abstürze und habe den Rechner auch nicht hart abgeschaltet.

Es ist also entweder komplett quatsch oder es passiert beim normalen Runterfahren.

Ich habe als "Gegenmaßnahme" das eigentlich von mir aktivierte "Windows soll den Write Cache nicht flushen." für die evo deaktiviert.

Ich fahre den Rechner häufig per shutdown-commando inkl..Timer runter, das führt automatisch zu einem "force" und Programme die zu lange brauchen, werden abgeschossen.
Das sollte es aber auch nicht sein.
Ein Pagefile liegt auch drauf.

Das naheliegendste ist es auch hier die evo zu verdächtigen, das die dem Rechner sagt: "Bin fertig." und der schaltete ab, aber eigentlich war sie noch gar nicht fertig.

Grummel.

 

[Holt]

Eine Partition dürfte nicht reichen. 25% Testpartition, 75% Windows Partition und davon 50% frei. Wenn die SSD hinreichend groß ist, dürfte der "freie Speicherplatz" der Windows Partition gebencht werden und nicht die Testpartition mit ihren Schachbrettmuster.

Du verwechselst immer noch was Filesystemebene und Zugriffe sind und was intern abläuft. Es reicht eine kleine Partition, es muss nur genug Platz hinterher für AS-SSD sein. Was auf dem Rest der SSD ist, spielt da keine Rolle, denn es geht auch nicht darum wie der Controller die Daten intern ablegt. Selbst wenn Du eine ganze SSD so bearbeitest wäre sowieso zu erwarten, dass der Controller die Daten intern umkopiert um einen großen freien NAND Bereich zu schaffen. Nach dem kompletten Beschreiben hätte er ja gerade noch die Free Area ab Werk zur Verfügung und dann löscht man die Hälfte der Daten, womit er wenn es durch TRIM Befehle erfährt, wieder die Hälfte der Kapazität freimachen könnte, nur werden dummerweise halt die Hälfte der Pages (bzw. halbe Pages bei Pagasize >4k) immer noch mit gültigen Daten belegt sein, die andere Hälfte mit ungültige. Wenn er da nicht aufräumt, würde mich das sehr wundern.

Dass das Muster nicht absolut fehlerfrei ist, habe ich auch nicht erwartet. Beim Test heute konnte ich nur beobachten, dass die Sektoren scheinbar wahlfrei verwendet wurden und kein Muster zu erkennen war.

Es muss schon eine frisch formatierte Partition sein, bei "gebrauchten" gelten andere Regeln für das Recylcen von LBAs. War es eine frisch formatierte Partition?

Trimmen bzw, Zusammenfassen der noch gültigen Daten müsste man dieses ebenfalls beachten. Der Aufwand dürfte inverse zur durchschnittlichen Dateigröße sein.

Das timmen passierten ja automatisch und intern wird der Controller die Daten zusammenfassen, aber es ging hier ja um denn Einfluss der Fragmentierung und die passiert auf Filesystemebene. Sind dort die Lücken immer nur klein, 4k oder mal 8k, dann muss AS-SSDs Testfile in viele Fragmente aufgeteilt werden und statt eines sequentiellen Messung bekommt man praktisch eine Random 4k Messung.

Das dürfte hier übrigens nicht das Problem sein, das liegt hier wohl in der FW die bei der GC die Daten ungeschickt umsortiert.

Meine 840 evo zählt munter den Power Loss Counter hoch. Ich achte da im Moment drauf und hatte definitv keine Abstürze und habe den Rechner auch nicht hart abgeschaltet.

Bisher hat die 21 bei 199 Einschaltungen, das ist noch normal.

Es ist also entweder komplett quatsch oder es passiert beim normalen Runterfahren.

Das kann sein, wie genau die SSDs es erfahren und was sie genau zählen ist nicht immer dokumentiert. Micron gibt düe dei m500 an:

Unexpected power loss can be avoided by preceding a power off with an ATA STBI
(STANDBY IMMEDIATE) command, and allowing the SSD to properly complete this
command before removing power to the SSD.

Ich habe als "Gegenmaßnahme" das eigentlich von mir aktivierte "Windows soll den Write Cache nicht flushen." für die evo deaktiviert.

Wie genau? So sollte es aussehen, dass würde ich generell immer empfehlen und auf den RAPID Modus sollte man auch verzichten.

Ich fahre den Rechner häufig per shutdown-commando inkl..Timer runter, das führt automatisch zu einem "force" und Programme die zu lange brauchen, werden abgeschossen.
Das sollte es aber auch nicht sein.

Wenn ich mir die Erklärung von Micron ansehen, dass man der SSD Zeit geben soll das Kommando zu beenden, dann könnte es das schon sein.

 

[Hallo32]

Selbst wenn Du eine ganze SSD so bearbeitest wäre sowieso zu erwarten, dass der Controller die Daten intern umkopiert um einen großen freien NAND Bereich zu schaffen. Nach dem kompletten Beschreiben hätte er ja gerade noch die Free Area ab Werk zur Verfügung und dann löscht man die Hälfte der Daten, womit er wenn es durch TRIM Befehle erfährt, wieder die Hälfte der Kapazität freimachen könnte, nur werden dummerweise halt die Hälfte der Pages (bzw. halbe Pages bei Pagasize >4k) immer noch mit gültigen Daten belegt sein, die andere Hälfte mit ungültige. Wenn er da nicht aufräumt, würde mich das sehr wundern.

Die Frage ist nur, wie/wie viel räumt der Controller auf?
Das Zusammenfassen der noch gültigen Daten geht auf die WA. Wie ist die Gewichtung "Daten zusammenfassen" und WA in Firmware des Controllers?
Reichen 50% ungültige Daten pro Block für ein Zusammenfassen aller dieser Blöcke?
Werden aufgrund der WA evtl. nur x% der SSD Kapazität getrimmt? (SF hatte doch so etwas.) Was passiert, wenn man mehr als die x% in einen Durchgang auf die SSD schreibt? Wie werden die 50% der noch gültigen Daten mit den Schreibzugriffen kombiniert? (Read-Ahead Komplexität BF3) -> Wie wirkt sich diese Entscheidung auf die notwendige Zeit bis zum Abschluss des Vorgangs auf der Ebene des Flashs aus?

In diesen Fällen spielt es schon eine Rolle ob wir von einer Partition reden oder von einer ganzen SSD und dabei dann auch noch von welcher.