Wie lange 'halten' bei euch die SSD's?

Esst mehr Mist, Milliarden Fliegen können nicht irren! Oder was meinst Du? Nur weil da etwas oft genug im Netz steht und von google gefunden wird, wird es nicht wahrer.
Aber nur, weil du es gebetsmühlenartig wiederholst, wird es richtiger!? Nee, so funktioniert das nicht.

Warum die SSDs durch Fragmentierung langsamer werden, habe ich ausreichend dargelegt
Nein, du hast es _behauptet_. Das ist etwas anderes.
dann sollte auch Dir aufgehen, das ich recht habe
Ah, darum geht es! Ok. Du hast recht.
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Ein paar unabhängige Quellen würden deinem Fachwissen trotzdem gut tun.
Für alle die es nicht kennen, da ist auch oben rechts eine Anschauliche Animation:
Fragmentierung (Dateisystem)
Ich hätte gerne links zu einem Paper oder irgendwas was Dateisystemfragmentierung in Verbindung mit SSD Performance und Defrag bringt.
In Verbindung mit der Performance muss man das schon selbst bringe, es wird nicht immer alles im Leben mundgerecht vorgekaut geliefert. Überlege aber nur mal, was bei der extremsten Fragmentierung passiert. Da wird eine mehrere MB große Datein nämlich im schlimmsten Fall in zahlreiche Fragmente zerligt, die nur jeweils einen Cluster, also normalerweise bei NTFS 4k, groß sind und nicht zusammenhängen.

Jetzt schauen wir mal in den ATA8 Befehlssatz, wie denn so gelesen wird. Da finden wir z.B. auf S. 163 den Syntax des READ STREAM DMA EXT - 2Ah Befehls, der im zweiten Word die Länge enthält, danach dann den LBA ab dem zu lesen ist:
01h Count The number of logical sectors to be transferred. A value of 0000h indicates that
65536 logical sectors are to be transferred.
Mit einem einzige Lesebefehl können also maximal 655356 LBAs zu normalerweise je 512 Byte gelesen werden, was 32MiB ausmacht. Mehr als die Länge eines Fragments wird aber natürlich nie gelesen, da die Daten der nachfolgenden LBAs ja nicht zu der gewünschten Datei gehören, kann man auch sicher irgendwo in der API Dokumentation von Windows nachlesen, wenn man es nicht so glaubt.

In unserem Beispiel der extrem fragmentierten Daten die nur auf 4k Langen Fragmentien besteht, können also immer nur 4k lange Lesezugriffe erfolgen, statt einiger Zugriffe mit bis zu 32MiB pro Lesebefehl also Lesezugriffe. Keine Ahnung ob die Treiber von Windows diese 32MiB ausnutzen oder nicht, aber das spielt auch keine Rolle, denn auf jeden Fall lesen sie ja mehr als 4k mit einem Befehl, wenn das Fragment bzw. die Daten entsprechend lang sind.

Glaubt wieder einer nicht? Gut dann schauen wir uns noch mal aus den Screenshot mit AS-SSD von pinki auf der letzten Seite:

as-ssd-benchkingstonkilkka.png


Da wurde beim sequentiellen Lesen 461,32MB/s erreicht, bei 4k lange Lesezugriffen aber nur 20,56MB/s. Selbst wenn nun Windows die ganze Fragmente der Datei parallel adressiert (ob es so ist, weiß ich nicht), dann würden wir eben maximal auf die 116,93MB/s kommen, die bei 4k_64 ermittelt wurden, immer noch weit unter den 461,32MB/s, oder?

Aber nur, weil du es gebetsmühlenartig wiederholst, wird es richtiger!? Nee, so funktioniert das nicht.
So, jetzt schreibe mir bitte, wie es Deiner Meinung nach funktionieren soll, eine extrem fragmentierte Daten wie in meinem Beispiel mit pinkis SSD mit den gleichen 461MB/s zu lesen, die beim seq. Zugriff möglich sind!
 
es haben sich nach dem Defrag alle werte verschlechtert, die einen mehr die anderen weniger stark.
Für mich heist das, bringt nix, jedenfalls nicht das gewünschte, im Gegenteil, ist eher entgegen dem was erreicht werden soll

PS: Hab das jetzt grad noch mit meiner 256 GB Corsair Performance Pro getestet, das Ergebnis ist recht ähnlich wenn auch nicht ganz so ausgeprägt
 
Zuletzt bearbeitet:
Mit auslogics nur analysiert, sieht ansich gut aus, hatte aber schon mal alle drei defragmentiert, aber die Verteilung des freien Platzes bei der m4 256 sieht doch eher ungünstig aus, oder?

Anhang anzeigen 270962
 
es haben sich nach dem Defrag alle werte verschlechtert, die einen mehr die anderen weniger stark.
Für mich heist das, bringt nix, jedenfalls nicht das gewünschte, im Gegenteil, ist eher entgegen dem was erreicht werden soll

PS: Hab das jetzt grad noch mit meiner 256 GB Corsair Performance Pro getestet, das Ergebnis ist recht ähnlich wenn auch nicht ganz so ausgeprägt

AS SSD kann den Einfluss einer Defragmentierung bei einer SSD kaum bis gar nicht messen. Wenn du das nicht verstehst, ist die ganze Diskussion müßig. Die Defragmentierung beschleunigt insbesodnere zugriffe auf bereits vorhanden Daten. AS SSD misst aber was anderes. Das ist das Problem bei neuen Technologien, man kann keine Performanceindikatoren messen udn auswerten, bevor man nicht GENAU weiß was man messen muss.

Übrigens auch der Grund warum Crucial sagt, dass SSDs nicht defragmentiert werden müssen. Die Interessieren sich nur für das Laufwerk, nicht für die Filesystemperformance. Und die zählt.

Mit auslogics nur analysiert, sieht ansich gut aus, hatte aber schon mal alle drei defragmentiert, aber die Verteilung des freien Platzes bei der m4 256 sieht doch eher ungünstig aus, oder?

Anhang anzeigen 270962

Wieso ist das ungünstig? Windows schreibt dorthin, wo es Platz hat. Die Verteilung ind en Speicherzellen ist eh komplett anders.
 
Mit auslogics nur analysiert, sieht ansich gut aus, hatte aber schon mal alle drei defragmentiert, aber die Verteilung des freien Platzes bei der m4 256 sieht doch eher ungünstig aus, oder?
Diese normale Defragmentierprogramme sind da etwas grob in der Auflösung und zeigen jede Datei als fragmentiert ab, selbst wenn es zwei Fragmente zu je 200MB sind, die nicht einmal bei HDDs die Performance wirklich beeinflussen. Schau Dir mal Mydefrag an, dass löst bei der Analyse viel genauer auf und man kann es sehr umfangreich konfigurieren. Das muss man auch, denn es legt sonst Lücken an, die ja nicht gewollt sind.

AS SSD kann den Einfluss einer Defragmentierung bei einer SSD kaum bis gar nicht messen.
Das stimmt, allerdings mit einer Ausnahme: Wenn der ganze freie Adressbereich nur noch aus kurzen, nicht zusammenhängenden Fragmente besteht und die Testfiles von AS-SSD daher auch fragmenrtieren, dann sieht man dort den Effekt auch. Aber hat man z.B. gerade eine großere Datei gelöscht und damit genug Platz um AS-SSD dann auch auszuführen, was sicher oft nötig ist denn die Fragmentierung steigt ja eben umso mehr, je voller die Partition ist, dann kann AS-SSD u.U. doch wieder eine (fast) zusammenhängende Testdatei schrieben und zeigt wieder normale Werte an. Im übrigen sind pinkis Abweichungen sind ja noch im Rahmen der Messgenauigkeit, zumindest bei dem Beispiel welches er gepostet hat.

Richtig ist aber natürlich, dass man die Fragmentierung eben bei den bestehenden, stark fragmentierten Dateien spürt und deren Lesegeschwindigkeit kann eben keine Benchmark ermitteln und Windows zeigt sie einem auch nicht so ohne weiteres an. Genau wie JojoTheMaster schreibt:
Die Defragmentierung beschleunigt insbesodnere zugriffe auf bereits vorhanden Daten.
Und eben das Schreiben größerer Dateien, wenn diese dadurch eben in zusammenhängenden LBAs landen statt massiv gestückelt zu werden, weil überall nur wenig Platz für die einzelnen Fragmente ist.
Das ist das Problem bei neuen Technologien, man kann keine Performanceindikatoren messen udn auswerten, bevor man nicht GENAU weiß was man messen muss.
Genau so ist es und es ist nur wenigen Leuten klar, die meisten werfen einen Benchmark an, schauen auf das Ergebnis und nehmen das für bare Münze.

