Test Samsung 850 Evo 2 TB im Test: Günstiger SSD-Riese mit Leistung auf Pro-Niveau

@Holt
trimcheck unterstützt exFAT nicht. Darum habe ich auf NTFS formatiert und trimcheck sagt "CONCLUSION:TRIM appears to be WORKING!".

Aber ich weiß nicht, wie lange braucht TRIM für z.b. über 600GB aus versch. Computer als Backup (gelöscht oder übergeschrieben).
 
Zumindest ist nun abzusehen das sich in dem bereich was tut. Hat ja lange genug Stagniert.

2 TB sind dann echt schon brauchbare Größen. Damit kann man im Laptop echt was anfangen.

Was ist die Größe bei 2.5 HDD 2TB?
 
Zuletzt bearbeitet:
Zuletzt bearbeitet:
@Redaktion: Die Überschrift ist irreführend und schlichtweg falsch - BILD Niveau sozusagen
Auch die Haltbarkeit einer SSD ist ein Leistungskriterium und die ist bei den EVO definitiv schlechter als bei den Pro Modellen
 
Nein die Überschrift passt, denn in der Überschrift ist doch von Leistung und nicht von Haltbarkeit die Rede. Außerdem sind die NANDs der 850 Evo mit 3000P/E Zyklen spezifiziert, mehr als die planaren NANDs mancher anderer aktueller SSDs und ein Heimanwender bekommt die NANDs bei normalem Gebraucht nicht kaputt. Selbst Profis nutzen bei vielen Storages nur bis zu 0,1 DWPD, die Studie finde ich aber gerade nicht.

Die Bedenken um die Haltbarkeit von NANDs sind jedenfalls beim Heimanwendern total unnötig, da geht vorher was anderes kaputt, denn ewig hält HW nicht und eine SSD besteht aus mehr als nur den NANDs.
 
Holt schrieb:
Nein die Überschrift passt, denn in der Überschrift ist doch von Leistung und nicht von Haltbarkeit die Rede. Außerdem sind die NANDs der 850 Evo mit 3000P/E Zyklen spezifiziert, mehr als die planaren NANDs mancher anderer aktueller SSDs und ein Heimanwender bekommt die NANDs bei normalem Gebraucht nicht kaputt. Selbst Profis nutzen bei vielen Storages nur bis zu 0,1 DWPD, die Studie finde ich aber gerade nicht. Die Bedenken um die Haltbarkeit von NANDs sind jedenfalls beim Heimanwendern total unnötig, da geht vorher was anderes kaputt, denn ewig hält HW nicht und eine SSD besteht aus mehr als nur den NANDs.
Na was du meinst ist Übertragungsgeschwindigkeit/Performance da gibt's keinen relevanten Unterschied.
Die Haltbarkeit ist bei mir ein Leistungskriterium und die Haltbarkeit ist für viele Privatanwender eher unwichtig, da stimme ich zu. Meine Boot SSD's haben nach 3 Jahren die 10TB bei weitem nicht erreicht, was aber daran liegt dass ich TEMP auf HD bzw. eine weiterer SSD schicke. Eine zweite SSD die als TEMP und für Photoshop herhalten muss, bekommt aber schon einiges ab.. (leider nicxht exakt feststellbar da die Transcend 370 keine entsprechenden SMART Wert ausgibt). ansonsten Haltbarkeit: 840EVO / BASIC lässt grüßen - nie wieder Samsung, das Samsung Handy reicht ;-)
BTW: Meine Plextor M3 im Daddel PC, der jeden Tag mehrere Stunden läuft, hat gerade mal 3,55TBW in knapp 3 Jahren, aber nur weil TEMP auf eine HD geht.
 
Sysworker, ich bin ganz auf Deiner Seite. Wobei ich mal vermuten will, TLC mit 40 Nanometer Strukturbreite wird schon halten. Aber "wird schon" ist mir nicht gut genug. Das will ich gar nicht ausprobieren. Für die Hälfte aller PC-Besitzer sind 256GB intern völlig ausreichend, und da kommt es mir auf 30€ mehr nicht an.

Das mit der "Haltbarkeit" kann ein Werbetrick sein. 3000 Zyklen ist ein Durchschnittswert über die komplette SSD, bis sie ganz kaputt ist. Dabei können - und dürfen nach Ansicht der PR-Abteilung - aber auch schon einige Speicherzellen nach 30 Zyklen ausfallen, und wenn wichtige Daten oder das System oder die Firmware(!!!) betroffen sind, hat das unabsehbare Auswirkungen.

Und die sogenannte "Leistung" ist mir schnuppe. Von daher ist mein Linux mit SATA2 so rasend schnell, dass ich leider nie mehr wirklich mehr brauche. Wenn ich mich mit dem Thema noch befasse, dann ist es rein aus technischer Neugier. Wie viel Speicher und welche Bauart, schneckenlangsam, und was für eine CPU haben denn die Smartphones und Tablets, mit denen die meisten Leute heute glücklich sind?
 
Zuletzt bearbeitet:
Sysworker schrieb:
Die Haltbarkeit ist bei mir ein Leistungskriterium
Dann kann bei Dir ein Trabi mehr leisten als ein Ferrari, weil die ja im Schnitt länger gehalten haben und mehr Kilometer gefahren sind? Seltsame Einstufung der Haltbarkeit, ich sehe die immer noch unabhängig von der Leistung als ein gesondertes Kriterium.
Sysworker schrieb:
leider nicxht exakt feststellbar da die Transcend 370 keine entsprechenden SMART Wert ausgibt).
Doch natürlich gibt die das aus, sollte sie zumindest und zwar im Attribut oxF1 bzw. 241 (dezimal), dort ist der Rohwert die Anzahl der geschriebenen Daten in 32MB Einheiten. Aber ich habe ich gesehen, dass es bei den Transcend 370 wohl Unterschiede bzgl. der S.M.A.R.T. Werte gibt, bei manchen zeigt CrystalDiskInfo mehr und bei anderen weniger Attribute an und außerdem kennt es die Namen der meisten Attribute nicht, außer vielleicht in der neuesten (Vorab-) Version.

Sysworker schrieb:
ansonsten Haltbarkeit: 840EVO / BASIC lässt grüßen - nie wieder Samsung, das Samsung Handy reicht
Was haben denn die Handys mit den SSDs zu tun? Das sind ganz unterschiedliche Produkte von total verschiedenen Abteilungen des Konzerns, Samsung baut auch Autos und bietet Versicherungen an und dann haben auch die 840 Evo und deren Vorgänger mit dem Haltbarkeit zu tun, die 840 Evo hat bis zur Behebung des Bug per FW-Update Daten langsamer ausgelesen die vor längere Zeit geschrieben wurden, aber ich habe von niemandem mit Datenverlust gelesen. Das war also ein Performance- und kein Zuverlässigkeitsproblem und dürfte der LDPC geschuldet sein, denn bei der SLDPC werden die Daten mehrfach mit unterschiedlichen Thresholds ausgelesen, was halt länger dauert.

Bei der 840 (ohne Zusatz) habe ich noch keinen echten Beleg für das angeblich langsame Lesen alter Daten gesehen habe, nur Unsinn mit HD Tune und einem Disk Refresher der linear Low-Lwevel refresht, damit kannst Du das auch bei Deiner Transcend 370 "nachweisen", probiere es mal aus!
Sysworker schrieb:
BTW: Meine Plextor M3 im Daddel PC, der jeden Tag mehrere Stunden läuft, hat gerade mal 3,55TBW in knapp 3 Jahren, aber nur weil TEMP auf eine HD geht.
Eine Plextor M3S habe ich auch, aber deren S.M.A.R.T. traue ich nicht mehr, wie der Fall dieser M5Pro zeigt, kann man sich wohl nur auf die Wert der Attributes BB, C4, C6 und E8 verlassen, die Attribute 01, B5 und B6 die eigentlich die Fehler anzeigen, scheinen geschönt zu sein. Und es gibt noch mehr solcher Fälle, das ist leider kein Einzelfall, weshalb ich inzwischen auch Abstand davon nehme Plextor SSDs zu empfehlen.
 
Lustig das man heute bei SSD noch über Haltbarkeit spricht.

Die Tests die es gibt geben aus das die SSD deutlich mehr aushalten als angegeben. Damit wurden die SSD ja absichtlich so belastet.

Sicher kann ich am Tag 900 Gig schreiben. Aber wer schreibt die eben jeden Tag.

Bevor die SSD kaputt geschrieben sind. Wurden Sie eh gegen größere getauscht und sind nur noch Datengrab.
 
So etwas sagt nur jemand, der absolut keine Ahnung hat oder der andere Leute ohne Fachkenntnisse absichtlich verschaukeln will.
Koto schrieb:
Die Tests die es gibt geben aus das die SSD deutlich mehr aushalten als angegeben.

Die getesteten SSDs halten IM DURCHSCHNITT mehr aus. Aber wenn von 2.000.000.000.000 Byte nur ein einziges Byte verfälscht wird, kann das einen Softwarefehler erzeugen, der tödlich sein kann. Bei PCs für verspielte Kinder ist das nicht wichtig.
 
Turbo Prinz schrieb:
So etwas sagt nur jemand, der absolut keine Ahnung hat oder der andere Leute ohne Fachkenntnisse absichtlich verschaukeln will.


Die getesteten SSDs halten IM DURCHSCHNITT mehr aus. Aber wenn von 2.000.000.000.000 Byte nur ein einziges Byte verfälscht wird, kann das einen Softwarefehler erzeugen, der tödlich sein kann. Bei PCs für verspielte Kinder ist das nicht wichtig.

Das ist ein typischer Troll Beitrag

Warum ist klar. Das wenig Sachliche ist irrelevant für das gesagte. Weil wie wahrscheinlich ist es das dieses eintritt und wie wahrscheinlich das was ich sage, also das man die SSD vorher tauscht.

Da kann man auch einwenden das einem ne Lötstelle kalt werden kann und ne SSD ausfallen. Das ist ebenfalls wesentlich wahrscheinlicher.

Der Rest ist unangemessenes geflamme.
 
Zuletzt bearbeitet:
Ja, Turbo Prinz ist ein bekannter Forentroll und kommt immer mit dem gleichen Mist an, der ist unbelehrbar und kann ich jedem nur raten ihn zu ignorieren und auch seine Beiträge nicht einzugehen, denn: "Don't feed...."

Wer sich um korrupte Daten sorgt, der sollte zuerst ein System mit ECC RAM, passendem Board und Chipsatz und passender CPU nehmen, wie schon auf S. 13 im Thread der 950 Pro geschrieben, aber Trolle kommen eben immer wieder mit dem selben Schwachsinn an, egal wie oft man sie widerlegt. Bleibt also für alle die sich wirklich Sorgen um Datenkorruption machen hier noch mal was Matt Ahren, Mitentwickler des ZFS-Dateisystems, schreibt:
Man beachte die Reihenfolge, zuerst empfiehlt er ECC RAM und dann als Kirsche auf den Kuchen ein Filesystem mit Prüfsummen wie ZFS zu verwenden, wenn man seine Daten liebt und vor Korruption schützen möchte! Das ECC RAM nur Sinn macht, wenn der Rest des Systems dieses auch unterstützt, ist sowieso selbstverständlich, denn sonst hängen die zusätzlichen Bits einfach nur in der Luft.
 
Vor allem Daten Korruption ist ja nicht SSD Anhängig. Es kann auch HDD, CPUs oder Ram oder das Board betreffen.

Keine Ahnung auf was man in dem Zusammenhang nun hinaus will.

Uns kann auch der Blitz beim Scheißen treffen. LOL
 
Ist jetzt leider nicht mehr ganz OnT:

Man sieht, es gibt unterschiedliche Ansichten zu den Leistungskriterien :-)

Die "Begeisterung" für Samsung hält sich zumindest in meinem Freundeskreis in Grenzen, seit den 840EVO Problemen kauft keiner mehr Samsung und meine 840 Basic hat nach dem ersten Backup - Refresh Zyklus Anfang diesen Jahres keine spürbaren Leistungsverluste.

Danke für den Tip mit F1 bei der Transcend, keine DiskInfo Variante kann damit was anfangen. Neuere Varianten haben übrigens Probleme mit der Plextor M3, die müsste ich wohl mal updaten von FW 1.05 auf 1.07


Daten Korruption -
hatte ich übrigens schon mal bei HD's - 2*HGST 2 TB Platten zusammen gekauft. Die erste hatte schon nach ein paar Monaten defekte Sektoren - mit Datenverlust, die zweite läuft schon viele Jahre ohne Probleme und daher:

ECC RAM & ZFS sind im Backup Server - mir ganz wichtige Daten gibt's in 4 facher Ausfertigung
 
Zuletzt bearbeitet:
Einen Einfluss haben die SSDs wie auch HDDs darauf schon, nämlich wenn es um den Schutz der internen Datenpfade vor Datenkorruption geht, was aber ein typisches Feature von Enterprise Platten ist, bei den Consumer Laufwerken findet man das gewöhnlich nicht. Dazu gehört dann z.B. auch ECC RAM für den Cache der Platte zu verwenden, wie es von den Consumer SSDs die Intel 730 und 750 haben, aber die stammen auch direkt von den Enterprise Serien DC S3500 bzw. DC P3500 ab und offiziell haben sie das Feature auch gar nicht. Aber der HW ist die gleiche und auch der zusätzliche RAM Baustein ist verlötet, man kann also schon davon ausgehen, dass es an Board ist, nur sollen eben Kunden die auf sowas Wert legen die teureren Enterprisemodelle nehmen.

Übrigens haben einige Consumer SSDs und vor allem von Seagate auch einige Consumer HDDs immerhin eine Erkennung der Fehler auf den internen Datenpfaden, was man dann am S.M.A.R.T. Attribut "Ende-zu-Ende Fehler" erkennt, aber erkennen eben solche Fehler nur, können sie aber offensichtlich nicht korrigieren. Das kommt zwar nur selten vor, aber wenn, dann verfälschen die Platten eben auch die Daten. Dann könnte es noch Verfälschungen bei der PCIe Übertragung geben, da gibt es wie bei jedem FIS über SATA auch eine CRC, aber eben bei PCIe noch Möglichkeiten erweiterter Fehlerkennung, aber das ist den größeren Serverplattformen vorbehalten, ebenso wie z.B. die ECC in den Netzwerkchips, wie hier am Beispiel von einigen Intel Chips zu sehen ist:

intel-ethernet-controller-ecc-png.528099


Man kann das Thema beliebig weiter spinnen, die Desktopplattformen haben im Grunde überhaupt keinen Schutz, da hat man die ECC die jede HDD am Ende jedes physikalischen Sektors und jede SSD für jede Page schreiben und die praktisch verhindert, dass sie falsche Daten wiedergibt, aber schon auf den internen Datenpfaden sind die Daten ungeschützt, dann werden sie über SATA übertragen und pro FIS mit maximal 8192 Byte Nutzdaten mit einer CRC32 geschützt, landen dann aber in einfachem RAM ohne ECC und dort liegt die mit Abstand größte Gefahrenquelle. Bei der kleinen Xeon E3 Plattform gibt es dann einfaches ECC RAM, aber mehr auch nicht, die Netzwerkkarten die dort verwendet werden haben keine Schutz, die Xeon E5 unterstützen schon mehr RAS Features, die Boards haben da auch meist die NICs mit ECC Features verbaut und die Xeon E7 sind die CPUs für hohe RAS Anforderungen von Intel. Wer es noch weiter treibt landet beim Mainframe, mehr Sicherheit vor Datenkorruption gibt es nicht, weshalb die Dinger immer noch bei Banken und Versicherungen rumstehen und IBM immer noch neue Modelle entwickelt und verkauft, obwohl sie schon vor Jahrzehnten todgesagt wurden.

Nun wird sich kein Heimanwender einen Mainframe kaufen, wohl auch kaum ein Xeon E7, aber einen E3 oder E5 mit passendem Board und ECC RAM und wenn man es weiter treiben will, dann nimmt man auch nicht die 850 Evo, sondern die Enterprise PM863, die hat nämlich so einen Schutz:
Die Kondensatoren um Low-Page Corruption zu verhindern hat die 850 Evo nicht, wie weit sie einen Schutz der internen Datenpfade hat, kann ich nicht sagen, vielleicht ist das mit dem Attribut C3 "ECC-Fehlerrate" gemeint, vielleicht bezieht es sich auf die ECC der Daten in den NANDs. Die thermische Überwachung mit dem Throtteling bei hohen Temperaturen haben jedenfalls auch die Consumer Modell der 850er Reihe.

Ja Consumer HW ist immer auch Mut zur Lücke wenn es um Datensicherheit geht, dafür ist sie dann aber auch billiger und das zählt bei den meisten Heimanwendern eben mehr, wie man auch an den Diskussionen rund um ZFS immer wieder sieht, wo immer genug Leute die Notwendigkeit von ECC RAM anzweifeln und meinen mit dem Prüfsummen des Filesystems sicher genug zu sein, vor allem aber wollen sie bei der HW sparen denn Plattformen die ECC unterstützen, sind eben i.d.R. teurer. Consumer HW wie einer 850 Evo über Datenkorruption zu reden ist also sinnfrei, da die gar nicht den Anspruch hat perfekt vor sowas zu schützen, das kann die SSD alleine auch gar nicht, denn dazu gehört eben auch ein passendes System wo alle Komponenten diesen Schutz bieten, oder zumindest die wichtigsten.

Trotzdem lauern dann noch überall Gefahren, auch solche die erst durch Technologien entstehen, die moderne Filesysteme wie ZFS oder btrfs erst einführen, wie die Daten-Deduplizierung, bei der es zu Hash Kollisionen kommen kann. Auch wenn das erst im Exabyte Bereich dann statistisch relevant wird, kann man schon bei einige TB das Pech haben das zwei unterschiedliche Datenblöcke den gleichen Hash erzeugen und damit zu Datenkorruption führen. Viel relevanter sind dagegen HW, SW- und FW Bugs, wie sie immer mal vorkommen können, z.B. der im Juli gefundene Bug im Linux-Kernel bei TRIM im mdraid.

Damit aber genug zum Thema Datenkorruption, das gehört einfach nicht in den Bereich der Consumer HW, da diese nicht dafür gemacht ist sowas zu verhindern, die ist gemacht um meistens zu laufen und dafür billig zu sein, egal ob es dabei um Laufwerke, CPU, Mainboards, Netzwerkkarten, RAM oder sonstwas geht und nur bei den Stellen wo die Fehlergefahr am größten ist, gibt es einen Schutz, so sind gekippte Bits im RAM noch zu selten um einen Schutz dagegen standardmäßig einzubauen, aber vor Übertragungsfehlern per SATA oder PCIe gibt es einen Schutz und ebenso für die Daten auf dem Medium, da sowohl bei HDDs wie auch bei SSDs immer mal ein Bit falsch ausgelesen wird, das ist einfach normal.

Intel-Ethernet-Controller-ECC.png
 
Holt schrieb:
Trotzdem lauern dann noch überall Gefahren, auch solche die erst durch Technologien entstehen, die moderne Filesysteme wie ZFS oder btrfs erst einführen, wie die Daten-Deduplizierung, bei der es zu Hash Kollisionen kommen kann. Auch wenn das erst im Exabyte Bereich dann statistisch relevant wird, kann man schon bei einige TB das Pech haben das zwei unterschiedliche Datenblöcke den gleichen Hash erzeugen und damit zu Datenkorruption führen.

Manchmal bin ich beeindruckt von deinem Fachwissen, aber bist Du dir sicher, daß sich ein HPFS Filesystem mit DeDup alleine auf den Hash Value verlässt?
 
Auf was soll man sich sonst verlassen? Das Ziel ist ja, dass man die gleichen Daten nur einmal speichert, auch wenn sie zu mehreren Dateien gehören, also muss man davon einen Hash, welcher auch immer das konkret ist und da der kürzer sein muss um überhaupt Sinn bei einer Daten-Deduplizierung zu machen, muss die Anzahl der möglichen Kombinationen immer kleiner sein als bei dem Datenblock aus dem er gebildet wird und damit wird es zwangsläufig immer mehrere Kombinationen von unterschiedlichen Datenblöcken geben, die den gleichen Hashwert erzeugen. Vermeiden lässt könnte man es nur, wenn der Hash mindestens so lange wie der Datenblock ist, aber dann werden die Verwaltungsdaten alleine für die Deduplizierung schon größer als die Daten selbst (neben dem Hash braucht man ja auch noch Referenzen wo die Daten jeweils stehen), so dass man erst dann einen Vorteil hätte wenn im Schnitt alle Daten mehr als zweimal auf der Platte stehen.

Will man das Risiko wirklich ganz ausschließen, so muss man auf das Feature verzichten, alle anderen brauchen einen bestimmten Mut zur Lücke. Es ist wie immer im Leben ein Kompromiss und man muss sich eben entscheiden wo man die Prioritäten setzt. Es braucht ja nicht jeder für alle Daten eine Lösung die möglichst nah an 100%ig Sicherheit vor Datenkorruption heran kommt und es ist ja auch nicht jeder bereit den dafür nötigen (finanziellen) Aufwand zu treiben.

Aber es ist eben manchmal einfach nur lächerlich und zeugt vom Unwissen, wenn bestimmte Leute einerseits ein Filesystem wie ZFS wegen dessen Sicherheit vor Datenkorruption einsetzen/empfehlen und dann aber auch Features wie Daten-Deduplizierung nutzen und/oder auf den nötigen Unterbau in Form eines Rechners der ECC RAM nutzt und unterstützt verzichten.
 
Zuletzt bearbeitet:
Holt schrieb:
Auf was soll man sich sonst verlassen?

Irgendwie verstehe ich deine"Gegenfrage" nicht!

Ich würde mal flapsig antworten, daß die Menschen, die Betriebssysteme, Filesysteme, Semaphoren und die darauf basierenden Algorithmen kennen und entsprechend auch richtig impementieren.

In der Praxis ist es aber oft so, das HW Leute gerne mal den Fehler, wie zB zerschossene Daten schnell mal auf die SW schieben und dies gerade zur Reklamationsabwehr gerne mal in "technisch fundierte" Aussagen verpacken ohne sich der Softwaremechanimen bewusst sind.

Das Ziel ist ja, dass man die gleichen Daten nur einmal speichert, auch wenn sie zu mehreren Dateien gehören, also muss man davon einen Hash, welcher auch immer das konkret ist und da der kürzer sein muss um überhaupt Sinn bei einer Daten-Deduplizierung zu machen, muss die Anzahl der möglichen Kombinationen immer kleiner sein als bei dem Datenblock aus dem er gebildet wird und damit wird es zwangsläufig immer mehrere Kombinationen von unterschiedlichen Datenblöcken geben, die den gleichen Hashwert erzeugen.

Klar, wenn man die Hash Algorithmen relativ simple betrachtet ist es so, allerdings geht Hashing einen Schritt weiter und behandelt selbstverständlich die Collision Detection in einem eigenen Verfahren.

Vermeiden lässt könnte man es nur, wenn der Hash mindestens so lange wie der Datenblock ist, aber dann werden die Verwaltungsdaten alleine für die Deduplizierung schon größer als die Daten selbst (neben dem Hash braucht man ja auch noch Referenzen wo die Daten jeweils stehen), so dass man erst dann einen Vorteil hätte wenn im Schnitt alle Daten mehr als zweimal auf der Platte stehen.

Nein.

Will man das Risiko wirklich ganz ausschließen, so muss man auf das Feature verzichten, alle anderen brauchen einen bestimmten Mut zur Lücke.

Nochmal Nein. Man muß die vermeintliche Lücke nur softwaretechnisch korrekt behandeln.

Aber es ist eben manchmal einfach nur lächerlich und zeugt vom Unwissen, ...

Das geht jetzt mehr ins Philosophische ;)


Aber wenn Du Belege hast, daß Data Corruption ein "geplantes Feature" eines BS/FS ist, immer nur her damit.
 
Wenn ein Hash 8 Byte lang ist, dann erlaubt er 2^(8*8) verschiedene Kombinationen und wenn man den über einen Cluster von 4096 Byte bildet, dann hat man dort aber eben 2^(8*4096) mögliche Kombinationen und nun rechne mal selbst aus, wie viele verschiedene Bitkombinationen der 4096 Byte jeweils den gleichen Hash erzeugen, also viel viele Hash Kollisionen möglich sind. Ob HW- oder SW-Mensch, ds gibt einfach kein Entkommen aus der Falle, wenn die Länge des Hashes kürzer ist als die Länge der Daten über die er gebildet wird (und jeweils alle möglichen Bitkombination vorkommen können), dann gibt es immer zwangsläufig auch Hash Kollisionen.
 
Zurück
Oben