Welche SSD?

Oh shit ... Wollte spontan dem Couchlaptop ein Upgrade der vollen 256GB SSD spendieren und hab dann erst die Preisentwicklung der letzten Wochen gesehen ... Hätte eigentlich 1TB genommen da ich mit ca 50€ gerechnet hab, aber 512 reichen eigentlich auch. Laptop ist Lenovo X13 AMD G2 und ich brauche keine Megaleistung, einfach was solides. SN770 1TB um 70€, oder gibt's sonst noch empfehlenswerte Alternativen zu beobachten?

Hast du mit der schon mehr Erfahrung gemacht? Die Verbatim Vi3000 & Lexar NM620 habe ich für budget builts auch immer wieder im Auge, sind beide ab 80-90e zu haben

hab mir jetzt mal als storage platte die nm790 bestellt mit 4TB.
denke die verhält sich ok bei zunehmenden füllstand. damit werde ich eine alte kingston a400 ssd ablösen sowie eine samsung QVC. im prinzip kannst dort nur die hälfte des speichers nutzen. danach steht das system defacto weil die schreibraten stark einbrechen.

hier noch ein review das ich für die entscheidung herangezogen habe:
https://www.computerbase.de/2023-09...-4-tb-ssd-test/

Zitat aus einem Post von Bender

Wenn es nur um Storage geht sind schreib/read werte eher irrelevant.
Das erstmalige beschreiben der 8tb Samsung war aber zach. 150mb..

Jein. Wenn du 80% füllstand hast und du defacto nix mehr kopieren kannst weil du mit 10-20mb/s herumtust dann ist der wiederbeschreibbare Speicher defacto nutzlos. Read werte brechen während dessen auch stark ein. Mag Anwendungsfälle geben bei denen es egal ist. Aber selbst wenn ich nur das iPhone Backup drauf spiele und die disk langsamer ist als der usb Port und das ganze dann 2h dauert wird man sie wechseln wollen. Alles was ca. 1gbit ankommend aus dem Netzwerk wegschreiben kann reicht mir komplett aus, die 2x oben genannten SSDs können es nicht.

Welche Fikwot denn? Die FN955 sollte ja TLC haben.

Hab mir noch ne 2TB FN955 für meinen neuen Laptop bestellt, die gibts noch um „günstige“ 120€ auf Amazon.

Gibt es eigentlich irgendwelche Online-Ressourcen, die systematisch testen, ob (Consumer-)SSDs von "Datenverlust-bei-Spannungsverlust-trotz-fsync-erfolgreich"-Problemen gebeutelt sind? Frei nach https://www.tomshardware.com/news/s...-ssds-data-loss zum Beispiel.

@PIMP: Wegen deiner Backups nimmst du afaiui Bezug auf ein anderes Phaenomen/Problem, das wir mal im IRC gestreift haben - naemlich dass (manche) SSDs durch langes "offline, powered-down Liegenlassen" sozusagen "vergesslich" werden, und nicht mehr alle auf ihnen zuletzt gespeicherten Daten wieder auslesen lassen koennen. Das meine ich hier nicht - waere aber auch sehr interessant (nur halt extrem muehsam, weil man ja ggf. systematisch ueber Jahre beobachten muesste)!


Ich meine hier, dass es Flash-Speicher gibt, das ueber den Erfolg bzw. Abschluss des "commit all written data to durable storage"-Befehls ("SYNC" nennt man das oft einfach ugs. - hat aber ueber die Jahre und Technologien immer mal wieder anders geheiszen, beim SCSI z. B. FUA (Forced Unit Access)) zu luegen. Das kann sich natuerlich fatal auf die Datenkonsistenz auswirken, wenn die in Auftrag gegebenen Schreibvorgaenge nur "clever" genug sind - was bei modernen, optimierten Dateisystemen meistens der Fall ist.

Zur Erinnerung: Wenn du in einem modernen Betriebssystem Daten ins Dateisystem schreiben laesst und die Kernel-Funktion, die das durchfuehrt, erfolgreich returned, bedeutet das im Regelfall NICHT, dass die Daten damit auf dem Datentraeger, der den das Dateisystem/den Mountpoint serviciert, auch wirklich persistiert sind. Dafuer gibt es (eben aus Optimierungsgruenden) nochmal einen gesonderten syscall, der genau dieses persistence Schreiben explizit veranlasst - bzw., wenn den eine Zeit lang niemand aufruft, eine Art integrierten "Cron-Job" z. B. im Dateisystemtreiber, der alle N Zeiteinheiten (meistens wird das in Centisekunden bis wenigen Sekunden gemessen) so einen SYNC/FLUSH/Younameit-Befehl triggert. Erst wenn das passiert, kuemmern sich die Schichten zwischen Kernel und NAND gemeinschaftlich darum, dass die Bitmuster nach Vorstellungen des Kernels ihren Weg in die logischen Sektoren des Speichermediums schaffen, sodass der so gebildete Zustand auch trotz eines ploetzlichen Spannungsabfalls (z. B durch Stromausfall, oder wenn die SSD abgesteckt/aus dem Slot gerissen wird, etc.) beim naechsten Einschalten in genau dieser Form immer noch vorhanden ist. Damit das funktionieren kann, darf keine darunterliegende Schicht die obenliegenden ueber den erfolgreichen und korrekten Abschluss ihrer Arbeit beluegen - was aber leider immer mal wieder gerne passiert, weil man damit halt bei Benchmarks mit geradezu fantastischen Zahlen luegen kann.

(Das Problem besteht uebrigens nicht notwendigerweise nur in SSD-Firmware und anderer Block Storage, sondern kann beliebig weit oben im Persistenz-Stack gelagert sein. MongoDB z. B. hat viele Jahre lang gute Performance vorgetaeuscht, indem es auf explizites SYNCen von committed writes verzichtet hat, was natuerlich in irgendwelchen Durchsatzbenchmarks super augeschaut hat, aber bei potenziell vielen Usern zu Datenverlust gefuehrt haben duerfte.)


Namen fuer dieses skandaloese Verhalten ist mir leider keiner bekannt. Wenn mir wer ein paar tausend Euro fuer Testhardware sponsert, mache ich aber gerne ein Quartal lang gewissenhaft Tests und hebe einen sprechenden solchen aus der Taufe

Klingt für mich nach Preisabsprachen und Ausnutzen der Kunden.