Übrigens auch der Grund warum Crucial sagt, dass SSDs nicht defragmentiert werden müssen. Die Interessieren sich nur für das Laufwerk, nicht für die Filesystemperformance. Und die zählt.
Wenn ich mir die ganze OS Optimierungen diverser SSD Toolboxen so ansehe, dann frage ich mich manchmal wirklich, wie viel Know-How denn so bei den jeweils Verantwortlichen in den Firmen so vorhanden ist. Die setzen den Mist um, den die Anleitungen im Netz verbreiten und kenne die Hintergründe offenbar nicht. Das SSDs nicht so unter Fragmentierung leiden und das Defragmentieren auch nicht bewirkt, dass die Daten im physikalsichen Speicher besser angeordnet werden (eher schlechter, weil beim Defragmentieren meist mit vielen kleinen Zugriffen verschoben wird, was schlecht für das Schattenfilesystem ist), ist natürlich richtig. Den Aspekt der Zugriffslängen und was der für die Performance bedeutet, hat man dabei eben vergessen, so viele hier ihn auch lange nicht gesehen haben bzw. nicht einsehen wollten. Microsoft hat offenbar daran gedacht und die manuelle Defragmentierung auch bei SSDs freigegeben, obwohl sich bei Win7 SSDs nicht einmal in den Zeitplaner des Defragmentierdienstes eintragen lassen.
 
das Problem ist doch unter anderem das Daten aus blöcken verschoben werden, welche anschliesend keinen trim befehl erhalten.

Auch bei real anwendungen konnte ich bisher keine verbesserung der Leistung messen, nur mal so neben bei
 
Hier mal meine C300. Ist jetzt gute 3 Jahre alt. Hoffe sie wird noch etwas durchalten ;)

Unbenannt-3.jpg
 
Das sollte sie wohl, es sind ja gerade erst 4% der garantierten P/E Zyklen verbraucht. 4% in 3 Jahren, da kannst Du kaum hoffen so lange zu leben, bis die garantierten 5000 P/E Zyklen verbraucht sind.
 
Ich habe hier seit Januar 2011 eine OCZ Vertex 2 60GB als OS Platte im Einsatz. Sie wurde bisher 2689 mal eingeschaltet und hat 10488 Betriebsstunden.

....und läuft, und läuft, und läuft.... :d

Dennoch wird sie nun ersetzt von einer 840 Evo. :)
 
Hallo zusammen,

ich habe auch mal ne Frage zwecks meiner Crucial M4 64GB.
Die SSD hat verrichtet schon lange gute Dienste als Systemplatte an meinem DX58S02 (Marvell mv91xx Controller Sata3).
Nach einer Bluescreen Orgie hat sich anscheinend alles wieder normalisiert :confused:
Kann aber leider mit den Werten hier wenig anfangen.
20140302_224415-7.jpg

Ereignis 11, Disk: Der Treiber hat einen Controllerfehler auf \Device\Harddisk0\DR0 gefunden
Bin gerade am überlegen diese zu ersetzen. :-[

Grüße JSF
 
Zuletzt bearbeitet:
Hänge die SSD mal an einen der SATA 3Gb/s Ports der ICH10(R) und prüfe Dein RAM damit RAM Fehler auszuschließen sind. Dazu stellt man alles so ein, wie es auch nachher läuft, also keine Tweaks unter Windows! Dann die iso von Memtest86 von CD oder USB-Stick booten, denn man kann nicht unter Windows sinnvoll das RAM testen. Es sollten min. 6 PASS abgewartet werden und es darf dabei kein einziger Fehler auftreten, also am Besten über Nacht laufen lassen. RAM-Fehler können die unmöglichsten Probleme erzeugen.

Ggf. hilft es auch die FW auf die 000F oder 0309 downzugraten, das sind die stabilsten FW-Versionen für die m4.
 
Hab ich gerade richtig gelesen, ihr Defragmentiert eure SSD :confused: Ich dachte immer das wäre bei SSDs total unnötig und schädigt die SSD nur, ich frag mich was das bringen soll? Es ist doch nicht wie bei Herkömmlichen HDDs wo der Kopf die Platter abtasten muss.
 
nobbi69, lies doch noch mal den Beitrag #152 etwas weiter oben, dann sollte klar werden, welchen Effekt die Fragmentierung des Dateisystems auf die Zugriffslängen hat und wieso sich das auch bei SSDs auf die Performance auswirkt.
 
Es wirkt sich bei SSDs nicht auf die Performance aus.
Deine Überlegungen bzgl. LBAs pro Lesekommando sind ohne Relevanz, auch bei Festplatten.
Der ATA oder SATA-Hostadapter weiß von einer Fragmentierung der Platte nichts.
Der schickt also nicht bei einer defragmentierten Platte 1 LBA-Befehl und bei einer fragmentierten Platte z.B. 20 LBA-Befehle.
Der schickt immer nur 1 LBA-Befehl.
Bei HDDs ist eine Defragmentierung aus anderen Gründen sinnvoll:
Latenz durch die Mechanik.
Die gibts bei SSDs nicht.
Die Zugriffszeit ist bei allen Speicherzellen exakt identisch.

Und noch etwas, was SSDs angeht:
Schon einmal etwas von Wear Leveling gehört?
Das haben seit längerem alle SSDs.
Der SSD-Kontroller schreibt die Daten in die am wenigsten benutzten Speicherzellen.
Und wenn diese durch Daten belegt sind, werden die dort stehenden Daten in andere Speicherzellen umgelagert.
Und das passiert permanent.
Sinn der Sache ist es, das alle Speicherzellen der SSD möglichst gleichmäßig abgenutzt werden.
 
passat3233, hast Du für den ganzen Mist den Du schreibst mal versucht einen Quelle als Beleg zu finden? Hast Du Dir den SATA Befehlssatz mal angesehen? Schau Dir mal "READ SECTOR(S) - 20h, PIO" an:

Um zu zeigen, dass die Treiberprogrammierer nicht so ganz bescheuert sind wie passat3233 es ihnen unterstellt, schauen wir und man den S.M.A.R.T. Werte einer SSD mit dem Indilinx Barefoot an, denn der zeigt in seinen S.M.A.R.T. Werte sowohl die Anzahl der Befehle als auch die der dabei gelesenen Sektoren an. Nehmen wir als Beispiel man diese hier, die hat 4668772995 Sektoren gelesen und dafür wurden 76585762 Lesebefehle an sie geschickt. Das waren also im Schnitt 60,96 Sektoren (LBAs zu je 512 Byte) pro Lesebefehl.

Geht man nun von diesem Befehl aus, so können maximal 128kiB pro Befehl gelesen werden, aber wenn eine Datei fragmentiert ist und das Fragment kleiner ist, dann müssen eben weniger LBAs mit einem Befehl gelesen werden und je kürzer der Zugriff ist, umso geringer wird die Übertragungsrate, wie man an jedem ATTO Screenshot einer SSD leicht erkennen kann. Wäre die Datei nur in Fragmente aufgeteilt die immer genau 256LBAs lang sind, dann hätte die Fragmentierung aber in der Tat wohl keinen Einfluss auf die Performance.
 
Zuletzt bearbeitet:
Es wirkt sich bei SSDs nicht auf die Performance aus.
Deine Überlegungen bzgl. LBAs pro Lesekommando sind ohne Relevanz, auch bei Festplatten.
Der ATA oder SATA-Hostadapter weiß von einer Fragmentierung der Platte nichts.
Der schickt also nicht bei einer defragmentierten Platte 1 LBA-Befehl und bei einer fragmentierten Platte z.B. 20 LBA-Befehle.
Der schickt immer nur 1 LBA-Befehl.

Holt hat recht.
Er sprach von der Fragmentierung des Filesystems (z.B. NTFS). Davon weiß der SATA-Hostadapter zwar wirklich nichts, aber das Filesystem weiß es, und schickt deshalb ggfls. mehrere Lesekommandos. Bei SSDs wirkt sich das nur nicht so dramatisch aus.
Holt hat das weiter oben ja sehr schön beschrieben. Vielleicht einfach nochmal durchlesen.
 
Crucial M4 256GB nach etwas mehr als 14Monaten hat sie das zeitliche gesegnet.
Laut Google zerstört sich das Teil wohl nach ±5000 Stunden von selbst :fresse2: und scheint auch so einige Bugs in der Firmware zu haben, die das Teil bei Lust und Laune abschalten können.
 
Nein, die zerstört sich nicht nach 5184 Stunden von selbst, die geht dann nur immer nach einer bestimmten Zeit einfach aus. Das lässt sich aber mit einem einfach FW Update beheben und wenn man das rechtzeitig macht, denn passiert es gar nicht erst. Macht man es später ist es auch kein Problem, dann tritt der Fehler nicht mehr auf und schlimmstenfalls ist das Filesystem beschädigt, weil eben die SSD plötzlich nicht mehr reagiert und die Daten aus dem Schreibcache nicht zurückgeschrieben werden können.

Wenn Du das also bisher nicht getan hast und die m4 noch die FW 0001, 0002 oder 0009 hat, dann mache die SSD stromlos, lade die ISO der Crucial m4 FW 0309 runter, entpacke das zip und ziehe die ISO nach madnex Anleitung mit Unetbootin auf einen Stick. Dann boote den Rechner und führe so flott wie möglich das FW Update aus, nicht das genau während des Updates der Bug zuschlägt.

- - - Updated - - -

Der Bug ist übrigens seid mehr als 2 Jahren gefixt und es wurde eigentlich sehr umfangreich drüber berichtet.
 
Die wird aber schlicht nicht mehr vom System erkannt :) den Ganzen Vodoo mit 3*20Min ohne Sata Kabel betreiben etc. habe ich auch schon durch.
FW Update kann man leider auch nur einspielen, wenn sie erkannt wird (kp was für eine Version drauf ist/war, denke die mit der sie ausgeliefert wurde). (AHCI, IDE, anderes Kabel, anderer PC etc. alles durch)

