Horst47 schrieb:
Läuft diese SSD auch mit Linux?
Wenn der Kernel NVMe unterstützt, dann ja.
Horst47 schrieb:
Wie sicher sind meine Daten auf so einer SSD?
Auf keinem einzelnen Laufwerk und auf keinem einzelnen RAID sind Daten besonders sicher, Enterprise SSDs und RAIDs mit Redundanz erhöhen die Sicherheit und Backups erhöhen sie noch viel mehr.
Horst47 schrieb:
Warum muss NVMe schneller sein als SATA?
Sie müssen nicht schneller sein, so wie USB3 Sticks nicht immer automatisch schneller sind als USB2 Sticks, aber sie könne,n weil eine entsprechende PCIe Anbinudng mehr Bandbreite hat und weil das NVMe Protokoll weniger Latenz bedeutet. Wenn die HW dies aber nicht ausnutzt, dann werden sie nicht schneller sein, so wie die 600p beim seq. Schreiben über viele GB am Stück eben langsamer als so manche SATA SSD ist.
Horst47 schrieb:
Schneller ist für mich nutzlos.
Dann vergiss die NVMe SSDs und bleibe bei dem was Du hast. Was soll dann die Frage, wenn Du mehr Performance nicht nutzen könntest?
Horst47 schrieb:
Datenerhalt innerhalb der garantierten Grenzen ist mir sehr wichtig.
Meinst Du damit den Offline Datenerhalt, also wenn die SSD stromlos ist?
Horst47 schrieb:
Solche schwammigen Sprüche wie "hält sehr viel länger als die Firmenangaben" stoßen mich eher ab.
Wieso? Du kannst dann immer noch darauf verzichten und die bei Erreichen der spezifizierten P/E Zyklen ersetzen. Bei SSDs die nicht einmal die spezifizierten P/E Zyklen erreichen, wo die NANDs also kaputt sind oder der Controller diese eben Read Only schaltet bevor der Media Wear Indicator (MWI) auf 0 oder 1 gefallen ist, kann man sich darauf nicht vorbereiten, weil dies unerwartet eintrott. Wenn der MWI hingegen jeden Monat um 1 fällt, kann man dan Zeitpunkt sehr gut planen wann man die SSD zu ersetzen hat und dann ist es sehr, sehr hilfreich, wenn diese auch deutlich mehr aushällt und weiter funktioniert statt vorher Stress zu machen.
Horst47 schrieb:
eine zeigt nach etwa 3 Jahren 13111853269 LBA an. Wie viel TB sind das?
Wie viele Bytes werden denn mit einem LBA adressiert? Außer bei den wenigen 4kn HDDs sind es eigentlich immer 512 Byte, also rechnet man 13111853269 LBAs mal 512 Byte/LBA = 6.713.268.873.728 Bytes, also 6,7TB oder 6,1TiB. Bei 2TB im Jahr wird die SSD kaum wegen NAND sterbe, da geht vorher was andere kaputt oder die wird als zu klein ausrangiert, ewig halten die übrigen Komponenten einer SSD auch nicht und wenn nur eine kalte Lötstelle sie dahinrafft.
Horst47 schrieb:
Wie lange wird die noch halten bis die Daten oder das System verfälscht werden?
Wie verfälscht? Die Daten sollten immer korrekt geliefert werden können, aber ein FW Bug oder der Ausfall eines NAND Dies können das auch immer mal verhindern, deshalb Backups. Außerdem ist vor allem das RAM des Rechner eine Quelle für Datenkorruption, wenn man kein ECC RAM hat und kein System welches dies auch unterstützt, dann sollte man dies zuerst ändern, ehe man sich über Verfälschung von Daten durch die Laufwerke Gedanken macht.
hrafnagaldr schrieb:
Darum, dass Daten nicht fehlerhaft abgelegt werden, kümmert sich das Dateisystem.
Nicht jedes Filesystem kümmert sich darum.
hrafnagaldr schrieb:
Der Controller hat fehlerhafte Sektoren zu markieren und teilt das dem Dateisystem mit.
Nein, nicht direkt, die Controller liefern einen Lesefehler, wenn sie Daten nicht mehr korrekt lesen können, die haben ja bei SSDs wie HDDs intern immer eine ECC für die Daten und wissen ob diese korrekt sind. Was dann passiert hängt davon ab wer diesen Lesefehler empfängt, bei einem RAID mit Redundanz wird der RAID Controller (was ggf. eine SW ist) die Daten mit Redundanz zu rekonstruieren versuchen und wenn das gelingt, werden die nicht lesbaren Daren auf dem Laufwerk auch überschrieben, weshalb HDDs in solchen RAIDs auch praktisch nie schwebende Sektoren zeigen.
hrafnagaldr schrieb:
Unerheblich, entweder Du hast ein Backup oder im Falle des Falles den Datenverlust verdient. Verrecken kann ein Datenträger aus vielerlei Gründen immer mal.
Und nicht nur durch das Verrecken von Datenträgern droht Datenverlust, auch durch Userfehler, Malware, etc.
Horst47 schrieb:
Aber die nutzen nichts, wenn auf ein Mal ne Kernel Panic kommt und ich nicht weiß warum.
Wieso sollten sie dann nichts nutzen? Du wirst sie dann vermutlich nicht brauchen, außer das Filesystem ist dabei kaputt gegangen und sie verraten nicht was die Ursache der Kernel Panic war, aber die solltest Du rausfinden und beseitigen, spätestens wenn es öfter vorkommt. Wie gesagt ist ECC RAM und natürlich ein System (CPU + Board) dies dies auch unterstützt, für Datensicherheit und auch einen stabilen sehr empfehlenswert, wer das nicht hat, sollte da zuerst ansetzen und dies ändern, erst danach würde ich mir bzgl. der Laufwerke Gedanken machen.
Horst47 schrieb:
SATA-SSD melden jedenfalls unter Windows im laufenden Betrieb niemals, daß eine DLL xyz einen Prüfbitfehler bringt.
Wie sollten sie das auch können, denn sie wissen nichts von Partitionen, Verzeichnissen oder Dateien, die bieten nur einen Adressraum unter dem Daten gespeichert und gelesen werden können und liefern beim Lesen eben die Daten oder melden einen Fehler. Es ist dann die Aufgabe des Programms welche die Datein xyz liest bzw. des OS welches ihm Funktionen dafür zur Verfügung stellt, diese Fehlermeldung zu geben wenn es statt der Daten einen Lesefehler von der Platte gemeldet bekommen hat.
Horst47 schrieb:
Für mich ist es einfach professionell, wenn ich fünf Jahre Garantie habe und kalkulieren kann, wann ich mir eine neue SSD besorgen muss.
Wenn Du ein Auto kaufst und dies hat nur 3 Jahre Garantie, tauscht Du es dann deswegen nach 3 Jahren, während Du eines mit 5 Jahren Garantie erst nach 5 Jahren tauschen würdest?
Horst47 schrieb:
Ich will sowieso keinen Datenträger länger benutzen, als der Hersteller das gut findet.
Na wenn alls so denken würden und die Hersteller dies wüssten, dann könnten wir die SSDs wohl bald jährlich tauschen. :evillil
Außerdem sagt die Garantie nicht, dass die SSD in der Zeit nicht ausfallen könnte, sie sagt nur, dass der Hersteller den wirtschaftlichen der SSD dann ersetzt, nicht die Folgeschäden wie den Datenverlust.