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.
Benchmark ist vom Programm disks unter ubuntu, cache ist da standardmäßig deaktiviert wegen Datensicherheit. HD tune unter Windows gibt selbes Ergebnis.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
Welches System, Hardware? Bei Pi z.B. gibts Probleme mit manchen Chipsätzen am USB3 Anschluss.
(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.
Angehängte Dateien:
-
kgn.jpg
58 KB
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.
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.
Rolf M. schrieb: > Wenn man das Modell kennen würde Steht in den Diagrammen. Allerdings nicht als Handelsname, sondern nur als Herstellercode.
Vielleicht haben die SSDs gar keinen Cache. https://documents.westerndigital.com/content/dam/doc-library/de_de/assets/public/western-digital/product/internal-drives/wd-blue-ssd/product-brief-wd-blue-3d-nand-sata-ssd.pdf
Beitrag #7491570 wurde vom Autor gelöscht.
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.
Norbert schrieb: > Das sieht ja wirklich ganz übel aus. Ob Du wohl die exakt gleichen Messungen durchgeführt hast wie er?
Wie heißt's so schön bei Geizhals zu dieser SSD? "Dieses Modell ist mit unterschiedlichen Controller- und Speicherbaustein-Bestückungen erhältlich." (https://geizhals.de/western-digital-wd-blue-3d-nand-sata-ssd-500gb-wds500g2b0a-a1661242.html) Vertrauenerweckend ist anders.
Harald K. schrieb: > "Dieses Modell ist mit unterschiedlichen Controller- und > Speicherbaustein-Bestückungen erhältlich." Bei HDDs wurde ein in den üblichen anfänglichen Benchmarks passabel abschneidendes Modell mit CMR-Technik anschliessend durch SMR ersetzt, ohne das irgendwie anzuzeigen. Da gabs dann allerdings eins hinter die Löffel.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Ob Du wohl die exakt gleichen Messungen durchgeführt hast wie er? Jetzt bin ich gespannt. Welche Knöpfe würden denn Abweichungen dieser Größenordnung hervor rufen? An einem SATA III Anschluss? Wenn man ›Nun bitte lesen‹ drückt! ;-) PS. 10MiB Blöcke zeigen das gleiche Bild…
Angehängte Dateien:
-
test_fail.jpg
53 KB -
vs.jpg
130 KB
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
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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 | ~$ |
:
Bearbeitet durch User
Ich hab vergessen zu erwähnen, dass der vs.jpg Bench weiter oben im Bild bei der Kingston n paar Sekunden gedauert hat und bei der WD 15 Minuten! journalctl -b -k hat keine Meldungen dazu. dmesg
Liegt auf der Platte evtl ein SWAP oder so? Irgendwas, das Zugriffe während dem Test generiert?
Roland E. schrieb: > Liegt auf der Platte evtl ein SWAP oder so? Irgendwas, das Zugriffe > während dem Test generiert? Selbst wenn während des Tests ein Zugriff auf ›swap‹ erfolgte, würde das System nicht die Grätsche machen.
Angehängte Dateien:
-
dd_vs__and_port_change.jpg
35 KB -
port_change.jpg
160 KB
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 /)
:
Bearbeitet durch User
Der G. schrieb: > So hab jetzt dd gemacht und bei 7mb/s dauert das natürlich zu lang. Das Ding ist zwar deutlich kleiner als der Zentralfriedhof von Chicago, dafür aber viele Male toter.
Denke auch dass es defekt ist, leider bietet WD die Dashboard Software nur für Windows an, also kann ich es nicht versuchen die Firmware zu updaten, dann schicke ich es RMA. Danke für die Hilfe, dd war n guter Tipp :-)
:
Bearbeitet durch User
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
Angehängte Dateien:
-
bonnie.png
30 KB
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.
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…
Norbert schrieb: > Komplette Umgehung des Lesecaches. Aber nur des Betriebssystem-Caches. Die Laufwerke haben in der Regel eigene Caches, auf die sich das nicht auswirkt. SSDs können sogar zwei Cache-Ebenen haben: Einen DRAM-Cache und einen SLC-Cache.
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 |
:
Bearbeitet durch User
Beitrag #7492889 wurde vom Autor gelöscht.
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.
:
Bearbeitet durch User
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
Harald K. schrieb: > SSDs kaufe ich von Speicherherstellern - wenn es günstig sein soll, von > Crucial (Micron), in Spezialfällen (2030) Kioxia (Toshiba) oder sonst > halt Samsung. WDC/SanDisk hat eine eigene Flash-Herstellung, eng mit Kioxia verbandelt.
(prx) A. K. schrieb: > WDC/SanDisk hat eine eigene Flash-Herstellung Ja, haben sie. Aber sie sind sowohl außerstande, Datenblätter zu produzieren wie auch reproduzierbare Produkte - siehe Beitrag "Re: SSD read speed 1/2 von write speed"
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.
:
Bearbeitet durch User
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.
Danke für die Korrektur, da braucht man sich also gar keine Gedanken machen, nur overprovisioning könnte helfen, also beim Partitionieren 10% nicht benutzen. Aber ich schätze mal die Hersteller haben eh schon die optimalen Werte genommen. https://en.wikipedia.org/wiki/Wear_leveling#Static_wear_leveling
:
Bearbeitet durch User
Der G. schrieb: > nur overprovisioning könnte helfen, also beim Partitionieren 10% > nicht benutzen. Das ist doch ein Linux System. Da werden doch wohl hoffentlich im ›fstab‹ die entsprechenden Einträge ein ›discard‹ vorweisen können. (Sowohl ext4 als auch swap) Somit kannst du dir diese Klimmzüge (overprovisioning) sparen.
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 ...
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.
:
Bearbeitet durch User
Der G. schrieb: > Für mich hört sich das nicht viel an, 2 Wochen volle Power, nehmen wir > irgend eine Serveranwendung, Cloud, Backup oder so. Die Sereranwendung, die das hinbekommt, ist kaputt. Sehr kaputt. Welche Netzwerkanbindung soll die denn bitte haben? Da müsste eine 5-GBit-Ethernet-Leitung auf Kante ausgenutzt werden. 24/7.
Der G. schrieb: > Für mich hört sich das nicht viel an, 2 Wochen volle Power, nehmen wir > irgend eine Serveranwendung, Cloud, Backup oder so. Nur ein wilder Wüsten-Clown würde in solch einem Fall eine EVO oder ähnlich unsinniges Material einsetzen.
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.
:
Bearbeitet durch User
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.
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. Schon ein paar Jahre her: https://www.heise.de/news/SSD-Langzeittest-beendet-Exitus-bei-9-1-Petabyte-3755009.html
:
Bearbeitet durch User
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.
Norbert schrieb: > 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. Mit genug Geld kann man auch 100 davon nehmen, um sicherzustellen, dass das Ausfallverhalten nicht vollkommen zufällig ist.
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.
Harald K. schrieb: > Es Was? > ist halt komplett sinnlos, Für wen? > aber macht Wer? Alle? > nur weiter. Womit?
Das ist gerichtet an die Helden, die glauben, daß eine typische SSD für ihre Anforderungen nicht langzeitstabil genug wäre. Also auch an Dich persönlich.
Harald K. schrieb: > Also auch an Dich persönlich. Schau Harald, du kennst mich nicht. Also spar' dir solche ›Weisheiten‹ Ich habe in meinem Leben schon mehr vergessen als du jemals gewusst hast und trotzdem weiß ich noch immer deutlich mehr als du.
Norbert schrieb: > Ich habe in meinem Leben schon mehr vergessen als du jemals gewusst hast > und trotzdem weiß ich noch immer deutlich mehr als du. Du hast sicherlich einen Mitgliedsausweis für den erlesenen Dunning-Kruger-Club.
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.
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.
Stimmt man könnte vermutlich den Bootloader sogar auf ne Sd Karte oder USB Stick schreiben. Aber ich will etwas was wie gewohnt ohne Umwege funktioniert. Der heise Artikel ist ja sehr interessant, die Dinger halten ja praktisch unendlich.
Der G. schrieb: > Aber ich will etwas was wie gewohnt ohne Umwege > funktioniert. Nun, Du schriebst, daß es sein könnte, daß das Board nicht von NVMe booten kann. Könnte.
Nein, es ist sogar sehr wahrscheinlich. https://www.youtube.com/results?search_query=nvme+pcie+adapter+old+computer+boot Aber nur als Speicher nutzen müsste eigentlich gehen, hab mich damit nicht weiter beschäftigt.
:
Bearbeitet durch User
Du benutzt tatsächlich Youtube als Suchmaschine? Sachen gibt's.
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.
:
Bearbeitet durch User
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.
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.
Der G. schrieb: > ... > > Unwahrscheinlich aber nicht unmöglich ist dass es irgendwie am Sata > Kabel oder so liegt. Ja, würde ich auch sagen. Sata Kabel sind eklig empfindlich, die Kontakte eher fipsig, gemessen am Anspruch. Bissel schief reicht schon für Ärger.
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.
Was mir auffällt, der Lack ist an einer Seite etwas abgekratzt, also ob man die SSD schon mal in ein Metallgehäuse geschoben hätte. Das habe ich aber nie gemacht.
Kommt jetzt die Salamischeibe, daß Du diese SSD gebraucht gekauft hast?
Neue SSDs sind verpackt. Nicht durch Amazon, sondern vom SSD-Hersteller selbst. Wenn diese Verpackungen schon mal geöffnet waren, sieht man ihnen das an. Kannst Du Dich noch daran erinnern, wie das bei Deiner SSD war? Warum ist Dir das mit den Kratzern eigentlich jetzt erst aufgefallen?
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.
:
Bearbeitet durch User
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.
Angehängte Dateien:
-
sanitize.jpg
210 KB
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.
:
Bearbeitet durch User
Auch an nem USB3 Gehäuse gibt die jetzt ganz normale Benchmark Werte aus, die ist da ca. 80% - 100% so schnell wie am 6G sata Port!
:
Bearbeitet durch User
Angehängte Dateien:
-
liefertab.jpg
55 KB
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.
:
Bearbeitet durch User
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)
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.