Geht morgen an Amazon zurück, scheint bei Amazon auch bekannt zu sein und nicht die erste die sie zurück bekommen.
(so hat es sich zumindest angehört bei der Beschreibung des Fehlers)
 
Zuletzt bearbeitet:
Die Version der FW mit der die SSD ausgeliefert wurde, steht auf dem Etikett drauf.
 
So, mal meine 840er nach einigen Stunden Betriebszeit.
Wie schon bei der Vorgängering, einer 830 mit 128GB, keinerlei Optimierungen.
Einzig der Hibernate ist deaktiviert.

Unbenannt-1.jpg
 
Die hat ja noch nicht einmal 2 P/E Zyklen runter.
 
Ich sehe bei meiner Samsung SSD 470 leider nur den Status "GUT" ohne Prozentzusatz. Das kann also viel heissen. Ob nun 100, 95 oder nur noch 25%, das sehe ich leider nicht.

Was sagen mir denn die anderen Daten, gibt es hier jemanden der die Smart Werte interpretieren kann ob hier noch alles im grünen Bereich ist ?

Unbenannt.JPG
 
Zuletzt bearbeitet:
Ja, das ist noch eine die eigentlich als OEM SSD geboren wurde und bei den OEM SSD (bzw. mit OEM FW) gibt es meist nur wenige Informationen, da will man offenbar übermäßig Reklamationen aufgrund missverstandener Werte verhindern. Ich würde aber mal sagen, dass die 45 im Rohwert von B1 die verbrauchten P/E Zyklen sein dürften und der Aktuelle Wert die Prozentangabe bis zum Erreichen der garantierten P/E Zyklen. Dafür wäre dann zwar B2 sehr hoch, aber die könnte die ab Werk defekten Blöcke enthalten, die zeigt ja die Crucial m4 auch separat an und da sind auch mal Wert die 2 bis 3 Blöcke pro GB Kapazität entsprechen, durchaus normal. Ich würde also mal den Rohwert von B2 im Auge behalten, denn der massiv steigt, wäre das nicht so toll.
 
Wie ich auch im Thread von Alex2108 über die S.M.A.R.T. Werte der 470er geschrieben habe, gab es im im Test bei xtremesystems.org eine 470 64GB die mit 276 gestartet ist:

272945d1394059414-interpretation-smart-werte-der-samsung-ssd-470-xs_org_470_smart_testanfang.png


Bei 9123 gibt es einen Screenshot der S.M.A.R.T: Werte und B2 ist immer noch unverändert gewesen. Erst nach mehr als 21827 P/E Zyklen hat sich da der Rohwert von B2 auf 282 verändert.

Samsung zählt bei der 470er also offensichtlich die ab Werk aussortiert Reservesektoren dazu, so wie auch Crucial bei der m500 mit der FW MU02 gemacht hat. Wer den Thread bei xtremesystems.org verfolgt hat, der weiß auch das es schon mal vorkommen kann, dass eine SSD auch recht frühzeitig mal eine oder ein paar Wiederzuweisungen haben kann, der Wert dann aber meist sehr lange stabil bleibt. Anders als bei HDDs ist das also bei SSD nicht so kritisch zu sehen, die wurden wohl beim Test ab Werk nicht erkannt und daher nicht gleich aussortiert. Sorgen sollte man sich erst machen, wenn der Wert kontinuierlich steigt, denn während es bei HDDs ja oft Folgeschäden aufgrund der gleichen Ursache sind, die dann das baldige Ende der Platte bedeuten können, gibt es so etwas bei SSD nicht, da ist kein Gefahr das Schmutz (Abrieb von einem Headcrash) im Gehäuse sein könnte, der dann unter die Schreib-Leseköpfe kommen und die ganze Platte zerkratzen kann.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh