Habe getestet:
WD blue, Kingston, Samsung EVO hier bekommt man was man von SSD erwartet um die 400-500MB lesen + schreiben
Crucial BX500, hier fällt die Schreibrate auf 90-140MB/s !!
Intenso Top 500GB, hier fällt die Schreibrate bei einer auf 54MB, bei der andren auf 63MB/s !!
Der Befehl zum Benchmark
for i in {001..200}; do dd if=/dev/zero of=file_$i bs=1M count=5000; done
schreibt in den Ordner auf der SSD der mit dem Terminal geöffnet wurde 5GB große Dateien mit Nullen. Das misst sozusagen die Schreibrate wenn auf die Platte große Dateien geschrieben werden. Wenn man z.B. 50 MB nimmt, dann variiert der Speed, dann sind die langsamen Platten schneller, es wechselt dann von 300-50MB/s für Intenso. Auch schreiben die langsamen Platten erst mal so 5-25GB in nem ordentlichen Speed den man von SSD erwartet, sinkt dann aber ab, bzw. pendelt bei kleineren Dateien.
Intenso zeigt bei GSmartcontrol ATA VERsion: ACS-2 T13/2015-D revision 3
Kingston: ACS-3 T13/2161-D revision 4
Samsung: ACS-4 T13/BSR INCITS 529 revision 5
ob das etwas bedeutet?
Mich würde interessieren was eure Platten so machen? Mit 5GB und sagen wir 100MB:
for i in {001..200}; do dd if=/dev/zero of=file_$i bs=1M count=100; done
(Vorsicht bei der Systemplatte, auf der das Betriebssystem läuft, die darf man nicht ganz vollschreiben sonst stürzt der PC ab.) (Und Vorsicht bei dem dd Befehl, der kann bei unsachgemäßem Einsatz Datenverlust verursachen.)
Zur Verteidigung der günstigen Platten: Im normalen Büro oder Gamingbetrieb sollte sich das Ganze kaum auswirken. Aber jemand der mit großen Dateien arbeitet bzw. kopiert, für den schon.
Die SSDs der TLC/QLC Generationen haben einigen als SLC genutzten Write-Cache im Flash, der mit hoher Geschwindigkeit speichert. Schmeisst man mehr hinein, ohne dass dieser zwischendurch von der SSD weiterverarbeitet wurde, wirds langsam. Und dann gilt über'n Daumen: billig=langsam.
Wer also eine SSD sucht, auf die viele Daten ab Stück geschrieben werden sollen, sollte sich vorher bei Sites umsehen, die zum Test die SSD auch vollschreiben.
Danke für den Beitrag, könntest du solche Seiten empfehlen, bzw. auf welche Marken/Modelle man setzen kann wenn man durchgehende Schnelligkeit benötigt?
Weiterer Effekt: Bei manchen Typen ist die Grösse dieses SLC-Cache davon abhängig, wieviel von der Disk ungenutzt ist. Technisch naheliegend, bedeutet das aber, dass solche Performance vom vorherigen Füllungsgrad abhängen kann. Lies: Das Dings wird mit der Zeit langsamer.
schlecht gekühlt
Kingston und Samsung voll Alugehäuse, WD blue und Crucial BX500 Kunststoffdeckel, Intenso Vollplastik. Aber ich hab mal mit der Hand gefühlt, die werden alle nicht sonderlich warm, also es ist eine leichte Wärme spürbar am Gehäuse. Man müsste die Dinger aber mal aufmachen und schauen ob der Controllerchip heiß wird.
Also ich hab die Dinger komplett vollgeschrieben, und da war der
Schreibwert durchgehend konstant.
Das bezog sich auf jene Fälle, bei denen man nicht vollschreibt, sondern praxisnäher nur sowas wie 50 GB am Stück schreibt und danach Pause lässt. Da kann es dann passieren, dass es bei leerer Disk in den dann grossen SLC-Cache reinpasst, bei Jahre später gefüllter Disk aber nicht.
Wer regelmäßig ›praxisnah‹ 50GB am Stück schreibt,
der holt sich keine Billich-Willich Quadlevel-cell-SSD.
Wer nur mal gelegentlich 50GB am Stück schreibt,
den interessiert die in diesem Falls erzielte Transferrate nur extrem peripher.
Des Weiteren wurde mit dem ›dd‹ (in der Art wie vorgeschlagen) zusätzlich auch noch implizit die Performance des darunter liegenden Dateisystems getestet.
Für den Preis einer Server-SSD, die die geforderte Schreibrate kontinuierlich liefert, kriegt man auch 3-5 Consumer-SSDs.
Die in ein Raid zusammengefasst, und schon hast du deine >500Mb/sec Dauerschreibrate auch wenn der SLC-Cache erschöpft ist.
Bei dm-raid unter Linux darauf achten, dass "discard" funktioniert, siehe:
https://www.kernel.org/doc/html/latest/admin-guide/device-mapper/dm-raid.html#discard-support
Wer regelmäßig ›praxisnah‹ 50GB am Stück schreibt,
Ich schrieb nicht ohne Grund "näher", nicht "nah". ;-)
Des Weiteren wurde mit dem ›dd‹ (in der Art wie vorgeschlagen)
zusätzlich auch noch implizit die Performance des darunter liegenden
Dateisystems getestet.
Auf heutigen Rechnern im Rahmen der Leistung von SATA ist das als mögliche Bremse irrelevant, zumal die Problematik von Fragmentierung bei SSDs ausfällt. Da gilt es eher, den Einfluss von Caching auszuschliessen (iflag/oflag=...).
Für den Preis einer Server-SSD, die die geforderte Schreibrate
kontinuierlich liefert, kriegt man auch 3-5 Consumer-SSDs.
Die in ein Raid zusammengefasst, und schon hast du deine >500Mb/sec
Dauerschreibrate auch wenn der SLC-Cache erschöpft ist.
Eine QVO fällt auf ca. 80…90MB/s
Da bräuchte man schon 6+ dieser SSDs um SATAIII zu sättigen.
Edit:
Gerade noch gelesen
500Mb/sec
Ja, 500 Megabit pro Sekunde, das geht natürlich. ;-)
Bei dm-raid unter Linux darauf achten, dass "discard" funktioniert,
Obacht mit dm-raid!
dm-raid nutzt die RAID-Funktionen des Motherboards, das hat den Nachteil, dass es häufig nicht mehr funktioniert, wenn das Motherboard gewechselt wird (bzw gewechselt werden muss, z.B. bei Defekt.).
Besser ist es, mdadm zu nutzen, das macht ein RAID ohne Hardware-Support und ist bei den heutigen Prozessoren genauso schnell wie dm-raid.
Auf heutigen Rechnern im Rahmen der Leistung von SATA ist das als
mögliche Bremse irrelevant, zumal die Problematik von Fragmentierung bei
SSDs ausfällt. Da gilt es eher, den Einfluss von Caching auszuschliessen
Ich habe ja nur 24GiB RAM zur Verfügung, aber wenn ›dd‹ ferig meldet und trotzdem noch 23GiB geschrieben werden müssen, das ist dann wohl eher eine Schätzung als eine Messung.
Zumal man es ohne Aufwand ordentlich machen könnte.
Was bei Anwendern von Business-Workstations nicht einmal falsch sein muss. Wenn ein Tag Arbeit futsch ist, kann das teurer sein, als die zweite Disk. Natürlich ist das unabhängig vom Backup zu sehen.
Backups sind wichtig keine Frage, am besten macht man jeden Tag eins, ist ja innerhalb von Sekunden gemacht und kann verhindern dass Wochen an Daten verloren gehen, oder die die man investieren muss um den Schaden zu begrenzen.
warum /dev/null? wiederhole den Test mal mit /dev/urandom
Dann könnte unter Umständen urandom der Flaschenhals sein. Zufallsdaten sind recht teuer, auch mit Pseudo davor. /dev/null ist hingegen auch ein denkbar schlechter Kandidat: die Controller der SSDs sind heute auch nicht mehr blöde – wenn da ein Stapel Null kommt, dann wird gesammelt und effizienter hinterlegt, als wenn echte Daten kämen. Ich nutze da eine Datei in einem tmpfs, die im Vorfeld mit Daten aus urandom gefüttert wurde. Da ist natürlich RAM der limitierende Faktor – aber mal ehrlich: dieser Faktor ist auch im realen Betrieb relevant. Interessiert mich nicht, wenn das Laufwerk nach 50GB sequenziell geschriebenen Daten eine Pause zum Wegschreiben einlegt, wenn ich Programmiererkram mit vielen kleinen Files von insgesamt deutlich unter einem GB mache.
Und wenn man schon ›dd‹ für den Zweck hernimmt, dann gibt man ihm a) eine Blockgröße passend zum jeweiligen SSD mit (und zwar nicht die, die es via ›smartctl‹ meldet, sondern die aus dem Datenblatt) und b) schaltet man die Caches ab. Ansonsten nimmt man lieber ein dediziertes Benchmark-Tool her – die sind darauf ausgelegt, diese Anfänger-Fettnäpfchen nicht zu triggern.
Man kann auch ne große ISO Datei von der selben Platte oder der schnellsten Platte kopieren falls der SSD Controller die Nullen überlistet. Random ist wesentlich langsamer.
Also ich würde einfach auf ne externe SSD ein rsync Backup schreiben. Kann man auch inkrementell machen, dann hat man alle Änderungen an den Dateien bei minimalem Platzverbrauch. Hab da ein paar Scripte dazu geschrieben. Was könnte man machen um das Backup vor Ramsomware zu schützen? Ich denke abgesteckt offline, und noch irgendwie nen Schreibschutz reinmachen, also dann die Platte schreibgeschützt einhängen wenn man davon betroffen war.
Doch, natürlich. Die Spatzen pfeifen es von allen Dächern, an jedem Büro und Arbeitsplatz von Admins hängt der "Kein Backup, kein Mitleid"-Aufkleber von Heise, und die meisten Leute haben ihren Computer nicht erst seit gestern.
Und ehrlich: Wann hast Du Dein letztes BA gemacht?
Vor 48 Minuten, und in 12 Minuten wird das nächste erfolgen. rsnapshot(1) und systemd.timer(5) machen's möglich.
Man macht kein Backup, man richtet seine Systeme derart ein das sie
Backups machen. Automatisch.
Wenn man ganz sicher gehen will nimmt man ne interne und ne externe, die interne wird jedes mal automatisch mit cronjob abgeglichen und die externe macht man zur Sicherheit ab und zu mal falls Ransomware die interne backup Platte zerstört.
Mit der iso datei Schreibtechnik komm ich auf die gleichen Werte wie mit dd Null. Schon blöd wenn SSD Speicher dann mit der Zeit auf 50MB/s abfällt, ist ja langsamer als HDDs die schaffen so 60 120 180
Wenn man Daten schaufeln will muss man Zeit haben.
Backups sind wichtig keine Frage, am besten macht man jeden Tag eins,
Man macht kein Backup, man richtet seine Systeme derart ein das sie
Backups machen. Automagisch.
Das setzt aber voraus, dass sie permanent mit dem Backup-Medium verbunden sind. Ein Blitzschlag kann dann das Backup auch gleich mit zerstören. Es sei denn, das Backup-System steht an einem anderen Standort.
die Controller der SSDs sind heute auch
nicht mehr blöde – wenn da ein Stapel Null kommt, dann wird gesammelt
und effizienter hinterlegt, als wenn echte Daten kämen.
Das tun auch schon die Filesysteme. Siehe "sparse files".
Wenn man Daten schaufeln will muss man Zeit haben.
Oder die richtige SSD. Ich hatte als Backup-Medium für meine VMware-Images deshalb eine entsprechende USB-SSD ausgesucht. Die bei den Backups an die 400 MB/s abliefert.
Genau richtig, aber das muss man vorher wissen, die Rezessionen nehmen ja ihr Diskmark und denken die Werte sehen ja ähnlich aus wie bei den guten. Ne Hitachi 1TB HDD 3,5" 7200rmp an esata macht 150MB/s Durchschnitt.
Sind aber sehr selten bis nicht vorhanden. Ne 2,5Zoll 5400rpm Scorpio Blue HDD 320GB schafft 90MB/s. Trotzdem sind auch die langsamen SSDs wesentlich besser als die HDDs, zumindest was den Alltagsgebrauch angeht.
Find ich ja echt geil. Der Erste stellt fest dass die 2TB Platte nur 400GB hat und der Rest lässt nur Diskmark kurz laufen und spricht dann ne Kaufempfehlung aus...
Hier sieht man das das Diskmark die Intenso genauso wie die Samsung bewertet. Fazit, kein geeignetes Benchmarktool für Datenschaufler. Mein Benchmark aber sehr wohl. Unterschied Faktor 9, bzw. 900%. Kann man sich fragen ob da der günstige Preis gerechtfertigt ist. Wobei sich die CrucialBX schützend vor die Intenso stellt, sonst hätte ich gedacht die sind Schrott. Btw ist es mir aber lieber ich hab langsame Platten die zuverlässig sind als andersrum.
Wenn man ganz sicher gehen will nimmt man ne interne und ne externe, die
interne wird jedes mal automatisch mit cronjob abgeglichen und die
externe macht man zur Sicherheit ab und zu mal falls Ransomware die
interne backup Platte zerstört.
Techniker aus dem 20. Jahrhundert? Schon das 1. Backup liegt da, wo der Benutzer keine Schreib- und Leserechte hat und natürlich auf einem anderen Server/PC. Das 2. Backup liegt physisch an einem anderen Ort.
Das ist aber auch ein altes Schätzchen.
Hatte damals™ selbst 'ne 830 128GB (oder waren's 120?), die hatte aber deutlich mehr als 300MB/s geschrieben. Gut, hatte auch die doppelte Anzahl Kanäle.
Ich habe bei der Samsung nicht näher nach Zusammenhängen geforscht. Die Installation ist steinalt, Basis Ubuntu 11, und der Wert derart unwichtig, das es mir egal ist. Ist ein Videorekorder, viel mehr als die üblichen Logfiles landen da nicht.
Lesen tut sie mit gut 200 MB/s, das reicht dafür auch. Viel mehr wirds bei SATA II (3 Gb/s) sowieso nicht.
Der Test zeigt hier ne Schreibrate von 200MB, dann müsste das in über ner Minute fertig sein, hat aber 5Min gebraucht, und dann hat man die Schreibrate von 66MB/s die ich auch mit dd rausbekomme. Wenn man den Test länger laufen lässt, dann gleicht sich der Wert an.
Der Test zeigt hier ne Schreibrate von 200MB, dann müsste das in
über
ner Minute fertig sein, hat aber 5Min gebraucht, und dann hat man die
Schreibrate von 66MB/s die ich auch mit dd rausbekomme. Wenn man den
Test länger laufen lässt, dann gleicht sich der Wert an.
Ernsthaft?
LUKS?
Du testest die Komprimier-Geschwindigkeit deiner Verschlüsselung gegen die Geschwindigkeit der darunter liegenden Hardware?
Hier noch mal n Diskmark mit Intenso und die Platine. Das Gehäuse ist Vollplastik und evtl. 2013 prozudiert, die Platine evtl. 2015. Der Controller strengt sich an 40 Grad zu bekommen, ich denke das Gehäuse dafür ist in Ordnung.
Kingston und Samsung haben Vollalu. Crucial und WD zur Hälfte Alu andre Plastik.
LUKS?
Das macht tatsächlich keinen Unterschied ob Luks oder nicht. Das war bei nem Intel Atom schon nicht merkbar und bei nem i3-4170 mit Crypt Befehlssätzen erst recht nicht.
Für ultra sensitive Daten könnte trim bei luks ein security Problem darstellen. Bei mir ist es automatisch aktiviert, crypttab discard.
Das Problem ist dass der Leistungstest von Ubuntu scheinbar nicht so ganz akkurate Resultate liefert, z.B. hier 12MBx1000. sollte ja nach Resultaten 1Min 10sec dauern, hat aber 3Min gedauert. Deshalb ist der dd Bench bisher das beste was ich gefunden hab. Oder man kopiert ne riesen Datei und stoppt die Zeit. Außerdem kann dd die Platte ganz voll machen. Mit "f3 - Fight Flash Fraud" oder (!! badblocks -wvsb 4096 /dev/sdx !Zerstört die Daten) kann man kucken ob er Speicher intakt und vollständig ist.
Allein schon
deshalb, weil es dort, wo ich so etwas teste, oft keine GUI gibt.
Beispielsweise bonnie++ braucht auch kein GUI, ist aber im Gegensatz zu dd tatsächlich für Benchmarks entwickelt worden und dafür auch geeignet.
Wie oben schon geschrieben: man kann nicht voraussetzen, dass dd in der Defaultkonfiguration die tatsächlich erreichbare Geschwindigkeit des Datenträgers auch nutzt (z.B. wenn die genutzte Blockgröße nicht zum SSD passt, oder so), oder auch nur realistische Werte ausgibt (z.B. wird ohne explizites Syncen der Cache unterschlagen; oder I/O kann von was Anderem in Anspruch genommen werden, oder so). Es ist nunmal kein Benchmarktool.
bonnie++ ist für mich zu hart, ich kann mit den Zahlen (evtl. noch) nix anfangen, ich brauch MB/s beim Datenschaufeln und fertig.
Ich versteh auch nicht warum man so dämliche Angaben macht wie MiB Pippibytes per second, oder Papabuts per sonstnochwas. Z.B. Wlan oder Bluetooth. Wir haben auf unseren Geräten MB und nicht irgend was andres und unsere Uhr zeigt Sekunden. Wenn man den ganzen Firlefanz dann umrechnet und mit dem vergleicht was man gemessen hat, dann kann man die ganzen Angaben getrost in die Tonne kloppen. Vermutlich Marketing Verwirrungs Strategie damit der Kunde sich von irrelevanten Angaben zum Kauf von Blödsinn verleiten lässt. Man müsste einfach alle Produkte kaufen, dann alle testen und dann das beste behalten und den Rest zurückschicken, das wäre irgendwie die Antwort auf solch "transparentes" vermarkten.
Samsung hat nen ganzen ARM Prozessor oder Soc auf seiner SSD, also umfangreich, könnte Grund sein dass sich evtl. Bugs einschleichen, wie hier:
https://www.youtube.com/shorts/cy_BgJM7R58
Die Intenso benutzt halt nen einfachen spezialisierten Chip für die Aufgabe. Und Crucial nutzt für MX und BX sogar den gleichen. Und die andren Nutzen auch solche Art von Chip. Zu dem Samsung ARM find ich sonst gar nix.
Wir haben auf unseren Geräten MB und nicht irgend was andres
Und nun die Preisfrage: das MB auf deinen Geräten – ist das eins von früher™, mit 1024kB zu je 1024 Bytes? Oder ist das eins von heute®, mit einer Million Bytes pro Megabyte? Denn das ist der Grund für MiB und MB heute.
Ich versteh auch nicht warum man so dämliche Angaben macht wie MiB
Pippibytes per second, oder Papabuts per sonstnochwas.
Also gar ehrlich … damit hast du dich vollends disqualifiziert.
Aber noch einmal langsam.
Weil man gerne präzise sein möchte.
Weil man sonst:
im k/ki Bereich 2.40% Fehler hat,
im M/Mi Bereich 4.86% Fehler hat,
im G/Gi Bereich 7.37% Fehler hat,
im T/Ti Bereich 9.95% Fehler hat.
Und damit - völlig ohne Not - schlimmste Verwirrung und Fehler schafft.
Oder Megabit für Internetleitungen, der Browser gibt auch MB/s an. Eben man sollte sich auf eine Einheit einigen und die verwenden, anstatt alles mögliche. Meine Qualitfikation steht gar nicht zur Debatte, ich bin immer mein bestes selbst und das muss reichen ;-D
man sollte sich auf eine Einheit einigen und die verwenden, anstatt
alles mögliche.
Man schreibt das korrekte Präfix einfach dazu.
Dann wissen Viele was genau (im Sinne von exakt) gemeint ist.
Und die binäre Präfixe sind mittlerweile so alt und etabliert, das man ihr Alter mit der Radiokarbondatierung messen kann.
Die traditionell auf eine eigenständige Begriffswelt bestehende TK-Branche verwendet keine Bytes, sondern Octets, weshalb in diesem Kontext MB/s eigentlich eindeutig ist.
Vorausgesetzt, man weiss, ob man sich mit einem TKler oder einem ITler unterhält. ;-)
Dass SSDs ’nen Cache haben, ist kein zu großes Geheimnis. Tatsächlich steht’s gar in deren Doku – zusammen mit Zahlen und Einheiten. Vielleicht war das der Grund, warum dem TE das bislang nicht klar war? Zahlen und Einheiten?
Wer ständig Files >50GB umherschiebt, muss halt etwas tiefer in die Tasche greifen und sich ein entsprechendes Gerät holen. Für alle Anderen sind sowieso eher IOPS und so von Interesse.
Der Controller der Intenso hat keinen Cache, steht im Datenblatt und auf
der PCB ist nur noch der Nand Klotz, also kein Cache. Und wenn, nach 8GB
oder 25GB oder so ist der auch nicht mehr in der Lage was zu reissen.
Außerdem ist es völlig egal ob da ein Cache ist oder nicht, man testet
das Teil ja nicht mit dem Cache, weil es dann im Alltag ohne den Cache
arbeiten würde, macht also keinen Sinn überhaupt den Cache dafür
verantwortlich zu machen dass die Messergebnisse nix taugen sollten.
Außerdem ist es völlig egal ob da ein Cache ist oder nicht, man testet
das Teil ja nicht mit dem Cache, weil es dann im Alltag ohne den Cache
arbeiten würde, macht also keinen Sinn überhaupt den Cache dafür
verantwortlich zu machen dass die Messergebnisse nix taugen sollten.
Ja gut – dass du nicht wirklich Ahnung von dem hast, das du (nicht nur) hier die ganze Zeit vor dich hinschreibst, ist auch vorher schon bekannt gewesen.
Also es ist so, dass die Intenso deswegen so langsam ist weil nur ein Chip arbeitet. Wenn eine DRam less schneller arbeiten soll, dann braucht sie mehr Chips. Weil die können dann parallel beschrieben werden und jeder Chip hat eine begrenzte Bandbreite die sein Interface zum Controller benutzen kann. Scheinbar hat der 3D Nand ca. ne Bandbreite von 30MB/s, wenn es zwei Chips wären wären es 60MB/s. Das Teil schreibt ja erst mal mit so 400MB/s fällt dann auf 50 und erreicht auch schon mal unter 10. Scheint irgendwie ganz schön vielfältig aufgebaut zu sein der eine Nand Chip. Jetzt hat Intenso noch andre Dram less SSDs, die da heißen: High - Top - Performace. Ich schätze mal da werden dann schnellere Chips und mehrere eingebaut. Wäre mal interessant was in der Performance steckt, die ist ja preislich gleich mit den Marken SSDs. Ob jetzt die Intenso schlechter ist als die Marken SSDs kann ich nicht beurteilen. Die "technischen" Angaben im Produkt Flyer sagen nichts aus, oder dass kein Unterschied zwischen den Versionen besteht.
Bei den unbekannten Herstellern aus China, handelt es sich wohl um die gleiche Qualität, oder irgendwas zusammengebasteltes aus der Reisekiste mit Testboards. Oder gleich um Fakes mit eingebautem SD Kartenleser mit fake SD Karte. Damit wird der Markt gerade überschwemmt, weil die Dinger sind n paar Cent wert und werden aber für gutes Geld verkauft. Ist Betrug. Und sollte man wirklich so ein Ding als Backup verwenden sind alle Daten futsch, weil der Controller die Kapazität nur vortäuscht und den Inhalt der SD Karte immer wieder neu überschreibt.
Die Rolle des DRAM bei SATA SSDs liegt nicht darin, Nutzdaten zu speichern, sondern Metadaten. Daten, die beschreiben, was an welcher Stelle im Flash liegt.
Und ehrlich: Wann hast Du Dein letztes BA gemacht?
Bei mir schiebt es ein Script mit rsync auf einen lokalen Server und auf einen entfernten den ich in meinem Sommerhaus stehen haben, täglich, fünf Uhr - mit einer 7/4/12 Strategie:
1
---------------------------------------
2
Start-Zeit: Sun Oct 15 05:00:01 2023
3
Number of files: 646,953 (reg: 535,406, dir: 65,957, link: 45,228, dev: 6, special: 356)
dass dein Schreibmenge-zu-Ahnungs-Verhältnis gigantisch ist.
Schön gesagt großer Meister. Aber lebst du denn hinterm Mond? Ist dir noch nicht aufgefallen dass es heutzutage völlig normal ist dass man mit Unwissen genauso weit kommt? Nehmen wir die Werbung, da wird der allergrößte Unfug versprochen. Oder die Rechtsparteien. Viele neue Möglichkeiten, muss man nur die richtige Perspektive wählen um nicht zu verzweifeln sondern sich daran zu erfreuen.
sondern Metadaten
Genau, deswegen wäre eine SSD mit Dram und langsamen Chip auch sehr langsam, aber eine SSD ohne Dram und schnellen Chips schnell. Ich schätze mal den Dram merkt man gar nicht, der bringt evtl. ein paar Millisekunden wenn viele Zugriffe gleichzeitig erfolgen, durch z.B. ein umfangreiches Programm.
Ich würde mittlerweile sagen dass Dram zusätzliche Bauteile bedeutet, was die Ausfallwahrscheinlichkeit erhöhen könnte und vermutlich auch tut. Vielleicht machen die Hersteller nur deshalb Dram in ihre Geräte weil die Konsumenten glauben das sei das A und O. Ich als schlauer User setze nicht auf Dram und wenn man langsamen Nand hat dann kann man viel bewusster Daten übertagen und hat mehr ein Blick ins Geschehen, man muss die Dinge nur perspektivisch richtig beurteilen.
Für 5MB/s könnte man auch "rsync -av --bwlimit=5000" benutzen. Oder aber mit FreeFileSync oder Robocopy
Was mir auffällt ist, dass sowohl "SATA Physical Error Count", als auch "Bad Block Count" (der sogar zweimal vorkommt) bei beiden exakt gleich ist - und auch sehr hoch für die kurze Laufzeit. Daher sind es vermutlich nicht die tatsächlichen Werte.
Das Problem ist bei SMART generell, dass die genaue Bedeutung der Werte nicht standardisiert ist. Da kann sich jeder Hersteller austoben.
Was mir auffällt ist, dass sowohl "SATA Physical Error Count", als auch
"Bad Block Count" (der sogar zweimal vorkommt) bei beiden exakt gleich
ist - und auch sehr hoch für die kurze Laufzeit.
Das Problem ist bei SMART generell, dass die genaue Bedeutung der Werte
nicht standardisiert ist.
Die RAW-Werte sind ohne Aussage, die interpretierten Werte sind von Bedeutung.
Wenn man smartctl direkt nutzt, gibt es eine Information aus, ob das betreffende Gerät in der Datenbank ist, oder nicht. Wenn ja, kann man davon ausgehen, dass die interpretierten Werte passen. Wenn nein, kann’s gar vorkommen, dass Felder völlig falsch zugeordnet werden.
Gut möglich, dass das beim TE der Fall ist – aber ich wage nicht zu bitten, dass er da mal nachschaut. So, wie er hier schreibt, ist zu befürchten, dass er das auswürfelt und dann als unumstößliche Tatsache hier hinstellt …
Wenn du auf
Attribute 161 - Valid Spare Block Count
raus willst: sieht gut aus. SMART Werte sind gewöhnungsbedürftig.
"Contains the remaining spare block percentage available on a solid state device. The percentage starts at 100% and will typically decrease to 0% during use. If this attribute reaches 0%, the solid state device becomes read-only. The raw value of thisattribute may contain the actual number of spare blocks."
Intenso Top ist nicht in der Smartctl Database. Evtl. weil es kein Hersteller Tool gibt. Ist die Frage ob die Labels von der Platte oder von smartctl kommen. Wenn die falsch zugeordnet werden können dann wäre das sehr schlecht, eigentlich sollten die labels von der platte selbst kommen, das würde Sinn machen. Crystal Disk Info liest die Werte fast gar nicht aus. Der Short Test und Extendet Test funktionieren beide.
Das ist sehr ungünstig. Dann machen die Smart Werte bei der Intenso ja gar keinen Sinn, weil es keine Herstellersoftware gibt wo die Zuordnung stimmt. Bei den andren Disks gibt Crystal Disk Mark auch gleiches oder kompletten Unfug raus, wie bei der crucial alles auf 100, nur temp auf 74 bei kalter Platte.
Deswegen kauft man keine "Intenso", "A-Data", "SimSung", "EasternDigital", usw. Da hast du auch keine Garantie, dass zwei äußerlich gleiche SSDs das gleiche Innenleben (und damit vergleichbare SMART-Werte) haben.
Die 2,50€ Aufpreis für eine Marken-SSD, wo ein Datenblatt existiert, in dem auch festgehalten ist welcher Controller darauf werkelt, sollten es einem Wert sein.
Aha, jetzt verstehe das was bei smartctl unter Worst steht, gibt Crystal Disk Info an. Und die Labels können vertauscht sein weil die Software das irgendwie interpretieren muss. Das heißt Threoshold und Worst kommen von der Platte, die Labels werden interpretiert und wenn die ssd nicht in der Datenbank ist können die auch falsch interpretiert sein. Den Gesamtzustand kommt auch vom Controller bzw. die Firmware darauf und entspricht in etwa dem Worst Wert und auf die Werte kann man sich verlassen. Normalerweise wenn smartactl kein Label zuordnen kann, steht da Unknown Attribute.
Und die Labels können vertauscht sein weil die Software
das irgendwie interpretieren muss.
Die IDs (Hex/dez) sind ziemlich klar, sofern ein Label dabei steht, das nicht auf "Vendor" oder "keine Ahnung" lautet. Aber nicht jede Disk hat den gleichen Satz an unterstützten IDs.
Deswegen kauft man keine "Intenso", "A-Data", "SimSung",
"EasternDigital", usw.
Dem kann ich mich nur anschließen. SSDs von richtigen Herstellern sind so günstig geworden, daß es wirklich nicht nötig ist, auf "RAMsch"* zurückzugreifen
*) hatte die c't mal für Arbeitsspeicher aus vergleichbaren Quellen verwendet. 3rd-Party-Assemblierer heißt so etwas neudeutsch. Firmen, die auf dem Spotmarkt gerade verfügbare Speicherchips kaufen, diese mit Phantasiebeschriftungen versehen und auf eigene Platinen löten. Weder ist damit sichergestellt, daß zwei Speichermodule die gleichen Speicherbausteine verwenden, noch, daß sie irgendeine Spezifikation zuverlässig einhalten können.
Meinst du Samsung? Ich frag mich auch ob die nicht gehyped werden. Gut sie sind schnell und die Technik scheint frisch entwickelt, aber es gibt so Sachen dass in den Amazon Rezessionen steht dass der Support von Samsung die Garantie abschmettert . Z.B. wenn die ssd in einem externen Gehäuse stirbt dann ist das die Schuld vom User, da die Platte angeblich dort nix zu suchen hat.
aber es gibt so Sachen dass in den Amazon Rezessionen steht dass der
Support von Samsung die Garantie abschmettert . Z.B. wenn die ssd in
einem externen Gehäuse stirbt dann ist das die Schuld vom User, da die
Platte angeblich dort nix zu suchen hat.
Ich lese da nur, dass sie eine externe Nutzung nicht empfehlen (warum auch immer), aber nix davon, dass sie die Garantie "abgeschmettert" hätten.
Ein wenig schon. Samsung hat den wohl teuersten Namen. Bei internen SATA SSDs nehme ich deshalb gerne Crucial.
Wenn ein leidlich renommierter Name dran steht, erhöht es die Chancen, dass man das kriegt, was durch die Reviews gezogen wurde. Manchmal nicht, wie das z.B. bei WD schon vorkam - dann gibts hässliche Publicity, was dem Ruf des Herstellers schadet. Sowas ist eine Art Regulativ.
Die QVO war indes schon in den Reviews eine üble und kritisierte Schnecke. Dass die billigste Samsung SSD auch die schlechtete ist, was die Performance angeht, sollte nicht überraschen. QLC hat Nachteile und ist für Aufgaben vorgesehen, bei denen das nicht wichtig ist.
Nein, ich meine die Chinesischen Fake-Marken, die mit identischer Aufmachung, aber manchmal leicht abgewandelten Markennamen Ramsch verkaufen. Gibt da auch welche in WD, Kingston, ...-Aufmachung.
Original Samsung ist schon OK, wenn auch Preis/Leistungsmäßig nicht top.
Die QVO war indes schon in den Reviews eine üble und kritisierte
Schnecke.
Was es halt für Tester gibt.
Wie Realitätsnah halt die Tester sind.
Im echten Leben:
Beim Lesen und normalen Nutzen:
durchgängig maximale SATA III Geschwindigkeit.
Beim Schreiben mehrerer DVD-ISOS direkt nacheinander:
durchgängig maximale SATA III Geschwindigkeit.
Beim Schreiben mehrerer großer HD-Pr0ns direkt nacheinander:
durchgängig maximale SATA III Geschwindigkeit.
Also für normale PC-Benutzer zu 99.99% kein Unterschied zu TLC,MLC,SLC.
Der Vollständigkeit halber:
Beim Klonen einer alten Festplatte oder SSD auf eine QVO:
Nach den ersten 90GB sinkt Schreibgeschwindigkeit temporär auf Festplattenniveau herab.
Tests haben die Aufgabe, verschiedene Parameter zu testen, darunter selbstverständlich auch Schreibvorgänge in grossem Umfang. Dem Anwender das Denken völlig abnehmen sollte sie nicht.
Also für normale PC-Benutzer zu 99.99% kein Unterschied zu TLC,MLC,SLC.
Etwa so? 99.99% der PC-Benutzer machen sowieso keine Backups. ;-)
Auf die Idee, eine grosse externe QVO als Backup-Medium zu nutzen, kann man schon kommen. Wenn man diese Daten nicht anschliessend ein halbes Jahr im Schrank vergammeln lässt.
Also für normale PC-Benutzer zu 99.99% kein Unterschied zu TLC,MLC,SLC.
Etwa so? 99.99% der PC-Benutzer machen keine Backups. ;-)
Eher: 99,99% der PC-Nutzer machen nicht jeden Tag ein Komplettbackup.
Ich mache meine täglichen Backups auf ein externes SSD. Das sind im Schnitt einige hundert MB; wenn mal neues Filmmaterial oder ein neues Projekt dazugekommen ist, sind’s auch mal eine Handvoll GB. Da ist‘s in der Tat einigermaßen egal, dass das SSD nach einigen ’zig GB einbrechen würde.
Ich mache meine täglichen Backups auf ein externes SSD. Das sind im
Schnitt einige hundert MB; wenn mal neues Filmmaterial oder ein neues
Projekt dazugekommen ist, sind’s auch mal eine Handvoll GB. Da ist‘s in
der Tat einigermaßen egal, dass das SSD nach einigen ’zig GB einbrechen
würde.
Etwa so? 99.99% der PC-Benutzer machen sowieso keine Backups. ;-)
Die immer schlimmer grassierende Seuche nach immer höheren, völlig unnötigen und in den meisten Fällen gar nicht genutzten Maximalwerten zu urteilen, ist auch hier schmerzlich bemerkbar.
Nochmal, für das Gros der normalen Anwenderinnen:innen:innen ist keinerlei Unterschied spürbar. Noch nicht einmal messbar, wenn sie es denn überhaupt täten.
Ach ja richtig, die Teile, die hat garantiert keine 8TB, die schickt die Daten die man drauf speichert in die Hölle. Dafür gibt es Testprogramme z.B. f3 Fight Flash Fraud
Was Samsung betrifft, die geben ihre TBW Werte von der 4TB Variante für die ganze 870Evo Reihe an was irreführend ist, siehe screehshot. Dass das im Kleingedruckten dann revidiert wird interessiert mich nicht. Transcent hingegen gibt sogar an ob in der SSD Dram drin ist oder nicht, das ist löblich.
aber nix davon, dass sie die Garantie "abgeschmettert"
Stimmt, aber warum sonst würde Samsung so etwas sagen? Es ist doch gleich an welchem Board der Sata Anschluss hängt, Sata Anschluss ist Sata Anschluss. Deshalb kann ich mir das nur so erklären, dass das ein Vorwand ist um die Garantie abzuschmettern.
Die Frage ist natürlich ob der Stromanschluss ausreicht, bei den HDDs war das ja so dass die 2,5 Zoll Modelle einen Headcrash haben konnten wenn der Strom nicht gereicht hat. Wenn ich zuviele 2,5 Zoll HDDs (zwei Stück) an nen passiven USB Hub häng dann hör ich wie die Platte die Initialisierung unterbricht und vielleicht gar nicht anläuft. 2,5 Zoll HDDs und SSDs brauchen 2Watt, ssd eher weniger, während 3,5 Zoll HDDs 7 Watt brauchen und die externen Laufwerke eine extra Stromversorgung haben. Vielleicht sind energiehungrige SSDs mit Dram da auch anfällig?
Es ist doch
gleich an welchem Board der Sata Anschluss hängt, Sata Anschluss ist
Sata Anschluss.
Nicht ganz. Im PC wird die SSD sauber "heruntergefahren", während sie noch Strom hat. Im USB-Gehäuse ist beim Ausstöpseln sofort der Strom weg, auch wenn der SSD-Controller gerade noch beschäftigt war.
Hat einen Grund warum in den Smart-Werten die "sauberen" und "unsauberen" Shutdowns getrennt mitgezählt werden.
Eigentlich sollte es der SSD nichts ausmachen, den Strom zu verlieren. Entweder macht der Controller seine Verwaltungstasks mit "Journaling", oder die SSD hat intern Supercaps zum puffern, das war aber eher zur SSD-Anfangszeit üblich.
aber nix davon, dass sie die Garantie "abgeschmettert"
Stimmt, aber warum sonst würde Samsung so etwas sagen?
Damit es das nächste mal nicht wieder passiert?
Wir wissen schlicht nicht, was im Bezug auf die Garantie passiert ist. Ich halte mich da an das, was dort geschrieben steht und nicht an eigene Mutmaßungen.
Es ist doch gleich an welchem Board der Sata Anschluss hängt, Sata
Anschluss ist Sata Anschluss. Deshalb kann ich mir das nur so erklären,
dass das ein Vorwand ist um die Garantie abzuschmettern.
Vielleicht sind energiehungrige SSDs mit Dram da auch anfällig?
Das wäre jetzt auch das einzige, was ich mir vorstellen könnte. Vielleicht reichen die 500 mA eines USB2-Ports nicht immer aus, oder durch die dünnen Käbelchen geht zu viel Spannung verloren, und die SSD bekommt Probleme, weil die Spannung gerade mitten im Schreibvorgang, wenn vermutlich am meisten Strom benötigt wird, immer wieder einbricht.
Ubuntu hat hierfür die Unmount Knöpfe, die aber nicht funktionieren, man muss im Terminal sync eingeben und warten bis die letzte Große Datei fertig geschrieben hat und darf erst dann abziehen. Sonst gibts Datenverlust.
Das statische Wear Leveling hat kein Problem damit wenn der Strom weg ist, weil erst wenn die Daten fertig geschrieben wurden werden sie erst Bestandteil des Dateisystems.
Spannung gerade mitten im Schreibvorgang
Das könnte sein, externe HDDs haben ja beim Start akustisch reagiert, aber SSD sollte erst im Einsatz Probleme bekommen. Leider gibts dazu auch kaum Infos, hab bisher nix dazu gefunden.
Nicht ganz. Im PC wird die SSD sauber "heruntergefahren", während sie
noch Strom hat.
Wie kommst Du auf diese lustige Idee? Macht das das Festplattenparkprogramm?
Im USB-Gehäuse ist beim Ausstöpseln sofort der Strom
weg, auch wenn der SSD-Controller gerade noch beschäftigt war.
Das ist bei PCs bei Abschalten auch der Fall. Nur vergeht i.d.R. zwischen dem Einstellen sämtlicher Schreibzugriffe durchs OS und Abschalten der Versorgungsspannung einfach immer eine gewisse Zeit, die dem SSD-Controller genügt.
Im USB-Gehäuse ist das auch kein Problem, sofern man das USB-Kabel nicht sofort rausreißt, sobald der "datei kopieren"-Dialog von Windows behauptet, fertig zu sein.
Wenn man da ein, zwei Sekunden lang innehält, oder gar sich bequemt, auf etwaige Aktivitäts-LEDs zu blicken, gibt es keine Probleme.
Anderer Grund könnte sein, dass bei (Nicht-UAS) USB-Gehäusen kein TRIM funktioniert, und das Wear-Leveling deswegen wesentlich schlechter arbeitet => TBW werden nicht erreicht.
Ubuntu hat hierfür die Unmount Knöpfe, die aber nicht funktionieren, man
muss im Terminal sync eingeben und warten bis die letzte Große Datei
fertig geschrieben hat und darf erst dann abziehen. Sonst gibts
Datenverlust.
Ein ›umount‹ führt IMMER ein ›sync‹ zuvor durch.
Wenn Ubuntu das Ende desselben nicht sauber abwartet, dann werden sie letztendlich nur ihrer Jahrzehnte alten Tradition der gnadenlosen Verschlimmbesserung gerecht.
Nicht ganz. Im PC wird die SSD sauber "heruntergefahren", während sie
noch Strom hat.
Wie kommst Du auf diese lustige Idee? Macht das das
Festplattenparkprogramm?
Das macht der Treiber. Über die SMART-Daten kann man bei Festplatten abfragen, wie oft sie einen Not-Parkvorgang durchführen mussten, weil die Versorgung ohne vorheriges Parken getrennt wurde. Bei den SSDs gibt es auch was vergleichbares. smartctl zeigt es mir dort als "Unsafe Shutdowns" an.
m PC wird die SSD sauber "heruntergefahren", während sie
noch Strom hat. Im USB-Gehäuse ist beim Ausstöpseln sofort der Strom
weg, auch wenn der SSD-Controller gerade noch beschäftigt war.
Deshalb sollte man vor dem Ausstecken das Laufwerk möglichst immer unmounten oder "sicher entfernen", oder wie auch immer es beim jeweiligen System heißt. Dann bekommt es nämlich auch vorher das entsprechende Kommando gesendet.
Im USB-Gehäuse ist beim Ausstöpseln sofort der Strom
weg, auch wenn der SSD-Controller gerade noch beschäftigt war.
Das ist bei PCs bei Abschalten auch der Fall. Nur vergeht i.d.R.
zwischen dem Einstellen sämtlicher Schreibzugriffe durchs OS und
Abschalten der Versorgungsspannung einfach immer eine gewisse Zeit, die
dem SSD-Controller genügt.
Nein, der Strom ist nicht einfach weg, sondern bei Runterfahren bekommt das Laufwerk ein Park-Kommando gesendet. Es weiß also vorher, dass gleich der Strom weg sein wird.
Wenn Ubuntu das Ende desselben nicht sauber abwartet
Hatte damit mal Probleme, weiß nicht ob das heute immer noch so ist, ich benutze immer vorsichtshalber den terminal sync command.
Was den Stromverbrauch angeht, hab mal nachgemessen:
Maximaler Strom für externe USB Laufwerke an USB 2.0 Anschluss gemessen mit USB Power Meter (50MB/s):
Intenso SSD (ohne Dram) Schreiben 220mA = 1Watt
HGST 2,5"HDD 0.7A Start und Schreiben
WD BLUE SSD (mit Dram) 0,45A Start und Schreiben
Maximaler Strom für BX500 (ohne Dram) und WD BLUE (mit Dram) intern (Stromzange an 2 schwarze Kabel 170MB/s):
270mA Schreiben und 400mA Schreiben
Könnte sein dass ne Samsung Evo 870 mit voller USB 3 Geschwindigkeit evtl. 1A zieht, kann ich aber nur vermuten, evtl, könnte mal jemand nachmessen. Interessant wäre auch was passiert wenn man auf ssd oder stick schreibt und der strom wird immer weniger bis das Gerät aussetzt.
Wikipedia verrät:
Bei USB 2.0 ist die maximale Stromstärke auf 500 mA begrenzt, weswegen einige Hersteller externer Festplatten Y-Kabel mitliefern, mit dem der Strom eines zweiten USB-Ports genutzt werden kann. Mit USB 3.0 wurde die Stromstärke auf 900 mA erhöht, mit der praktisch jede 2,5-Zoll-Festplatte betrieben werden kann.
# time $(dd if=/dev/shm/BIG_FILE_${i}.BIN of=/mnt/ssd_under_test/file_${i}_${k} bs=1M count=5000; sync)
12
done
13
done
Weil:
Nicht NULL-Daten schreiben, weil manche Controller das Erkennen
und es optimieren.
Erzeuge Dir Files via /dev/urandom mit zufälligen Daten!
Lesen aus dem RAM und nicht von einer anderen Disk/SSD, damit Du
nicht die Performance dieser Quell-Disk/SSD in Spiel bringst.
Schneller als aus dem RAM kannst Du nicht Lesen!
Den auskommentierten dd Befehl musst Du noch aktivieren.
Ist nur zur Sicherheit, damit jemand nicht gleich loslegt,
ohne zu wissen was er tut.
Das echo Kommando zeigt aber wie der Ablauf des Skripts ist.
Möchte man auf ein externes Netzteil verzichten, sollte man beachten, dass das USB-Kabel nicht zu lang gewählt ist, da sonst der Widerstand des Kabels dazu führen kann, dass die Festplatte nicht ausreichend Strom erhält.
https://www.hardwareschotte.de/externe-festplatten
Und zu viel Strom zieht? Gute Systeme haben ein Stromüberwachung auf den USB-Ports und schalten dann den Port ab. Hatte ich zumindest vor längerer Zeit auch konkret erlebt. Im Zeitalter häufiger mindestens zeitweiliger Überlastung durch externe DVD/HDD sind die heute aber wohl recht tolerant.
Umgekehrt müssen SSDs eine Stromüberwachung und -Anpassung enthalten, weil sie meist an verschiedenen Arten von Stöpseln hängen dürfen. Ob USB-A 2.0, USB-A 3.x, USB-C ohne und mit Leistungs-Signalisierung...
Wikipedia verrät:
Bei USB 2.0 ist die maximale Stromstärke auf 500 mA begrenzt, weswegen
einige Hersteller externer Festplatten Y-Kabel mitliefern, mit dem der
Strom eines zweiten USB-Ports genutzt werden kann.
Was in der Regel aber auch nicht konform ist, weil die 500 mA nur dann gelten, wenn das Gerät das vorher vom Port angefordert hat. Das machen sie aber auf dem zweiten Port in der Regel nicht. Damit dürfen aus diesem aber nur maximal 100 mA gezogen werden. Die Ports sind aber im Kabel gerne einfach parallel geschaltet, und man kümmert sich nicht darum, wie viel Strom aus welchem Port kommt.
Hatte damit mal Probleme, weiß nicht ob das heute immer noch so ist, ich
benutze immer vorsichtshalber den terminal sync command.
sync ist nicht ausreichend. Direkt nach sync sind die Puffer geflusht, aber 1ms später kann bereits wieder ein Schreibvorgang stattfinden. Wichtig ist ein zusätzliches umount.
Hab mir so nen USB Kabeltester gebaut, mit 3 Ohm, R=U/I = 1,66A Strom, wenn das ein USB Kabel liefert dann ist es gut zum Laden, aber manche schaffen nur 0,3A wegen schlechter Qualität. Aber hiermit hab ich mal meine USB Ports durchgetestet, ist ein H81Plus mit USB3.1gen1
https://usbstelle.de/wie-viel-ampere-hat-ein-usb-port/
Passiver USB 3 Hub liefert 1,4A, USB2.0 an Verlängerung 1,5A, ein 2.0 Hub den ich direkt ans Pc Netzteil angeschlossen hab bringt 1,6A. USB Ladegerät mit 2A liefert 1,6A.
Also alles gut der Strom scheint bereitwillig zu fließen. Scheinbar gibt es bei dem Thema keine Probleme, sonst würden die externen Gehäuse nicht so gut gehen, oder aber die Leute haben keine Ahnung und können bei Fehlern nicht darauf schließen.
Jetzt müsste man mal in eine USB Verlängerung den Widerstand erhöhen und schauen wie ein Testgerät SSD reagiert.
Also wenn die Platte nicht in der database ist können Werte scheinbar falsch zugeordnet werden, wie bei pny hier im Bild. Temperature wird wohl SSD life left sein. Im Bild oben Smartctl unten Windows Software von pny.
Bei den beiden Intenso SSD dürfte Bad Block count auch SSD life left sein. Frag mich was der 5.050 Wert sein könnte der bei allen 4 Intensos gleich ist. Die 240er haben übrigens 4 Nands aufm Board.
Schreibt längere Zeit mit 400MB/s fällt dann sehr lange Zeit auf 80MB/s bis nur noch mit 30MB/s geschrieben wird. Konnte die Platte mit 80 MB vollschreiben die letzten wurden mit 30MB geschrieben, dann gelöscht und dann neu Beschreiben gings mit 30MB weiter.
Kingston hat die unaussagekräftigste Smart Seite die man sich vorstellen kann in der Windows Software. Bei allen Platten ist aber immer die SmartCTL Software am ausführlichsten.
Nach nem Format ist die SSD wieder so schnell wie am Anfang, 400MB/s bis 80GB, den ganzen rest so 80MB/s bis zu den letzten 10GB oder so mit 30MB/s. Aber ohne Format bleibt sie nach dem Löschen aller Dateien bei 30MB/s. Intenso high 240 an USB. Dann funktioniert wohl Trim über den USB Controller nicht.
Bei verschlüsselten Festplatten soll der auch nicht funktionieren, wohl aber Garbage Collection
ABER man kann Trim manuell ausführen, einfach sudo fstrim /folder/disk, dauert n paar Sekunden und die SSD surrt wieder fröhlich mit 400MB/s. Schon komisch, andererseits könnte man so auch den Cache Nand schonen und auf Speed verzichten. Ein Sabrent Gehäuse unterstützt den Befehl nicht, ein Inateck schon.
für sabrent mit jms576 ist es die Zeile dazu:
ACTION=="add|change", ATTRS{idVendor}=="152d", ATTRS{idProduct}=="0583", SUBSYSTEM=="scsi_disk", ATTR{provisioning_mode}="unmap"
USB Luks Trim aktivieren:
sudo cryptsetup --allow-discards --persistent refresh luks-mapper-volume
sudo fstrim -av /media/user/volume
