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

[juenger]

Klar, aber warum erklärst mir gerade das, was ich oben bereits geschrieben habe.

Wenn es zu zwei identischen Hash Keys (Collision) kommt, wird im einfachsten Fall ein Byte-Compare der Basisdaten durchgeführt und entsprechend des Compare Results entschieden

Case A Data-Equal - Hash Correct und beide Datensätze entsprechen einander DeDup möglich

Case B Data-Different - Hash-Value contains two (ore more) different Data - und es werden unter diesem Hash Key mehrere unterschiedliche Datensätze verwaltet.

Anzunehmen, das FS Entwickler Data Corruption dem statistischen Zufall überlassen ist einfach Humbug.

 

[Holt]

Könnte man machen, aber wie sieht es mit der Performance aus, wenn man dann jedes mal die Daten byteweise vergleicht und wie will man das nachher verwalten? Soll etwa neben dem Hash dann noch eine Art Versionsnummer verwaltet werden? Rechne mal aus wie lang die werden könnte!

 

[juenger]

Könnte man machen, aber wie sieht es mit der Performance aus, wenn man dann jedes mal die Daten byteweise vergleicht und wie will man das nachher verwalten?

Was erwartest Du für Antworten? Hohe Datenintegrität und Speichereffizienz oder besser RAM-Disks für hohe FPS?

Soll etwa neben dem Hash dann noch eine Art Versionsnummer verwaltet werden?

Wenn es egal ist, ob die Daten bereits nach kürzester Zeit Corrupted sind, kann man den Aufwand natürlich sparen.

Rechne mal aus wie lang die werden könnte!

Mit oder ohne Clustering?

 

[Holt]

Was heißt nach kurzer Zeit? Die Zahl der möglichen Kombinationen ist ja nach Länge des Hashes doch sowieso gewaltig und wenn man die Kapazitäten von realen Storages im Verhältnis dazu sieht, dann ist die Wahrscheinlichkeit eben nur noch minimal, dass überhaupt zweimal der gleiche Hash für unterschiedliche Daten erzeugt wird. Ich hatte doch geschrieben, dass es "erst im Exabyte Bereich dann statistisch relevant wird", aber trotzdem kann es eben auch im Terabyte Bereich nicht ausgeschlossen werden und es ist halt ein Punkt den man kennen sollte, wenn man sich um Datenkorruption Gedanken macht.

Ebenso ist es mit der Wahrscheinlichkeit, dass eine Platte mal unerkannt falsche Daten zurückliefert, ohne dass die internen Datenpfade daran schuld sind. Die passiert praktisch nur, wenn eine HDD den falschen Sektor angefahren hat und dessen Markierung auch noch falsch gelesen wurden und dies nicht aufgefallen ist, was auch nur passiert, wenn die fehlerhaften Daten dann auch noch zur (möglicherweise ebenfalls fehlerhaften) ECC so gut passt, dass es maximal als korrigierbarer Fehler erkannt wird. Belastbare Zahlen sind dafür nicht zu finden, aber die Wahrscheinlichkeit dafür soll jenseits von 1:10^30 gelesene Bits liegen, RAM Fehler sind im Vergleich dazu alltäglich.

Man muss eben sehen, wo die Wahrscheinlichkeiten am höchsten sind und sollte sich auf die wahrscheinlichsten Ursachen zuerst konzentrieren. RAM ist die wahrscheinlichste Fehlerursache, weshalb auch die Xeon E3 Plattform sich von den S. 115x Desktopplattformen nur ECC RAM Unterstützung unterscheidet, die Xeon-D, Xeon E5 und erst recht die Xeon E7 Plattformen legen dann eben da und auch noch an anderen Stellen jeweils was drauf.

Mit oder ohne Clustering?

Das ist Dir überlassen, aber im Worst Case kann das Volumen eben die maximal zulässige Größe haben und jede Einheit über die der Hash gebildet wird, hat zwar unterschiedliche Daten, die aber alle den gleichen Hash erzeugen. Das Risiko liegt erst dann auch theoretisch bei Null, wenn auch dieser (praktisch natürlich absolut unwahrscheinliche) Fall gehandelt werden kann.

 

[Turbo Prinz]

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.

Warum wohl? Mindestens Jede 10. Anfrage in Foren bezüglich Blue Screens könnte als Ursache schlechte Datenträger haben, egal ob Platte oder SSD. Ich würde auch keine als schlecht bekannten Festplatten kaufen.

Wenn jemand schreibt, dass sich billige SSDs für ihn nicht lohnen, dann kommt einer mit mimimi... aber das Ram, aber das Motherboard... - alles reine Ablenkung. Für 500€ bekommt man eine sehr gute gebrauchte Workstation.

Wenn man schreibt, dass alles sicher ist und man BtrFS verwendet, dann kommt einer ... mimimi... Deduplizierung (hat er bei Google gefunden). Deduplizierung wird wohl kein vernünftiger Heimanwender verwenden. Das kostet schließlich Rechenzeit und bringt ihm wenig. Wenn ich Speicherplatz im PC sparen will, dann miste ich aus. Jede Woche sehe ich mir mal die SMART-Werte an. Wenn ein kritischer Wert erhöht ist, dann nehme ich die SSD nur noch für Katzenvideos - so wie ich eine TLC-SSD, wenn überhaupt, generell nur für Katzenvideos nehmen würde. Übrigens hatte uns MS ja schon längst ReFS mit Hash versprochen. Wenn das bei Consumern Standard wäre, dann gäbe es vielleicht einige % mehr Reklamationen bei Consumer-SSDs.

 

[vizu]

Ich hatte schon überlegt mir 2 1TB SSD's zu holen, wenn jetzt alle anderen Hersteller nachziehen kann man auch zur 2TB SSD greifen. Nur von Samsung hol ich mir nichts. Ich hab keine Lust auf Softwareprobleme...

genau das hab ich mir auch gedacht hab immer noch probs mit meiner 840 Evo

 

[Holt]

vizu, hast Du denn die neueste FW drauf? Und was für Probleme hast Du? Wenn Du mit meinst immer noch schlechte Leseraten bei alten Daten zu haben, dann schau Dir den den Thread "MX100 schon defekt?" an, da habe ich auch im Post #53 erklärt, warum diese Low-Level Benchmarks wie HD Tune nicht dazu taugt festzustellen ob das Problem vorhanden ist und warum diese oft viel niedrigere Werte liefern. Denn damit kann man das scheinbar bei jeder SSD nachweisen, wenn sie länger genutzt wurde und wenn man dann ein Diskrefesh macht welches auf Low-Level Basis arbeitet wie es für HDDs üblich ist, dann wird man hinterher auch mit einem Low-Level Benchmark immer bessere Ergebnisse bekommen, einfach wegen dem Schreiben aufeinanderfolgender LBAs im gleichen Zusammenhang statt dem Schreiben von Dateien an einem Stück.

Wenn man die Leserate mit alten Dateien prüfen will, dann bencht man mit dem File Bench Tool von Blublah (Quelle) und sollte mindestens 3MB als Mindestgröße wählen, mit nur einem MB schafft auch meine 830 einige Dateien nur mit 100MB/s, ab 3MB liest sie alle mit über 300MB/s.

 

[juenger]

Was heißt nach kurzer Zeit? Die Zahl der möglichen Kombinationen ist ja nach Länge des Hashes doch sowieso gewaltig und wenn man die Kapazitäten von realen Storages im Verhältnis dazu sieht, dann ist die Wahrscheinlichkeit eben nur noch minimal, dass überhaupt zweimal der gleiche Hash für unterschiedliche Daten erzeugt wird. Ich hatte doch geschrieben, dass es "erst im Exabyte Bereich dann statistisch relevant wird", aber trotzdem kann es eben auch im Terabyte Bereich nicht ausgeschlossen werden und es ist halt ein Punkt den man kennen sollte, wenn man sich um Datenkorruption Gedanken macht.

Es ist völlig egal wie wahrscheinlich oder unwahrscheinlich eine Hash Key Collision ist, da diese entsprechend behandelt werden. Das habe ich doch einen Post weiter oben bereits geschrieben!

Falsch ist es zu behaupten, daß eine Data Corruption in Filesystemen auftreten kann, nur weil man die zugrunde liegenden Verfahren der Hash Mechanismen nicht verstanden hat.

 

[Koto]

Ihr habt Probleme. Was für eine Diskussion LOL

 

[Holt]

Man muss es aber passend mit verfiy als Option einstellen und dann ist da wieder das Risko von Bugs, die eben auch zu Datenkorruption führen können:

It's unfortunate that Jeff Bonwick's blog post linked by the OP is so widely referenced, since it's incorrect - about three weeks after it was posted the 'fletcher4,verify' option was permanently removed from ZFS due to the discovery of major bugs

Aber lassen wir das, es passt wirklich nicht zum Thema, denn bei Consumer HW liegt der Fokus woanders, da wird nicht mehr als nötig investiert um Datenkorruption soweit zu verhindern, dass sie bei 99,x% der User möglichst keine Probleme macht und sie an ihren billigen Rechnern dappeln, surfen und Briefe schreiben können. Das erfüllt auch die 850 Evo wie praktisch jede andere Consumer SSD, die ist auch nicht besonders auffällig für Slient-Data Corruption, hat aber eben auch keine besonderen Enterprise-Features um dieses Risiko weiter zu mindern. Damit macht sie was sie soll: Heimanwendern einen günstigen und schnelle Massenspeicher zu bieten.

Die Enterprisegeschwister der PM863 Serien bieten dagegen die Feature wie Full-Power-Loss Protection und Internal-Data-Path-Protection (letztere könnte die 850er durchaus auch haben ohne damit beworben zu werden, da ja der gleiche Controller verbaut ist) und bietet damit die Feature für die Profianwender auch Geld bezahlen weil sie darauf wert legen und die System im Ganzen auch weit besser gegen Datenkorruption geschützt sind. So eine Enterprise SSD aber wegen der Sorge um Datenkorruption in einen Desktop der nicht einmal ECC RAM unterstützt zu verbauen, wäre aber wie wenn man Einbrecher mit 3 Riegeln vor der Haustür abschrecken möchte, aber die Fenster offen stehen lässt.

 

[Hallo32]

@Holt:

Menschen machen Fehler, dabei ist es egal, was diese gerade machen. Ob es nun bei der Implementierung eines Dateisystems erfolgt, beim Schreiben einer Firmware oder ebi anderen Tätigkeiten. Die Folgen der Fehler kann man minimieren aber in der Regel in der Praxis nicht vollständig eliminieren.


Wie sieht es eigentlich mit ECC innerhalb der CPU aus?

 

[Holt]

Gute Frage! Die CPUs die einen Memorycontroller haben der ECC RAM unterstützt, dürfte auch im Cache ECC haben, zumindest die Xeon E7 dürften das sicher haben, da es die Plattform mit dem höchsten RAS Ansprüchen ist, nach Itanium den sie ablösen dürfte. Wenn aber die kleinen S. 115x Celeron, Pentium und i3 es haben und die Dies der Xeon E3 12xx, dann macht es keinen Sinn das auf den Dies die als i5 und i7 verkauft werden, wie deaktivieren. Aber wie gesagt: Will man maximalen Schutz, landet man bei einem Mainframe!

 

[Hallo32]

Die Caches dürften bei der Realisierung nicht einmal das Problem sein, aber wie sieht es bei den Datenpfaden in der Alu und deren Register aus?
Was schließt kippende Bits in diesen Bereich der Datenverarbeitung aus?

Mainframes sind eine Lösung aber wo werden diese heute noch wirklich verwendet? Persönlich höre ich eher die Aussage, das identische Problem auf zwei System lösen und wenn das Ergebnis identisch ist, dann ist die Wahrscheinlichkeit, dass beide Systeme den identischen "stochastischen" Fehler erlebt haben, hinreichend klein.

Fehler in der Software deckt dieses natürlich nicht ab, aber das machen Mainframes ebenfalls nicht.

 

[Holt]

Ja, eine HW die logische Fehler im Programm finden kann, wird es so bald wohl nicht geben. Wie es in den Ausführungseinheiten der CPUs aussieht, kann ich nicht sagen, die Mainframes sind da geschützt und das sichert ja u.a. auch ihre Existenz z.B. in Banken und Versicherungen. Für den Rest gilt vermutlich mal wieder, dass man da den Mut zur Lücke hatte, weil die Wahrscheinlichkeit von Fehlern so gering ist, dass sie den Aufwand nicht rechtfertigt der nötig wäre diese Fehler zu vermeiden. Hard-errors werden wohl kaum vorkommen, dafür Chips mit derartigen Defekten zu erkennen, ist die Qualitätskontrolle zuständig und ein PC dessen CPU bei bestimmten Bitkombinationen dann eine Fehler produziert würde bei dem Durchsatz den es dort gibt, wohl kaum überhaupt booten. Eine Bitkombination die z.B. bei RAM dafür sorgt das ein bestimmtes Bit kippt, die meisten Fehler bei Memtest86+ fallen ja nicht in den einfach Tests mit 00 und FF als Bitmuster auf (das Testen die RAM Hersteller sicher schon selbst), sondern bei komplexen Bitmustern, kommt ja im Verhältnis zu einem vergleichbaren Fehler in der CPU nur sehr selten zum Tragen, da wird ja nur ab und an mal drauf zugegriffen, während in einer ALU oder einem Register je denkbare Bitkombination (es müssen ja nicht alle 64 Bits sein, es reicht wenn einige Nachbarbits bestimmte Werte haben) im Sekundentakt durchgeht. Außerdem ist das im Vergleich zu RAM ja auch eine ganz andere Technik, RAM ist eine Matrix aus dicht gepackten Speicherzellen.

 

[Turbo Prinz]

Warum diese an den Haaren herbei gezogene Diskussion? Es geht hier doch nur um eine (zu) große SSD mit billigem (problematischen) Speicher über die man geteilter Meinung sein kann, weil sie eben in der Zuverlässigkeit während ihrer gesamten Nutzung wegen TLC nicht auf Pro-Niveau liegt, sonst brauchte man ja gar keine Pro herzustellen.

Warum Deduplizierung keinen Sinn macht
https://www.thomas-krenn.com/de/tkmag/expertentipps/warum-deduplizierung-keinen-sinn-macht-2/
siehe ---> linux-magazin.de/Ausgaben/2014/03/Deduplizierung (Links werden beim Edit verweigert)
"Online-Deduplizierung frisst mächtig Performance und will gut überlegt sein."
Ja, man kann sich auch ein Loch ins Knie bohren. Das soll nur von TLC ablenken...

 

[UweW.]

Aber meine 240 GB SSD hat darmals 117 Euro gekostet auch wenn die SSD Preise praktisch unverändert die letzten Jahre sind,
würde ich heutzutage dafür keine 600 bis 700 Euro für den Speicherplatz ausgeben...

Jeder hier im Forum, der noch vor 20 Jahren ohne mit der Wimper zu zucken 5000DM für einen PC (oder ähnlich gut ausgestatteten Amiga 4/5000) auf den Tresen gelegt hat, hat aber auch >700DM für eine IDE- oder >1000DM für eine gleichgroße SCSI-HDD, 1000DM für eine Matrox Millenium I mit 4MB, 500DM für eine Voodoo II 8MB etc. bezahlt. Einfach so. Prä-Internet-Ära. Treiber gab es in Form von Disketten beim Händler.

Viele Jahre lang habe ich SSDs immer dann gekauft, wenn der Preis unter 300€ gefallen war. Da gibts jetzt schon als 2,5" SSD 1TB und als flotte M2 512GB. Supergeil.
So eine leckere Intel 750er mit 1,2TB kostet zwar noch über 1000€, aber schaun mer mal, wie sich die Preise in 2 Jahren entwickelt haben. Bis dahin wird es wohl erst eine NVME 512GB M2 richten dürfen.



@all: Aber das Forum verkommt zu einem großen Haufen Nörglern, denen nichts recht ist und alles immer zu teuer.

 

[ChrisMK72]

Viele Jahre lang habe ich SSDs immer dann gekauft, wenn der Preis unter 300€ gefallen war. Da gibts jetzt schon als 2,5" SSD 1TB und als flotte M2 512GB. Supergeil.

Jo, für meine 830er 256GB hab ich noch um die 190€ bezahlt.
Jetzt gibt's schon ne 1TB SSD für um die 300€.

Ist zwar mehr Geld, aber auch bald 4 mal so viel Platz.
Kurz:
Was man heute für's Geld bekommt, ist schon toll.
Ich freu mich

edit:

So ... nu haben wir den 24.6.16, meine GTX 1080 werkelt im Rechner und ich schaue auf meinen 34" 21:9 Monitor, hab vorhin die 850 Evo 2TB bestellt und Win 10 Pro gleich dazu.
Die Gaming Zukunft kann für mich kommen.