News WD Blue 3D NAND: Vereinzelt Leistungsverlust beim Lesen alter Dateien

[gymfan]

Bin ich alleine, oder finden andere das Problem auch 'erwartbar'?

Den refresh hat eine SSD, die im täglich laufenden PC verbaut ist, selbstständig zu tun. Andrer SSDs können das schließlihc auch, auf meiner Crucial M500 960GB von 12/2013 sind die Dateien teils 3101 Tage alt und sie sind fast alle mit 300 MB/s und mehr durch das Tool lesbar.

Ich würde niemals eine SSD als klassisches Datengrab verwenden.

Ich würde mir nie mehr eine HDD in den PC einbauen. Und selbst im NAS mit 10 GBit/s Anbindung müsste man schon eine SSD als Cache nutzen, um auch nur ansatzweise auf die Geschwindigkeit einer lokalen SATA SSD zu kommen.

Was soll außerdem ein Datengrab sein? Installierst Du alle paar Wochen Windows/Linux inkl. aller Programme neu, weil es sonst genügend Dateien gibt, die einmal bei der Installation geschrieben und danach nur noch gelesen werden?

Könnten diejenigen, die hier fleißig Screenshots posten, bitte auch dazu schreiben, wann sie ihr System aufgesetzt haben bzw. wann die Daten auf die SSD geschrieben wurden?

Schau Dir einfach die Screenshots an. Ganz links steht das Alter der Dateien (vermutlich das Erstellungsdatum gemäß Dateisystem, es muss also weder für die gesamte Datei stimmen noch muss es das Datum sein, an dem die Datei real auf die SSD geschrieben wurde), danaben die Leserate und die Dateigröße.

Irgendwas stimmt mit dem auslesen beim Alter der Dateien nicht. Das mit den 8-12 Jahre alten Dateien glaub ich weder der MX300 (Mai 17 gekauft) noch der MP510 (Nov 19 gekauft)...

Es scheint das Erstellungsdatum der Dateien gemäß Dateisystem zu sein. Das lässt sich bekanntlich, wie alle anderen Zeitstempel, beliebig ändern und es wird von einem Kopierprogramm u.U. aus der Quelle übernommen.

Bei meiner 2TB Datei gilt:
Änderungsdatum: 01.01.2020
Erstellungsdatum: 22.06.2020
Lieferdatum SSD: 21.06.2020
Reale letzte Änderung der Datei (Veracrypt-Container): 09.06.2022
Testdatum: 10.06.2020
Angabe des Tools: Alter der Datei 717 Tage

 

[Drahminedum]

@MichaG Ich zweifle die Daten des Tools an - zumindest was das Datum angeht.

Die SSD in dem geprüften PC ist ein gutes Jahr alt und er zeigt mir Dateien, die zB 15 Jahre alt sind. Ja, die Datei hat einen Datumsstempel von vor 15 Jahren, sie wurde aber vor maximal einem Jahr auf den PC geschrieben. So hat das Datum in dem Tool überhaupt keine Aussagekraft.

 

[Stormfirebird]

So hat das Datum in dem Tool überhaupt keine Aussagekraft.

Daran ist jetzt aber nicht wirklich das Tool schuld. Ausreiser gibt es hier ja scheinbar öfter, aber das ist ja auch nicht unbedingt Sinn und Zweck des Tools. Ohne Vergleich zu einer anderen Platte oder einen früheren Zustand ist das ja sowieso mit Vorsicht zu genießen.

 

[feidl74]

Da werden wohl schon ein paar Dateien im RAM gewesen sein.

Neustart wurde gemacht und auch der VC deaktiviert. hatte mich nur in der Spalte geiirt😉. nur die average Leserate ist 40mb/sec zu hoch. meine 840 Evi schafft keine 598mb/sec., wenn man Datenmenge durch Lesedauer Teilt, bleiben eben nur knapp560mb/sec. weiß aber nicht, wie das Programm das ausrechnet.

 

[Corpus Delicti]

Für Betroffene:

Statt "Backup -> formatieren -> Backup" zurückspielen" einfach DiskFresh nutzen, hat damals bei der 840 und 840 EVO hier geholfen, bis Samsung die Lösung in einem FirmWare-Update hatte.

Leider scheint WD das Problem zu leugnen (WD Reds mit SMR machen auch keine Probleme in RAIDs, gelle?) und somit sollte man mit so einem Update auch nicht rechnen.

 

[Bigeagle]

Da kann man WD aber schon vorwerfen dass das Problem weder neu noch unbekannt war und sie das auf dem Schirm hätten haben müssen. Schließlich ist das deren Job.
Die vorstellung dass irgendwann die Daten nicht nur langsam, sondern gänzlich unlesbar sind ist eher uncool. Darauf läuft es aber hinaus.
Aber hey, kann einem mit HDDs ja auch passieren, also was solls.

Mich stört ja dass der Graph im SSDReadSpeedTester nur bis 100 Wochen geht. Das sind doch keine alten Dateien, die sind noch jung und frisch! ^^

Spaßeshalber habe ich den ersten Test unter völliger Missachtung der Hinweise zur Benutzung gemacht. Mit voll ausgelasteter CPU, GPU, parallel surfen und nach über 35 Tagen seit dem letzten Neustart.

Folgetest mit pausiertem BOINC zeigt dass die beschäftigte CPU durchaus einen Unterschied macht, wenn auch keinen allzu großen.

Eine 840 pro, leider ohne uraltes OS darauf. Aber alt genug scheinen einige Dateien ja zu sein. Interessant ist die erheblich höhere mittlere Geschwindigkeit schon, dafür dass die Evo da keine schwäche haben sollte. Aber vielleicht kommt das auch nur von mehr größeren Dateien.

Meine primären HDDs lasse ich auch mal durchlaufen um einen Vergleich zu haben. Die 840 pro verdient denke ich auch einen zweiten Durchlauf um zu schauen ob die langsamen Dateien ausrutscher sind, oder gleichbleibend.

Allgemein sollte der Test für sinnvollere Ergebnisse die ungewöhnlich langsamen Dateien erneut lesen um Störungen von Außen unwahrscheinlicher zu machen. Aber das scheint ja mehr ein schnell gebautes Tool für einen groben Überblick zu sein, kein wissenschaftliches Instrument.

Was machen die, die technisch nicht so versiert sind oder die eventuelle Systemplatte nicht neu aufsetzen wollen?

Also ich würde ja etwas richtung 'dd if=/dev/sda of=/my/back/up' und zurück sagen fg
Unter Windows selbst kann man je nachdem was betroffen ist die Dateien ja nicht einfach neu schreiben. Ansonsten könnte sich jemand der User erbarmen und ein Script schreiben dass aus den tsv Files die langsamen ausliest, diese kopiert und zurückschreibt.

@MichaG Ich zweifle die Daten des Tools an - zumindest was das Datum angeht.

Die SSD in dem geprüften PC ist ein gutes Jahr alt und er zeigt mir Dateien, die zB 15 Jahre alt sind. Ja, die Datei hat einen Datumsstempel von vor 15 Jahren, sie wurde aber vor maximal einem Jahr auf den PC geschrieben. So hat das Datum in dem Tool überhaupt keine Aussagekraft.

Woher sollte das Tool denn wissen wann die Datei auf das Speichermedium geschrieben wurde? Kristallkugeln in Software sind gerade nicht lieferbar, somit sind die Erstell- und Änderungszeiten im Dateisystem alles was bleibt. Da könnten noch ganz andere Werte drinstehen wenn jemand mit der Systemzeit gespielt hat.
Die Aussagekraft die verbleibt ist dass auf dem typischen PC eine Datei von 1980 wahrscheinlich zu den ältesten Dateien auf dem Speichermedium gehören und Dateien von vor 5 Minuten möglicherweise erst kürzlich geschrieben wurde. Womöglich hat auch nur jemand den Zeitstempel aktualisiert, das lässt sich womöglich nur genau herausfinden indem man das Speichermedium auseinandernimmt und sehr genau untersucht. Für den Zweck einer allgemeinen Orientierung ob langsam lesbare Dateien mit zunehmendem Alter korrelieren reicht das Tool aber.

 

[Kontrapaganda]

Der Zeitspempel des Dateisystems sagt nichts aus, gerade bei "Systemdateien", die du nicht selber erstellt hast.
ich habe gerade interessehalber mal bei mir unter Linux (openSUSE Tumbleweed installiert Ende Mai) in »/usr/bin/« nachgeschaut. Dort gibt es z.B. die Datei "hdisk.pl", die den Userspace-Teil eines Treibers für das alte Apple-HFS-(ohne Plus!)-Dateisystem stellt. Änderungsdatum ist der 13. Mai 1998 00:36 Uhr. Damit ist die Datei älter als ich.
Das verrät uns zunächst einmal, dass der HFS-Treiber schon ein paar Jahrezhnte nicht maintained wurde.
Erstellungsdatum. das ist aber normal: Das Treiberpaket für meinen Drucker hatte unter Ubuntu 20.04 ein Änderungsdatum in 2008. Das "Universe" lässt grüßen.
Erstellungsdatum hingegen ist Doonerstag der 26 Mai 2022. Das war kurz nach der Installation, als ich meine package list durchlaufen lies und dabei wenig bedachtsam einen HFS-Treiber installierte, den ich vermutlich gar nicht brauche.

Umgekehrt habe ich gerade eine XOPP-Datei gefunden, die ich heute morgen bearbeitet hatte und die jetzt auch als Erstellungsdatum den 11 Juni hat, obwohl ich weiß, dass ich die Datei schon letzten Samstag erstellt habe. Der Grund dafür ist ebenfalls einfach: Das benutze Programm (Xournal++) schreibt bei jedem Speichervorgang die Datei komplett neu mit komplett neuem Datumsstempel und beachtet nicht, dass die Datei vorher schon existiert hatte, obwohl vor dem Überschreiben nachgefragt wird.
Kile (Ein Qt-basierter TeX-Editor) hingegen übernimmt das Erstellungsdatum.

 

[TP555]

@MichaG

Ich denke , da viele ihre Windows SSD mit dem Tool Testen , das da durch solche Ergebnisse rauskommen , man bedenke Win10 kam 2015 raus , da sind Garantiert noch alt Daten enthalten , wird bei 11 nicht großartig anders sein.

Beispiel Windows 8.1 , das kann man installieren wann man will 🙂

Das wäre schon Mal ein guter Test.

Oder sich mit Attribute Changer selber die Daten entsprechend abändern , habe das gerade Mal ausprobiert , Funktioniert einwandfrei.

Mfg.

 

[failXontour]

ComputerBase hat Western Digital auf die Berichte angesprochen und schnell eine Antwort erhalten. Demnach sei dem Hersteller kein technisches Problem bekannt und nach Prüfung der besagten Threads aus dem ComputerBase-Forum schlägt der Hersteller eine Neuformatierung der Laufwerke vor, die die Leistung offensichtlich wiederherstellt. Im ersten Schritt solle allerdings geprüft werden, ob die Firmware auf aktuellem Stand ist, was bei den Betroffenen der Fall gewesen ist. Anschließend sollte der TRIM-Befehl (siehe Screenshots) ausgeführt werden und im Anschluss nach vorheriger Datensicherung die Neuformatierung erfolgen.

Ich empfinde das schon als ziemliche Frechheit als Kunde, einfach so abgefertigt zu werden von WD. Uns ist angeblich kein Problem bekannt, aber dennoch ein so radikalen Schritt den Käufer*innen als Empfehlung zu geben zu, dann Sicherheitshalber falls bestehend Formatieren.

Ja ich habe auch eine WD Blue SATA SSD M.2 2280, kann also den ärger nachvollziehen zwar keine aus der 3D NAND Serie. Da ich auch Probleme mit Leistungseinbrüchen bei der Lese und Schreibgeschwindigkeit, dies sich vor allem beim Start bemerkbar gemacht hatte. Setze mich die Tage noch mal dran und prüfe auch entsprechend nach. Bevor ich sowas wie TRIM/Formattieren umsetze.

Hier mal mein Speedtest, wo ich auch das obere Durchstreichen musste. Da Leistungstechnisch an sich an die versprochenen Herstellerwerte herankomme, obwohl hier schon einiges an versprochener Leistung bereits wegefallen ist 10 - 12%:

Original-Posting mit Problemen
Muss ich mal weiter durchtesten ob das Problem wirklich hier herkommt.

Für die Tests unten war der Schreibcache deaktiviert, wie auch Windows Defender

 

[ThommyDD]

Bei meiner 2TB Datei gilt:
Änderungsdatum: 01.01.2020
Erstellungsdatum: 22.06.2020
Lieferdatum SSD: 21.06.2020
Reale letzte Änderung der Datei (Veracrypt-Container): 09.06.2022
Testdatum: 10.06.2020
Angabe des Tools: Alter der Datei 717 Tage

Bei TrueCrypt und VeraCrypt kannst du einstellen, ob das Änderungsdatum des Containers bestehen bleiben oder aktualisiert werden soll. Standardeinstellung ist aber die Beibehaltung.

Genau genommen müsste man beim Datum einen Vergleich zwischen Änderungs- und Erstellungsdatum machen. Das jeweils neuere Datum ist mit hoher Wahrscheinlichkeit das richtige. Windows-Systemdateien, Treiberdateien, Programmdateien usw. erhalten normalerweise als Änderungsdatum das Datum der Kompilierung. Wie hier schon zu sehen war, kann das teils Jahrzehnte her sein. Entscheidend ist aber für das hier betrachtete Problem, wann diese Daten auf der SSD gelandet sind. Anders sieht es bei Dokumenten aus. Diese können einmal in der Vergangenheit erstellt worden sein (Erstelldatum), und dann später hat man sie bearbeitet, wodurch das Änderungsdatum aktualisiert und die Datei in vielen Fällen komplett neu geschrieben wird. Aber eben auch nicht in allen. Wenn ich eine Videodatei öffne und darin nur die Metadaten ändere, wird nicht die komplette (sehr große) Datei neu geschrieben, sondern nur der Teil der Datei mit den Metainformationen. Hier wäre dann zwar das Änderungsdatum neuer als das Erstelldatum, für die Datenstruktur ist dann trotzdem das Erstelldatum maßgebend. Manche Programme erlauben auch die Beibehaltung oder gar bewusste Änderung des Änderungsdatums beim Bearbeiten. Das kann beispielsweise bei Bilddateien sinnvoll sein. Kamera-Speicherkarten mit dem FAT32-Dateisystem unterscheiden nicht nach Sommer- und Winterzeit. Änderungszeit ist die jeweils in der Kamera aktuell eingestellte Zeit. Abhängig davon, wann (Sommer oder Winter) man die Daten dann unter Windows auf den NTFS-Datenträger kopiert hat, zeigt Windows automatisch einen Offset von einer Stunde an. Und die Galerieansicht auf einem Android-Gerät wiederum sortiert Bilder nach Änderungsdatum, nicht etwa nach Metadaten. Wenn man dann nicht die Möglichkeit nutzt, die Änderungsdaten von Bildern aus verschiedenen Quellen zu synchronisieren, bekommt man nie eine ordentliche Ansicht hin.

Lange Rede, kurzer Sinn: Egal, welches Datum der Read Speed Tester nun anzeigt, es wäre so oder so zu einem großen Anteil das falsche. Eine individuelle Information seitens der Nutzer*innen wäre zur Einordnung nötig.

 

[gymfan]

Also ich würde ja etwas richtung 'dd if=/dev/sda of=/my/back/up' und zurück sagen fg

Wenn die SSD nicht nahezu voll ist, schreibt man damit viel zu viele Daten. Eine sinnvolles Backup-Software würde nur die belegten Sektoren sichern und nach dem TRIM der gesamten SSD wieder zurück spielen.

Unter Windows selbst kann man je nachdem was betroffen ist die Dateien ja nicht einfach neu schreiben. Ansonsten könnte sich jemand der User erbarmen und ein Script schreiben dass aus den tsv Files die langsamen ausliest, diese kopiert und zurückschreibt.

Falls die SSD genug Platz für die Datei hat, muss man nichts auf andere Laufwerke kopieren. Es geht darum, dass die Datei in neue, bisher ungentzte Sektoren geschreiben wird. Nur müsste man dazu wissen, welche Dateien betroffen sind und nicht nur, wie die durchschnittliche Leserate der gesamten Datei ist.

Das klappt außerdem nur mit Dateien, die niemand geöffnet hat (z.B. Systemdateien, Datenbanken, VC-Container, Logfiles).

Woher sollte das Tool denn wissen wann die Datei auf das Speichermedium geschrieben wurde?

Dann soll das Tool halt nicht solche Werte angeben sondern einfach nur alle belegten Sektoren der SSD lesen und dafür die Lesegeschwindigkeit und den Bezug zu einer Datei angeben. Das ist aber mehr Aufwand, da es dafür NTFS analysieren müsste.

So suggeriet es, dass es diese Daten aus irgendwelchen Metadaten der SSD auslesen könnte.

Ich empfinde das schon als ziemliche Frechheit als Kunde, einfach so abgefertigt zu werden von WD. Uns ist angeblich kein Problem bekannt, aber dennoch ein so radikalen Schritt den Käufer*innen als Empfehlung zu geben zu, dann Sicherheitshalber falls bestehend Formatieren.

Wenn ich mir hier im Thread die Werte ansehe, dann gibt es bis auf die eine SSD von Stormfirebird in der Meldung, schlicht keine, die von dem Problem betroffen ist. Auch im Ursprungs-Thread scheint sonst niemals eine betroffene SSD zu haben. Nur weil das Tool ein paar sehr kleine Dateien mit <100 MB/s liest, hat die SSD kein Problem.

Ich fände es mal interessant, wie viele Exemplare (und welche Modell exakt) bisher bekannt sind und ob nur ein einziger Kunde bereit wäre, seine betroffene SSD mit ungelöschten Daten an WD zum Austausch einzusenden.

Für mich bleibt ein denkbarer Serienfehler bisher genauso Spekulation wie ein möglicher HW Fehler der betroffenen Exemplare (hier ja bishe nur eine WD Blue 3D 1TB SATA).

 

[Bigeagle]

Ich habe nun mal zwei HDDs durchlaufen lassen und bin eher positiv überrascht was die Geschwindigkeit angeht. Entweder cached und optimiert da noch etwas die Zugriffe, oder die sind in der Praxis auch für Zugriffe < 64kb nicht halb so schlimm wie in Benchmarks O.o

Außerdem zwei Dinge gelernt.
1. Die roten Striche sind wohl der Mittelwert des Balkens
2. Das Programm ist nicht Multiinstanztauglich, der Screenshot meiner Spieleplatte war nur das noch im Durchlauf befindliche Fenster zu meiner Datenplatte
3. gut komprimierbare komprimierte NTFS Dateien gehen richtig ab.

108 3588,9 45,1 G:\Spiele\GalaxyClient\Games\Europa Universalis III\mod\Terra Nova\save games\France1782_08_16.eu3

3588 mb/s von HDD für ein savegame

Also ich finde ja über 200 MB/s mittlere Lesegeschwindigkeit für eine fast 73% gefüllte HDD garnicht so übel. Auch die langsamen Dateien mit nur einer handvoll unter 10 mb/s sind sehr unerwartet. Wo sind die lahmen 4kb Dateien? Das NTFS hat auch nur 4kb Cluster, hab extra nachgeguckt damit das nicht am Ende über die Dateitabelle gecached wurde.
Ich bin mir nicht mal sicher ob die Geschwindigkeit überhaupt realistisch ist, es erscheint mir etwas zu schnell. Einige Dateien haben deutlich über 300 MB/s. Wenn ich mir allerdings die größten Dateien angucke sieht das ok aus, keine unrealistischen Werte und die langsamen Ausreißer sind nach Stichprobe alle deutlich fragmentiert.
Irgendwo findet da immer noch ein Caching für kleinere Dateien statt obwohl man meinen würde dass bei sequentiellem durchlesen der Platten bei den Datenmengen der Cache praktisch funktionslos ist. Das könnte auch bei SSDs die ergebnisse falsch-positiv aussehen lassen.

Es gibt in den Logs keine Dateien unter einem halben MB bei mir. Ignoriert das Programm die einfach?

edit: hätte mir auch früher auffallen können dass die Anzahl der Dateien viel zu gering ist. 887k Dateien und nur 67k im log vom tool. Oder 2623k Dateien und 253k im log.
Damit ist auch klar warum die HDD so schnell erscheint und dass es nicht dafür da ist betroffene Dateien zu erkennen, sondern einen Überblick zu bekommen. Auch nicht unbedingt für einzelne Fälle, sondern über mehrere.

 

[moppie123]

entfernt

Also ich hatte sicherlich das Problem. WD Blue 3D 250GB, aktuellste FW. Aus dem lange nicht genutzten PC ausgebaut und in einen aktuellen gehangen (Ryzen 7 5800x). Das Tool hat mehrere Stunden gebraucht und hatte die 6MB/s als Ergebnis (bei ca. 40 GB Belegung von 250 GB). Hab jetzt 4 Stunden den Refresh gemacht (mit Disk Refresh) und danach nochmal getestet. Das hat kein 10 Min gedauert - Screenshot anbei.

 

[Stormfirebird]

Wenn ich mir hier im Thread die Werte ansehe, dann gibt es bis auf die eine SSD von Stormfirebird in der Meldung, schlicht keine, die von dem Problem betroffen ist.

Das stimmt einfach nicht, schon in meinem ursprünglichen Thread gab es Leute mit dem gleichen Problem, hier auch. Die meisten Screenshots die hier gepostet werden sind von komplett anderen Platten. Wobei sich tatsächlich beim überfliegen hier mehr Leute gemeldet haben die bei einer der fraglichen Platten tatsächlich kein Problemhaben, aber auch nicht jeder hat hier einen Screenshot gepostet der das Problem schon hatte.

Könnten die Leute die eine haben aber deren SSDs normal laufen mal schauen was für ein Herstellungsdatum auf der SSD vermerkt ist?

Ja ich habe auch eine WD Blue SATA SSD M.2 2280, kann also den ärger nachvollziehen zwar keine aus der 3D NAND Serie.

Eben doch, das ist eig. genau die Platte die ich habe nur hast du eine andere Firmware bzw. eher Revision, denn mir wird kein Firmware update angeboten.
@moppie123 Hat scheinbar auch eine ältere Revision und scheinbar das gleiche Problem.

 

[Luthredon]

Den refresh hat eine SSD, die im täglich laufenden PC verbaut ist, selbstständig zu tun.

Ich bin fälschlicherweise davon ausgegangen, dass es um 'gelagerte' SSD geht in dem Artikel.

Ich würde mir nie mehr eine HDD in den PC einbauen. Und selbst im NAS mit 10 GBit/s Anbindung müsste man schon eine SSD als Cache nutzen, um auch nur ansatzweise auf die Geschwindigkeit einer lokalen SATA SSD zu kommen.

Bei großen Datenmengen ists mir einfach zu teuer. So ein 50TB RAID5 Array aus HDs hat schon auch seine Vorteile und ist mit 600-700MB/s auch nicht so langsam. Die I/Os übernimmt der Controller, da brauch ich auch keine SSD.

Was soll außerdem ein Datengrab sein?

Das ist im Sprachgebrauch von einigermaße IT-affinen Menschen eigentlich bekannt . Grob gesagt, Archive, die eben auch längere Zeit nicht betromt sein können. Aber wie gesagt, darum gings in dem Artikel wohl gar nicht, mein Fehler.

Installierst Du alle paar Wochen Windows/Linux inkl. aller Programme neu, weil es sonst genügend Dateien gibt, die einmal bei der Installation geschrieben und danach nur noch gelesen werden?

Was hat das alles mit Archiven zu tun? Willst du sagen, die meisten Menschen haben keine Daten (in wachsender Menge), die sie gerne (möglichst sicher) aufbewahren möchten, aber eher selten lesen?

Ergänzung (12. Juni 2022)

Definiere "Datengrab". Bei mir - und auch anderen Nutzer*innen hier - ist auch eine regelmäßig genutzte SSD betroffen, die meine Spielebibliothek enthält.

Ich hab ja - nach nochmaligem Lesen des Artikels - schon festgestellt, dass ich irgendwie reingelesen habe, dass die SSDs längere Zeit unbestromt waren.
Aber Datengrab definiere ich einfach als Speicher, der hauptsächlich als Archiv dient und deshalb auch nicht durchgehend 'bestromt' ist. Das kann im einfachsten Fall eine 2,5" ext. HD sein, die eben nur angesteckt wird, wenn man etwas ablegt und wenn sie voll ist, noch viel seltener. Kostete kürzlich die 5TB Variante von WD bei Amazon 99€. Da würde ich nie eine SSD nehmen.

 

[failXontour]

Könnten die Leute die eine haben aber deren SSDs normal laufen mal schauen was für ein Herstellungsdatum auf der SSD vermerkt ist?

DOM - Date of Manufacturing: 20.09.2020
Kaufdatum: 10.01.2021 - über Mindfactory

 

[Kontrapaganda]

Mal 'ne Frage in den Raum zum Thema Datenverlust bei Flash mit der Zeit. Ich habe noch eine SD-Karte anno 2001 mit einer gigantischen Speicherkapazität von sage und schreibe 6,7 MB!
Ich benutze sie als Notfall-Bootloader für meine Linux-Systeme. (Habe externernen USB-Reader)
das letzte Mal unter Strom gesetzt habe ich die Karte vor vielleicht 2 Jahren beschrieben vor 4 Jahren.
Ich habe sie gerade mal angesteckt und die Checksummen der Dateien geprüft. Alles paletti.
Die Karte liegt sonst nur im Schrank zwischen Pfefferminzbonbons von 2009 in einer Werbe-Schachtel aus Alu, die ein Erinnerungsstück an ein einen aufgelösten Verein sind.

Hat alter Flash diese Probleme nicht?

 

[Corpus Delicti]

Hat alter Flash diese Probleme nicht?

2009 wurde noch Qualität gebaut.

Das stromlos --> Datenverlust-Zeitfenster wurde mit der Weiterentwicklung SLC->MLC->TLC->QLC immer kleiner.

 

[Tanzmusikus]

Meine WD SN520 512GB (PCIe NVME) im Notebook ist nicht betroffen.
Da kein Cache auf der SSD vorhanden ist, geht es jedoch runter bis 13,8 MB/s bei kleinen Dateien.

 

[massaker]

DOM - Date of Manufacturing: 20.09.2020
Kaufdatum: 10.01.2021 - über Mindfactory

Wow, also lesend (bis auf die Zugriffszeit) ganz ordentliche Werte für eine SATA-SSD....Aber schreibend...Ist ja schon fast eine Katastrophe...hmm. Wie voll war denn diese WD Blue3D M.2 1TB, als Du sie mit AS-SSD gebencht hast?🤔