SSD read speed 1/2 von write speed

#7491461
Lesenswert?

Der Name "disks" ist zwar sehr sprechend, aber erleichtert die Suche danach nicht gerade. Dessen exakte Arbeitsweise ist für die Frage aber sehr wichtig. Mir erschließt sich auf die Schnelle nicht, was das mir bisher unbekannte "disks" genau durchführt.

Ich bevorzuge zunächst getrennte rein sequentielle Lese- und Schreibtests als wichtige Grundlage. Dabei sollte bei einer SATA SSD für beides die Interface-Rate in der Größenordnung 500 MB/s rauskommen. Wenn es da schon klemmen sollte...

Das Diagramm ist ohne Erläuterung nicht hilfreich. Was ist die x-Achse, die hier in % angezeigt wird? Finden im Laufe des Tests verschiedene Phasen statt? In welchem Zeitrahmen in welcher Datengröße?

Bei kombinierten Lese- und Schreibtests kann Disk-internes Caching eine Rolle spielen, etwa eine begrenzte SLC-Zone für Schreiboperationen. Das ist dann eine inhärente Arbeitsweise und nicht deaktivierbar. Der Kaffeesatz sagt, es wird da hinein geschrieben und aus TLC/QLC gelesen. Da könnte aufgrund der internen Operationen eine zusätzliche Wartezeit der Leseoperationen auftreten.

OP (Firma: schlechthin) #7491473
Lesenswert?

Hab mal ne 3GB große Datei von intern sata zu intern sata kopiert, 12s lesend 15s schreibend von betreffendem Laufwerk. Das entspricht schon eher dem was man erwarten würde. Ist ein i3-4370. Hier noch der Bench des andren Laufwerks. Ubuntu ist Linux von Cannonical.

Angehängte Dateien:
#7491490
Lesenswert?

Interessant ist, dass bei der zweiten SSD irgendein Wert (wo ist eigentlich die Legende?) sich nach der Hälfte der Zeit verdoppelt.

Jan H. schrieb:

(prx) A. K. schrieb:

Disk-internes Caching

Wird wohl so sein, im Screenshot sieht man "Messwertgröße: 10,0 MiB". Das cacht sich sowieso leicht weg, vielleicht mal mit deutlich größeren Werten probieren.

Denke ich auch. Wenn man das Modell kennen würde (das leider in allen Screenshots abgeschnitten wurde), könnte man mal nachschauen, wie viel DRAM-Cache die SSD hat. Ggf. hat sie auch noch SLC-Cache.

Beitrag #7491570 wurde von einem Moderator gelöscht.
#7491624
Lesenswert?

Der G. schrieb:

Was ist davon zu halten wenn eine SSD die halbe Lesegeschwindigkeit hat als Schreibgeschwindigkeit? Normalerweise ist es ja anders rum. SMART Werte sind alle OK.

Das sieht ja wirklich ganz übel aus. Unter der Annahme das kein HW-Problem besteht (NT/Mainboard/Kabel) würde ich das Ding komplett sichern. Dann einen vollen ›blkdiscard‹ auf das Ding loslassen und die Sicherung zurück holen.

Sieht's danach immer noch so erbarmungswürdig aus, then »it's time to say good bye«

Anhang: So sollte es am SATAIII Port aussehen. Einmal fünf Monate alt, dreimal neu mit unterschiedlichen Blockgrößen.

Angehängte Dateien:
OP (Firma: schlechthin) #7491847
Lesenswert?

Ist schon komisch, das kommt wenn ich auf 1GB erhöhe (5 Messwerte), die GUI ist dabei eingefroren, evtl. war das der Grund für den IO Error. Das System läuft gut und der Test wurde aus dem System gestartet, werde es nochmal von einem Live System aus machen. Ist ein SATA 6Gb/s port

Nachtrag: Jetzt nochmal aus Live System beide Platten getestet, diesmal Test abgeschlossen. Anmerkung: Mein System ist letzte Zeit öfters mal eingefroren die Gui, konnte aber über virtual terminal (alt strg F3) neu starten.

Nachtrag: Beim Absturz der gnome Shell steht das im Syslog: gnome-shell[1748]: gnome-shell: Fatal IO error 11 (Die Ressource ist zur Zeit nicht verfügbar) on X server :0.

WD Platte ca 2019 gekauft, Kingston ca. 2j später. Würde ja noch Garantie geben.

smartctl -t findet keine Probleme

Angehängte Dateien:
OP (Firma: schlechthin) #7491900
Lesenswert?

Bin mir unschlüssig, soweit ich weiß spielt es beim Bench keine Rolle wie viele und welche Daten auf der Platte gespeichert sind. Das nächste mal mach ich die Tests wenn das Gerät neu ist und archiviere das um später einen Vergleich zu haben. Vermutlich ist alles ok, und die Abstürze sind Bugs. Vielleicht eine Anomalität eines Controllers auf der Platte oder dem Mainboard.

#7491911
Lesenswert?

Der G. schrieb:

Nachtrag: Beim Absturz der gnome Shell steht das im Syslog: gnome-shell[1748]: gnome-shell: Fatal IO error 11 (Die Ressource ist zur Zeit nicht verfügbar) on X server :0.

Viel wichtiger wäre (als root) die ›dmesg‹ Ausgabe. Wenn's da Probleme zeigte, könnte man mehr sagen. Oder du bootest das System mal im non-GUI Modus. Dann

1
dd if=/dev/sdx of=/dev/null bs=64M status=progress

So etwas muß klaglos das ganze Drive lesen. Und man sieht die Geschwindigkeit. Aber Obacht mit den Parametern. Wollen doch nicht, das die Klagemauer nass von Tränen ist. ;-)

Und so sieht's dann aus:

1
~$ dd if=/dev/RO_sdb of=/dev/null bs=64M status=progress
2
249846300672 Bytes (250 GB, 233 GiB) kopiert, 462 s, 541 MB/s
3
3726+1 Datensätze ein
4
3726+1 Datensätze aus
5
250059350016 Bytes (250 GB, 233 GiB) kopiert, 462,481 s, 541 MB/s
6
~$
OP (Firma: schlechthin) #7492037
Lesenswert?

So hab jetzt dd gemacht und bei 7mb/s dauert das natürlich zu lang. Dann die Ports gewechselt also Anschluss + Kabel getauscht. Im Prinzip selbes Ergebnis nur ich hab früher abgebrochen, später wäre die Leserate auch auf 7 gesunken. Beim Bench war diesmal dann lesen aber schneller als schreiben. Tippe auf Bug in Controller oder Firmware des Speichers, kann sein dass es mir bisher nur nicht aufgefallen ist. (keine swap auf der platte angelegt, schreibt ubuntu dann als datei in /)

Angehängte Dateien:
#7492499
Lesenswert?

Der G. schrieb:

Hab mal ne 3GB große Datei von intern sata zu intern sata kopiert, 12s lesend 15s schreibend von betreffendem Laufwerk. Das entspricht schon eher dem was man erwarten würde. Ist ein i3-4370. Hier noch der Bench des andren Laufwerks. Ubuntu ist Linux von Cannonical.

Unter *buntu gibt es ein Benchmark-Tool für Festplatten namens "bonnie++", das Du aus den Paketquellen zum Beispiel mit "sudo apt install bonnie++" installieren kannst. Das macht zwar keine schicken Grafiken, liefert aber zuverlässige Messwerte. Ansonsten haben die Leute bei Arch Linux -- wie so oft -- eine Übersicht verschiedener Benchmark-Tools: [1].

[1] https://wiki.archlinux.org/title/benchmarking

Moderator Persönliche Seite #7492788
Lesenswert?

Ein T. schrieb:

Unter *buntu gibt es ein Benchmark-Tool für Festplatten namens "bonnie++", das Du aus den Paketquellen zum Beispiel mit "sudo apt install bonnie++" installieren kannst. Das macht zwar keine schicken Grafiken, liefert aber zuverlässige Messwerte.

Das kann ich nur bestätigen. bonnie++ bearbeitet beim Benchmarking eine Datei, welche standardmäßig doppelt so groß ist wie das RAM. Damit können dann irgendwelche Cache-Effekte, die oben aufgetreten sind, grundsätzlich erstmal ausgeschlossen werden.

P.S.

Graphiken gehen schon, denn bonnie++ erzeugt durchaus maschinenlesbaren Output, den man weiterverarbeiten kann, siehe Anhang.

Angehängte Dateien:
#7492803
Lesenswert?

Komplette Umgehung des Lesecaches. (Was beim Lesen eines vollständigen Drives wohl nur für die Wenigsten eine Bedeutung haben sollte) ;-)

1
dd if=/dev/RO_sda of=/dev/null bs=64M count=128 iflag=direct  status=progress

Gerne auch zweimal ausführen, wenn man's nicht glaubt.

PS. Man muss nicht immer sein komplettes Arsenal an nuklearen Waffen auf Spatzen abwerfen …oder wie auch immer das betreffende Sprichwort lautet…

#7492877
Lesenswert?

Rolf M. schrieb:

Aber nur des Betriebssystem-Caches. Die Laufwerke haben in der Regel eigene Caches

Ja. Jedoch geht es hier um das KOMPLETTE Lesen eines Laufwerkes!

Selbst für ein 250GB Laufwerke käme da eine Menge Cache-RAM zusammen wenn die Ergebnisse signifikant beeinflusst würden.

PS:

1
~$ dd if=/dev/RO_sda of=/dev/null bs=16M count=1 iflag=direct  status=progress
2
1+0 Datensätze ein
3
1+0 Datensätze aus
4
16777216 Bytes (17 MB, 16 MiB) kopiert, 0,0414557 s, 405 MB/s
5
~$ dd if=/dev/RO_sda of=/dev/null bs=16M count=1 iflag=direct  status=progress
6
1+0 Datensätze ein
7
1+0 Datensätze aus
8
16777216 Bytes (17 MB, 16 MiB) kopiert, 0,0413612 s, 406 MB/s
Beitrag #7492889 wurde von einem Moderator gelöscht.
OP (Firma: schlechthin) #7492890
Lesenswert?

Schöne Übersicht über Benchmark Software, dd war hier sehr aufschlussreich und einfach. Könnte sein dass es irgendwie ein fake ist. Habs von Amazon und mir ist aber nichts aufgefallen, war der Überzeugung eine Orginal gekauft zu haben. Es ist schon sehr merkwürdig, dass der Speicher an sich gut funktioniert aber solche komischen Werte produziert. Dass WD hier weniger optimale Chips verbaut ist doch sehr unwahrscheinlich. Hier: www.hardwareluxx.de/community/threads/wer-steckt-hinter-fanxiang.1325682/ www.youtube.com/watch?v=qRYMM0DQo1w Gehe im Moment von einem Defekt oder Montagsmodell aus.

Fakes sind nicht so unwahrscheinlich, der Supplementemarkt ist betroffen, es geht sogar so weit dass in der Apotheke gefälschte Medikamente landen.

#7492918
Lesenswert?

Der G. schrieb:

Dass WD hier weniger optimale Chips verbaut ist doch sehr unwahrscheinlich.

WD hat sich SanDisk einverleibt, und SanDisk hat aktuell massive Qualitätsprobleme. Anders als jeder andere echter Speicherhersteller hat SanDisk nie irgendwelche wirklich brauchbaren und verlässlichen Spezifikationen (sprich: Datenblätter) veröffentlicht, sondern nur blumigen Marketingbullshit betrieben.

WD hat sicherlich Kompetenz bei der Konstruktion von Festplatten (auch wenn man vermeiden sollte, 2.5"-Festplatten im USB-Gehäuse von denen zu kaufen), aber deren SSD-Sparte traue ich nicht weiter als dem, was SanDisk macht.

SSDs kaufe ich von Speicherherstellern - wenn es günstig sein soll, von Crucial (Micron), in Spezialfällen (2030) Kioxia (Toshiba) oder sonst halt Samsung.

Aber das kann natürlich jeder halten, wie er will.

Garantierten "Erfolg" gibt es beispielsweise hiermit:

https://www.aliexpress.com/item/1005005673404266.html

OP (Firma: schlechthin) #7493175
Lesenswert?

Auch noch interessant ist TBW also die maximale Belastbarkeit. total bytes written. Mich wundert dass der Fakt dass eine fast volle Festplatte die viel benutzt wird nur einen Bruchteil der Zeit hält kaum Beachtung findtet, besser gesagt ich finde dazu nichts. Weil da das wear leveling nicht mehr greift und die verbleibenden Blöcke tot geschrieben werden. Kann man verhindern indem man ne ordentliche Portion auf der Platte frei lässt und jährlich die Daten rauskopiert, löscht und wieder reinkopiert. Sinnvoll wäre evtl. auch ne kleine Platte für die oft geschriebenen Daten zu nehmen und den Rest der nicht angerührt wird auf nen großen Speicher auszulagern. Das wäre bei Ubuntu Swap und alle .* in home.

#7493189
Lesenswert?

Der G. schrieb:

Auch noch interessant ist TBW also die maximale Belastbarkeit. total

Falsch, TBW ist nicht die max. Belastbarkeit. Du schreibst Unsinn.

TBW ist üblicherweise der Wert, bis zu dem Dir der Hersteller, sofern die Festplatte in einem definierten Zeitraum (z.B. 3/5 Jahre) aufgibt, Garantie gewährt.

Das hat gar nix mit Belastbarkeit oder Lebensdauer o.ä. zu tun.

bytes written. Mich wundert dass der Fakt dass eine fast volle Festplatte die viel benutzt wird nur einen Bruchteil der Zeit hält kaum Beachtung findtet, besser gesagt ich finde dazu nichts. Weil da das wear leveling nicht mehr greift und die verbleibenden Blöcke tot geschrieben werden.

Wundert ja auch nicht, Du schreibst Unsinn und hast wear levelling nicht verstanden.

Stichwort: Static Wear Levelling, das greift sehr wohl, da hier die Daten bereits beschriebener Blöcke bei Bedarf verschoben werden. Im Idealfall werden so alle Blöcke der SSD gleich oft beschrieben.

Informiere Dich doch mal, bevor Du schreibst, immerhin ist das Thema zig-fach durchgekaut.

#7493239
Lesenswert?

Der G. schrieb:

Auch noch interessant ist TBW also die maximale Belastbarkeit. total bytes written.

Das ist nur der Wert, bis zu dem der Hersteller bereit ist, Garantie zu gewähren, das bedeutet nicht, daß die SSD danach tot ist.

Ein anderer Parameter wird "DWPD" genannt: "drive writes per day".

Ja, und jetzt betrachten wir das mal:

https://www.heise.de/preisvergleich/samsung-ssd-870-evo-1tb-mz-77e1t0b-a2458826.html?hloc=de

Diese 1-TB-SSD ist mit 600 TB spezifiziert.

Bei den SATA-typischen 500 MByte/sec Schreibrate dauert ein vollständiges Beschreiben also 2000 Sekunden - das mal 600 sind zwei Wochen. Zwei Wochen durchgehendes Beschreiben.

Der "DWPD"-Wert, mit dem diese SSD spezifiziert ist, liegt bei 0.3, also 300 GByte.

Und nun gehen wir mal in uns: In welchem Nutzungsszenario schafft man es überhaupt, 300 GByte /pro Tag/ auf seine SSD zu schreiben? Und das dauerhaft, 7 Tage die Woche ...

OP (Firma: schlechthin) #7493561
Lesenswert?

Für mich hört sich das nicht viel an, 2 Wochen volle Power, nehmen wir irgend eine Serveranwendung, Cloud, Backup oder so. SSD sollen aber HDD in der Beschreibbarkeit auch übertreffen können. Gut ist dass dann nur die Beschreibbarkeit aufhört, d.h. die Daten können nach Lebensdauerende noch gelesen werden. Also droht kein Datenverlust. Hab mal Spyware Fenster 11 (erweiterbar mit unfreiwilligen Datenshredder Addons) installiert und das WD Dashboard, das meint 2-3% von TBW verbraucht. Findet auch bei den Smart Tests keine Fehler, und kein Firmware Update da.

#7493588
Lesenswert?

Der G. schrieb:

SSD sollen aber HDD in der Beschreibbarkeit auch übertreffen können.

Kommt auf dich an, also was du mit dem Gerät treibst, in dem die SSD steckt. Wir haben ein Storage System mit ca einem Dutzend SSDs in RAID, dessen Lebensdauer auf 5 Jahre 24x7 100 MB/s Schreibrate ausgelegt ist. Die SSDs darin sind keine speziellen high endurance Typen.

Sowas muss man auch nicht selbst ausrechnen. Dell hat eine solche Rechnung im Konfigurator auf der Webseite.

#7493782
Lesenswert?

Der G. schrieb:

Ich bin nur Privatanwender, aber ein sehr interessantes Thema, mit ner nvme könnte man so einen hardcoretest machen und schauen wie viele tbw wirklich möglich sind und wie der Speicher dann genau ausfällt.

Leichte Korrektur, du könntest diese Eine tot schreiben und schauen wie viele TBW bei dieser Einen möglich waren. Und ja, du wüsstest dann wie diese Eine ausfiel.

#7493835
Lesenswert?

Rolf M. schrieb:

Mit genug Geld kann man auch 100 davon nehmen, um sicherzustellen, dass das Ausfallverhalten nicht vollkommen zufällig ist.

Ja, da lohnte sich schon fast eine wackelige Statistik. ;-)

