Hallo32 schrieb:
Die Theorie dahinter ist bekannt. Eine Verifikation
Welche meinst Du?
Mit Verifikation wäre es ja auch keine Theorie mehr.
Holt schrieb:
Ist verstanden, ich habe auch eine Idee wie so etwas aussieht und wie ich es selbst designen würde.
Ich weiß natürlich nicht wie es tatsächlich implementiert ist.
Ich würde es so designen, dass es den Zugriff auf zusammenhängende LBAs optimiert.
Das wäre dann auch die Optimierungsstrategie bei einer Garbage Collection.
Alles andere halte ich für verfehlt, denn die SSD weiß einfach nicht genug vom darüber liegenden System.
Ein typisches normales Filesystem wie NTFS geht mit Annahme an den Start, dass die darunter liegende Schicht (also die Festplatte) für den Zugriff auf zusammenhängende LBAs optimert ist.
eine andere Verteilung als wenn man z.B. Random über den Adressbereich mit 4k schreibt. Dann ist da noch der Aspekt der Zugriffslängen, die können bei ATA Befehlen maximal 32MiB sein, sind aber eben nie länger als ein Fragment der Datei und bei langen Zugriffen erreicht man höhere Transferraten als bei kurzen.
Weißt Du welche Transfergrößen wirklich genutzt werden?
Ich kann das nur auf der API-Ebene z.B. mit ProcMon sehen. Der Explorer z.B. schreibt beim kopieren immer in 64 KB-Blöcken. Lesen tut er mit 1 MB. (Windows 7).
CrystalDiskMark liest und schreibt im ersten Test (Seq) in 1 MB Schritten.
Kann schon sein, dass die später nochmal zusammengefasst werden, aber dann kann man schon nicht mehr wissen, ob die von einem Programm kommen, also zu einer Datei gehören.
Mit NCQ und Multi-Tasking. Auch auf Treiber/Puffer/Cache-Ebene würde der wohl sowieso zu maximal großen Zugriffen zusammenfassen und das sind dann auch wieder zusammenhängende LBAs.
Nochmal, das sind sie nicht, das scheint nur so, wenn man diese Low-Level Benchmarks nimmt. Wie schon vorgeschlagen: Schreibe mit
Wie schon erwähnt, habe ich mir den Hinweise ja zu Herzen genommen, bevor ich diesen Thread eröffnet habe.
Damit habe ich herausbekommen, dass es alte, große Dateien gibt, die langsam gelesen werden.
Gerade Dateien die dauernd im Zugriff sind und verändert werden wie z.B. der Lightroom-Catalog sind schnell.
Vielleicht hilft ein Bild vom Tool für das Verständnis.
Ich kann damit also jede beliebige Datei benchmarken und das eben auch auf der schon langsamen SSD.
Mit dem h2testw ein neues File anzulegen wäre da nicht hilfreicher. Wäre ja auch zu Beginn ein neue File
Werten Daten nun einzeln geschrieben, also ohne jeden Zusammenhang und landen nur zufällig auf benachbarten Blöcken (LBAs, Cluster des Filesystems, i.d.R. also 8 aufeinanderfolgende LBAs), so achtet der Controller eben nicht darauf,
Hast Du irgendeinen Hinweis, dass Deine "Der Controller versucht zu raten, was eine Datei ist"-Theorie stimmt?
Meinst Du der merkt sich dass dann auch bis auf weiteres für alle Files des Hostsystems?
Das wäre schon recht irre.
Wenn dann nur ein Teil der geratenen Datei neu geschrieben wird. Ist das dann für den Controller eine neue Datei oder ist noch die gleiche?
Ich will gar nicht ausschließen, dass jemand versucht so eine SSD zu bauen. Dann würde ich auch total verstehen, warum die nach und nach abkotzt.
Die wären im Einzelfall vielleicht besser und dafür in anderen schlechter. Im Mittel wahrscheinlich nicht besser.
da MyDefrag beidem Monthly Plan ja praktisch alle Dateien der Reihe nach neu schreibt, hast Du den im Moment nicht, er wird nach einiger Zeit aber wieder auftreten.
Deshalb habe ich das mit MyDefrag ja gemacht.
Wenn Dateien, die jetzt schnell sind wieder langsam werden, weiß ich dass die SSD intern für mich falsch optimiert und das ist höflich formuliert.
Total bunt verteilt ist nicht WortCase sondern Best-Case!
Vielleicht hätte ich hier exakter sein sollen. Sagen wir mal total bunt = maximale Distribution der Hostdaten über LBAs und SSD in minimalster Dateneinheit. WorstCase halt.
Welche sind denn langsam?
Vor allem Readonly files, die ich gleich am Anfang draufkopiert habe. Archive, Datenbankfiles einer Datenbank, die nur gelesen würde, wenn ich sie überhaupt nutzen würde.
Dateien im 2 GB-Bereich von Spielen, die ich nicht mehr spiele
Wenn die jetzt wieder langsam werden, kann ich nur folgende Theorien annehmen:
1. Die Evo optmiert für mich falsch und macht den Zugriff auf alte Daten langsam, weil neue Daten bevorzugt werden und die SSD nicht auf zusammenhängende LBAs optimiert.
2a. Die Evo hat Schwierigkeiten mit der Datenhaltbarkeit (Data Retention) und Daten, die schon eine Weile nicht mehr gelesen wurden, habe so viele ECC-Fehler, dass die gleich beim Lesen in neue Bereiche verschoben werden.
2b. Hat zwar viele ECC-Fehler, die aber ausreichend korrigierbar sind, weshalb das Lesen zwar lahm ist, die Daten aber noch nicht umkopiert werden müssen, denn das würde ja Zyklen kosten.
Gegen 2a spricht, dass die Dateien auch beim 2ten oder 3ten lesen nicht schneller wurden. Auch nach einiger Wartezeit (1h) nicht.
)
). Aber der Effekt ist gering und daher kaum geeignet den Verlust an Leseleistung zu erklären.