Ich stelle mir allerdings die Frage, ob das kontinuierliche komplette Vollschreiben mit 0xaa, dann, im nächsten Durchgang, mit 0x55 das gleiche Fehlerbild erzeugen würde wie ein kontinuierliches Beschreiben zufällig ausgewählter 4KiB Blöcke mit den gleichen Mustern. Ich würde mein Geld auf völlig unterschiedliches Verhalten setzen.

Fragen über Fragen.

OP (Firma: schlechthin) #7494111
Lesenswert?

Harald K. schrieb:

Es ist halt komplett sinnlos, aber macht nur weiter.

Mensch Leute sowas einfach ignorieren, wenn es ihn nicht interessiert dann ist das schön für ihn, wenn er es auf diese weise Kund tut, ist das auch schön für ihn. Wenn man auf sowas sinnloses eingeht und sich streitet hat man das Ziel aus den Augen verloren und zwar einen möglichst glorreichen Thread über SSD knowledge der allen Lesern eine grelle Glühbirne über die Frisur zaubert.

Auch interessant, es gibt pcie nvme Adapter, aber davon würde ich Abstand halten, weil ein Motherb. ohne M.2 nvme Unterstützung könnte damit Probleme haben das Laufwerk zu booten, dann müsste man komische Verrenkungen machen wie das Bios patchen. Ich hab mich mit dem H81Plus dagegen entschieden und SATA genommen.

#7494113
Lesenswert?

Der G. schrieb:

aber davon würde ich Abstand halten, weil ein Motherb. ohne M.2 nvme Unterstützung könnte damit Probleme haben das Laufwerk zu booten, dann müsste man komische Verrenkungen machen wie das Bios patchen.

Oder halt nicht von der NVMe-SSD booten, sondern von einer (kleinen) SATA-SSD. Dann kann man das (offenkundig ältliche) Motherboard weiterverwenden, muss aber nicht auf den Geschwindigkeitsvorteil von NVMe verzichten.

OP (Firma: schlechthin) #7497015
Lesenswert?

Update und Konkretisierung:

TRIM: sudo fstrim -v /
/: 40,6 GiB (43596931072 Bytes) getrimmt Windows: 18,5 GiB (19835265024 Bytes) getrimmt (Die Windows Parttion ist die die in den Benchmarks auf den Bildern getestet wurde.) Resultat: Keine Veränderung

Beim Kopieren von 5GB Dateien verhält sich die WD genauso wie die Kingston, beim Kopieren von Kingston auf Kingston (NTFS) sinds 80MB/s und von WD (ext4 luks) nach Kingston 140MB/s und von WD nach WD 140MB/s

NTFS ist unter Linux langsamer, und luks evtl. auch.

Bei sudo dd if=/dev/sdb of=/dev/null bs=64M status=progress Sackt die Leserate von WD nach 1GB von 400MB/s abrupt auf 70MB/s ab und zwar fallend, die Kingston rattert mit 400MB/s die GB nur so durch während die WD lange nicht über 2GB kommt. Man kann den Test nicht abschließen weil irgendwann sind 7MB/s und noch weniger.

Bei der Kingston verändert sich überhaupt nichts wenn ich sie mit 5GB Dateien vollgeschrieben habe.

Ich frage mich was mit der WD genau los ist. Im Alltag merkt man das ja nicht. Evtl. ist das einfach nur eine Besonderheit der WD die als normal betrachtet werden kann? Immerhin kopiert sie ja die 5GB Dateien problemlos auf sich selbst.

#7497143
Lesenswert?

Der G. schrieb:

Ich frage mich was mit der WD genau los ist.

Die hat's hinter sich.

Im Alltag merkt man das ja nicht. Evtl. ist das einfach nur eine Besonderheit der WD die als normal betrachtet werden kann?

Nein. So ein Verhalten weist auf einen üblen Defekt hin.

Eine SSD, die beim Lesen langsamer wird als eine Festplatte? Die ist eindeutig hinüber.

Mach ein Backup. Jetzt, sofort. Nicht gleich, jetzt.

OP (Firma: schlechthin) #7497608
Lesenswert?

Ich mache regelmäßig Backups, hab mal ne sehr unangenehme Erfahrung mit Datenverlust gemacht als ich ne Soundkarte eingebaut hab und der Pc dann abgestürzt ist und die Hälfte der Dateien Cyrillisch war.

Jetzt hat ein "/var/log/syslog > sata bus error DRDY " dazugesellt, dh. das Laufwerk macht schon Probleme und wird als read only geschützt. Das hatte ich wiederholt schon mal früher also ich mechanische HDDs irgendwie ohne sie festzuschrauben im Gehäuse betrieben habe. Daraus hab ich gelernt mech. HDDs fest im Gehäuse zu verschrauben und zwar waagrecht, und dass 2,5 Zoll HDDs schneller ausfallen als 3,5HDDs.

Aber ich konnte bei diesem Error immer noch die Platte auslesen, indem ich sie an ein externes HDD USB2 Gehäuse gehängt hab. Diesmal geht das auch, da läuft sie auch wieder normal. Scheinbar wird die Platte da sanfter betrieben oder so. Hauptsache es funktioniert.

Unwahrscheinlich aber nicht unmöglich ist dass es irgendwie am Sata Kabel oder so liegt.

OP (Firma: schlechthin) #7498319
Lesenswert?

Hab erst mal das Kabel gewechselt, das war das dünnste und schäbigste was ich hatte, evtl lags daran. Danach konnte ich sie noch normal weiterverwenden. Jetzt ist sie schon ersetzt und wird überschrieben, und das dauert über 10 Stunden also Schneckentempo. Das war am Anfang definitiv nicht so, die muss über die Zeit irgendwie defekt geworden sein.

OP (Firma: schlechthin) #7498434
Lesenswert?

Verkäufer war jemand der Netzwerkhardware die SSD und Kosmetik verkauft, nur UStID ist angegeben. Versand Amazon. Hab sogar noch den Karton, war alles orginalverpackt und versiegelt. Die Kratzer sind minimal, und evtl. in der Fabrik entstanden, nur an einer Seite. Auf der Verpackung ist Englisch und Französisch. SN Warranty läuft noch ein Jahr.

Hab das SSD Gehäuse aber nicht an Ground angeschlossen, aber das ist ja bei ext. Laufwerken auch nicht so. Also das sollte kein Grund sein.

#7498465
Lesenswert?

Der G. schrieb:

Jetzt ist sie schon ersetzt und wird überschrieben, und das dauert über 10 Stunden also Schneckentempo.

Wozu soll bei einer SSD überschreiben gut sein? SSD löscht man via "Secure Erase". Damit werden alle Blöcke gelöscht und das dauert vielleicht ne Minute. Danach sind allerdings auch keine Strukturen wie Partitionen, Dateisystem usw. vorhanden. Zur Anwendung siehe z.B.: wiki.ubuntuusers.de/SSD/Secure-Erase/

Wenn die SSD dann leer ist, könnte man einen Performancetest dann auch sinnvoll ausführen.

OP (Firma: schlechthin) #7498486
Lesenswert?

Sehr verwirrend, also scheinbar hat das Teil mal normale Speedwerte und dann wieder miserabel. Vor ein paar Tagen waren die Leistungstest Werte, die kopier Werte alle ok nur dd war so extrem langsam.

Hab jetzt zwecks rma das Teil mit WD USB Stick mit "Sanitize" behandelt. Wollte auch secure erase machen, aber da war security froze state im weg, dazu müsste man die ssd nach dem bios post anschließen.

Jetzt gibt aber auch plötzlich der dd command ganz normale Werte aus, bei allen ssd im system. Auch der Leistungstest ist jetzt wieder normal. Und Platte vollkopieren geht jetzt auch wieder blitzschnell. Hängt jetzt am 3G Port.

Könnte es sein dass es mit dem Partition Table Probleme gab? Oder die Software auf dem Laufwerk ein Problem hatte? Oder weil ich Luks unter Ubuntu verwendet hab? Oder der TRIM oder sonstwas nicht richtig gearbeitet hat? Hab die Platte n paar mal formatiert und dieses sanitize gemacht. Alles verwirrend. Könnte auch sein dass ein Chip aufm Controller n Wackler hat oder sonstwas.

Die Sams ist neu, die Kingston hat win11 infektion.

Nachtrag: Nochmal alles getestet, jetzt muss ich davon ausgehen dass das Laufwerk ok ist. Vielleicht doch das Kabel, oder Dreck am Stecker. Oder aber man muss seine SSD ab und zu mal erasen? Also ich hab schon mal gelesen dass SSD langsamer werden können wenn sie voll sind. Evtl. hat sich aus irgend einem Grund Datenmüll angesammelt und das Laufwerk blockiert, was jetzt weg ist.

Angehängte Dateien:
OP (Firma: schlechthin) #7498632
Lesenswert?

Wenn ich das Problem nochmal hätte, täte ich erst mal die Stecker n paar mal an und abstecken, dann neues Kabel, anderer Port, dann erasen und kucken was passiert. Hinterher ist man immer schlauer.

Die liefert jetzt einfach so ab wie man das von ner SSD erwartet, hier ein Test an nem USB3 Port.

Angehängte Dateien:
OP (Firma: schlechthin) #7500261
Lesenswert?

Auch sporadische Abstürze sind jetzt weg die ich auf die Software geschoben hab und Vmware ist jetzt richtig speedy mit der andren SSD. Die WD ist aber auch absolut tadellos und wieder im Einsatz. War wohl ein Dateisystemfehler oder ein evtl. Virus, was durch das low level Format beseitigt wurde. Also die Platte war 200gb ntfs davon 190GB voll, die andre hälfte war luks encrypted und zu 85 Prozent voll. Hatte vor kurzem ne kleine laptop platte, die hatte Lesefehler und smart test hat abgebrochen, nach fsck bzw. Windows lang formatieren war der Fehler behoben und die Sektoren verschoben.

Ich bin eigentlich davon ausgegangen dass Ubuntu das Dateisystem selbst regelmäßig prüft, bin mir aber nicht sicher, siehe: https://wiki.ubuntuusers.de/Dateisystemcheck/#Dateisystempruefung-einer-LUKS-verschluesselten-Partition (hab ich nicht gemacht)

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren