Der leise Tod einer SSD...?...

On 12/13/2021 19:47, Volker Bartheld wrote:
Ach so, Du wolltest nur generalisieren [sup: und theoretisieren]. Me culpa.
Und jetzt huschhusch, zurück ins Körbchen.

Generalisieren - ja.
Aber theoretisch ist da nichts.

Ich habe eine Ausbildung dazu von Fujitsu erhalten.
Denk mal an - ich weiß halt Bescheid - einer von wenigen.
Ich wußte daher auch vorher, daß Du den nicht wieder schnell bekommst.

On Mon, 13 Dec 2021 18:37:33 +0100, Helmut Schellong wrote:
Flash-Speicher altert nun mal mit jedem Schreibvorgang - bis hin zur
Unbrauchbarkeit.
Was genau an \"Die 840er hat noch 75% \"Restlebensduer\", die 850er sogar noch
97%.\" in meinem Eingangsposting hast Du nicht verstanden?
Ich habe das zu 100% verstanden.
Er wird schon lange davor merkbar langsamer geworden sein.
Er wurde bis vor wenigen Tagen _überhaupt nicht_ merkbar langsamer
Was schrieb ich denn wirklich?
Ich schrieb von einem hypothetischen Exemplar mit Lebensdauer 400 TBW
Deshalb verwende ich Flash nur für Backup-Zwecke und Konfiguration.
Ich nicht.
Ich unter _allen_ Umständen!
Sehe ich 180° anders. Du magst die Zeit haben, Dich mit lahmem Dreheisen
totzulangweilen, der Rest der computernutzenden Welt nicht.
Warum dann Dein Posting: \"Der leise Tod einer SSD...?\" nach einigen Jahren?



--
Mit freundlichen Grüßen
Helmut Schellong var@schellong.biz
http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm
http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html
http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm
http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm
http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/rand.htm http://www.schellong.de/htm/bsd.htm
 
Am 13.12.21 um 14:53 schrieb Volker Bartheld:
[SATA-Secure-Ease]

Fürs SATA-Secure-Erase braucht es dann aber auch wieder ein tolles (und vor
allem proprietäres) Tool?

Hallo,

manche PCs von Fujitsu haben das eingebaut.
EraseDisk

https://sp.ts.fujitsu.com/dmsp/Publications/public/ds-EraseDisk.pdf

Einige Hersteller von SSDs offenbar auch:

https://www.ssdblog.de/2014/10/13/ssd-secure-erase-mit-herstellertools/


Bernd Mayer
 
On Mon, 13 Dec 2021 12:06:27 -0800, Joerg wrote:
[Samsung 840 Evo lahmt beim Empfang größeren Dateien]
Anachronistisch? Ich habe hier eine Samsung EVO 860 mit 240GB

Natürlich anachronistisch. Diese meine Samsung 840(!) Evo ist 8 Jahre alt.
Keine Ahnung, ob sie sich totgelangweilt hat, jedenfalls haben alle
Rettungsversuche nicht zur Wiederherstellung der ursprünglichen Performance
geführt.

Noch besser: Demnächst die 860 Pro einbauen, 840 Evo beisete legen, auf
Ersterer Linux Mint Mate installieren und die ganze Windowsscheiße
einfach
vergessen. Das erzeugt zwar initial ein paar Schmerzen wegen Wine,
PhotoLine, TheBat, 40tude Dialog, Sony Content Browser, Anbindung ans NAS
und - last not least - Sharing eines über USB lokal angeschlossenen
Kyocera-Druckers via Netzwerk an andere Linuxrechner.
Gibt es fuer den Drucker keinen Linux-Treiber?

Natürlich. Man sucht und findet ihn in irgendeiner staubigen Ecke bei
Kyocera, installiert den und druckt erfolgreich. Sodann Kopfkratzen, wie
man diesen lokal(!) per USB(!) am Rechner hängenden Drucker im Netzwerk
zugänglich macht. Für Dich ein Klacks, für mich als Linuxnovize schon eher
eine Herausforderung.

Volker
 
On Mon, 13 Dec 2021 10:39:47 +0100, Volker Bartheld wrote:
[Samsung 840 Evo schwächelt beim Empfang größerer Dateien]
Die 840er hat noch 75% \"Restlebensduer\", die 850er sogar noch 97%.

Rekapitulation: TRIM war auf der Platte aktiviert, ~60GB frei, Partition
korrekt ausgerichtet, AHCI. Bis vor kurzem unauffälliger, störungsfreier
Betrieb am SATA-2 Port meines ASUS P7P55D mit plausiblen
Übertragungsraten.

fstrim von der Linux-Stick erbrachte erwartungsgemäß um die 60GB an
freigegebenem Platz, allerdings keine relevante Änderung in der
Übertragungsgeschwindigkeit. Nach 50% und ca. 5GB sackt die Rate von
ehedem 250MByte/s auf unter 120MByte/s, teilweise sogar 50-60MB/s ab.

Ich habe dann zunächst die komische \"System Reserved\" Partion von Windows
entfernt [1], ein Backup gezogen, alle Partitionen gelöscht, SSD Secure
Erase unter Linux ausgeführt [2] (dieser Magician-Müll wird boykottiert)
und das Backup wieder aufgespielt.

Vielleicht hat die Aktion ein kleinwenig gebracht, die 120MB/s am Ende
eines 10GB-Transfers sind trotzdem inakzeptabel: bessere
Netzwerkgeschwindigkeit. Man muß also davon ausgehen, daß es die SSD
hinter sich hat, allen anderslautenden Aussagen der SMART-Parameter zum
Trotz.

Deswegen jetzt die nagelneue 860 Pro reindübeln, dort das Backup
draufspielen und sehen, ob sich die erwarteten Transferraten (wieder)
einstellen. Was ich hoffe, weil ein Problem mit irgendwelchen Treibern oder
gar dem SATA-Controller wäre unerfreulich. Sehr.

Volker


[1] https://kb.terabyteunlimited.com/kb-articles/how-to-remove-the-windows-system-reserved-partition/
[2] https://wiki.ubuntuusers.de/SSD/Secure-Erase/
 
On Tue, 14 Dec 2021 10:50:09 +0100, Gerrit Heitsch wrote:
On 12/14/21 10:26 AM, Volker Bartheld wrote:
Natürlich. Man sucht und findet ihn in irgendeiner staubigen Ecke bei
Kyocera, installiert den und druckt erfolgreich. Sodann Kopfkratzen, wie
man diesen lokal(!) per USB(!) am Rechner hängenden Drucker im Netzwerk
zugänglich macht. Für Dich ein Klacks, für mich als Linuxnovize schon eher
eine Herausforderung.
https://www.cups.org/doc/sharing.html könnte helfen.

Oh, Danke! Die Anleitung liest sich erstaunlich kurz und bündig. Dank
SAMBA-Support sollten eigentlich auch Windows-Clients kein Problem sein.
Das probiere ich gleich mal in (m)einer Linux-VM aus - sobald ich das
SSD-Problem aus Welt geschafft habe.

Volker
 
Am 13.12.21 um 10:39 schrieb Volker Bartheld:

Die 840er hat noch 75% \"Restlebensduer\", die 850er sogar noch 97%.
Das hatte ich auch mal.

Am Ende hat sich herausgestellt, dass ich die Werte aus dem smarttool
falsch verstanden hatte: statt der vermeintlichen 96% Restlebensdauer
waren es nur noch 4%. Die Platte war also zu 96% \"fertig\".

Terabytes-written war ein fantastisch hoher Wert, naja, jahrelange
Videobearbeitung halt.
 
On 12/14/21 1:59 AM, Volker Bartheld wrote:
On Tue, 14 Dec 2021 10:50:09 +0100, Gerrit Heitsch wrote:
On 12/14/21 10:26 AM, Volker Bartheld wrote:
Natürlich. Man sucht und findet ihn in irgendeiner staubigen Ecke bei
Kyocera, installiert den und druckt erfolgreich. Sodann Kopfkratzen, wie
man diesen lokal(!) per USB(!) am Rechner hängenden Drucker im Netzwerk
zugänglich macht. Für Dich ein Klacks, für mich als Linuxnovize schon eher
eine Herausforderung.

Linux-Neuling bin ich auch, mache das erst seit dem Abgesang von Windows
7 und als Nicht-Programmierer faellt mir das entsprechend schwer.
Inzwischen laeuft aber fast alles, was ich brauche. Das was nicht
laeuft, ist hauptsaechlich Windows-basierte Software, die ums Verplatzen
nicht in einer VM will und schon gar nicht mit WINE. Als Weg des
geringsten Widerstandes habe ich jetzt einen aelteren HP Pavilion hier,
der als Windows-only Kiste mit Remote Desktop ins LAN gehaengt werden
soll. Ohne Monitor und Keyboard.

Dieser HP bekommt eine simple Hyundai SSD mit 120GB. Nicht so edel wie
Samsung, aber sie muss dort auch nicht viel leisten. Ich muss dem
Windows 7 allerdings die elende Temp File Schreiberei abgewoehnen, damit
er die SSD nicht unnoetig verschleisst.


https://www.cups.org/doc/sharing.html könnte helfen.

Oh, Danke! Die Anleitung liest sich erstaunlich kurz und bündig. Dank
SAMBA-Support sollten eigentlich auch Windows-Clients kein Problem sein.

Samba ist manchmal so eine Sache. Funktioniert wochenlang und dann
ploetzlich nicht mehr.


Das probiere ich gleich mal in (m)einer Linux-VM aus - sobald ich das
SSD-Problem aus Welt geschafft habe.

Da hilft wohl nur eine neue.

--
Gruesse, Joerg

http://www.analogconsultants.com/
 
Am 14.12.21 um 10:53 schrieb Volker Bartheld:
Vielleicht hat die Aktion ein kleinwenig gebracht, die 120MB/s am Ende
eines 10GB-Transfers sind trotzdem inakzeptabel: bessere
Netzwerkgeschwindigkeit. Man muß also davon ausgehen, daß es die SSD
hinter sich hat, allen anderslautenden Aussagen der SMART-Parameter zum
Trotz.

Nein, aber du hast gerade die Funktionsweise eines SLC-Cache entdeckt. ;-)
Dessen Größe kann je nach Zustand bzw. Alterung auch dynamisch variieren.


Deswegen jetzt die nagelneue 860 Pro reindübeln, dort das Backup
draufspielen und sehen, ob sich die erwarteten Transferraten (wieder)
einstellen. Was ich hoffe, weil ein Problem mit irgendwelchen Treibern oder
gar dem SATA-Controller wäre unerfreulich. Sehr.

In der Consumer-Class wirst du das beschriebene Verhalten bei großen
Transfers /immer/ feststellen. Bei neuen zum Teil schlimmer als bei
alten. Die brechen z.T. noch wesentlich stärker ein. Im Neuzustand ggf.
weniger als im gebrauchten.


Marcel
 
On 12/14/21 9:17 PM, Joerg wrote:
On 12/14/21 1:59 AM, Volker Bartheld wrote:
On Tue, 14 Dec 2021 10:50:09 +0100, Gerrit Heitsch wrote:
On 12/14/21 10:26 AM, Volker Bartheld wrote:
Natürlich. Man sucht und findet ihn in irgendeiner staubigen Ecke bei
Kyocera, installiert den und druckt erfolgreich. Sodann Kopfkratzen,
wie
man diesen lokal(!) per USB(!) am Rechner hängenden Drucker im Netzwerk
zugänglich macht. Für Dich ein Klacks, für mich als Linuxnovize
schon eher
eine Herausforderung.


Linux-Neuling bin ich auch, mache das erst seit dem Abgesang von Windows
7 und als Nicht-Programmierer faellt mir das entsprechend schwer.
Inzwischen laeuft aber fast alles, was ich brauche. Das was nicht
laeuft, ist hauptsaechlich Windows-basierte Software, die ums Verplatzen
nicht in einer VM will und schon gar nicht mit WINE. Als Weg des
geringsten Widerstandes habe ich jetzt einen aelteren HP Pavilion hier,
der als Windows-only Kiste mit Remote Desktop ins LAN gehaengt werden
soll. Ohne Monitor und Keyboard.

Dieser HP bekommt eine simple Hyundai SSD mit 120GB. Nicht so edel wie
Samsung, aber sie muss dort auch nicht viel leisten. Ich muss dem
Windows 7 allerdings die elende Temp File Schreiberei abgewoehnen, damit
er die SSD nicht unnoetig verschleisst.


https://www.cups.org/doc/sharing.html  könnte helfen.

Oh, Danke! Die Anleitung liest sich erstaunlich kurz und bündig. Dank
SAMBA-Support sollten eigentlich auch Windows-Clients kein Problem sein.


Samba ist manchmal so eine Sache. Funktioniert wochenlang und dann
ploetzlich nicht mehr.

Kenne ich auch von SSH auf Windows. Der sshd läuft da wochenlang und auf
einmal nicht mehr, hängt dann beim Login. Und ja, es kann sinnvoll sein
sich in ein Windows-System per SSH einzuloggen.

Gerrit
 
On 12/14/21 12:36 PM, Gerrit Heitsch wrote:
On 12/14/21 9:17 PM, Joerg wrote:
On 12/14/21 1:59 AM, Volker Bartheld wrote:
On Tue, 14 Dec 2021 10:50:09 +0100, Gerrit Heitsch wrote:
On 12/14/21 10:26 AM, Volker Bartheld wrote:
Natürlich. Man sucht und findet ihn in irgendeiner staubigen Ecke bei
Kyocera, installiert den und druckt erfolgreich. Sodann
Kopfkratzen, wie
man diesen lokal(!) per USB(!) am Rechner hängenden Drucker im
Netzwerk
zugänglich macht. Für Dich ein Klacks, für mich als Linuxnovize
schon eher
eine Herausforderung.


Linux-Neuling bin ich auch, mache das erst seit dem Abgesang von
Windows 7 und als Nicht-Programmierer faellt mir das entsprechend
schwer. Inzwischen laeuft aber fast alles, was ich brauche. Das was
nicht laeuft, ist hauptsaechlich Windows-basierte Software, die ums
Verplatzen nicht in einer VM will und schon gar nicht mit WINE. Als
Weg des geringsten Widerstandes habe ich jetzt einen aelteren HP
Pavilion hier, der als Windows-only Kiste mit Remote Desktop ins LAN
gehaengt werden soll. Ohne Monitor und Keyboard.

Dieser HP bekommt eine simple Hyundai SSD mit 120GB. Nicht so edel wie
Samsung, aber sie muss dort auch nicht viel leisten. Ich muss dem
Windows 7 allerdings die elende Temp File Schreiberei abgewoehnen,
damit er die SSD nicht unnoetig verschleisst.


https://www.cups.org/doc/sharing.html  könnte helfen.

Oh, Danke! Die Anleitung liest sich erstaunlich kurz und bündig. Dank
SAMBA-Support sollten eigentlich auch Windows-Clients kein Problem sein.


Samba ist manchmal so eine Sache. Funktioniert wochenlang und dann
ploetzlich nicht mehr.

Kenne ich auch von SSH auf Windows. Der sshd läuft da wochenlang und auf
einmal nicht mehr, hängt dann beim Login. Und ja, es kann sinnvoll sein
sich in ein Windows-System per SSH einzuloggen.

Ich werde das demnaechst per RDP versuchen, von Linux aus auf einen
Windows Rechner zugreifend. In der Hoffung, dass das dann jahrelang
robust bleibt.

--
Gruesse, Joerg

http://www.analogconsultants.com/
 
On Mon, 13 Dec 2021 23:25:47 +0100, Bernd Mayer wrote:
Am 13.12.21 um 14:53 schrieb Volker Bartheld:
[SATA-Secure-Ease]
Fürs SATA-Secure-Erase braucht es dann aber auch wieder ein tolles (und vor
allem proprietäres) Tool?
manche PCs von Fujitsu haben das eingebaut.
EraseDisk
https://sp.ts.fujitsu.com/dmsp/Publications/public/ds-EraseDisk.pdf
Einige Hersteller von SSDs offenbar auch:
https://www.ssdblog.de/2014/10/13/ssd-secure-erase-mit-herstellertools/

Ich habs mit der Anleitung aus
https://wiki.ubuntuusers.de/SSD/Secure-Erase/
und meinem Linux Mint Mate vom Stick probiert, weil dieser Samsung
Magician ein Scheiß ist. Secure Erase hat exakt nach Anleitung
funktioniert, zu altem Glanz erstarkt ist die SSD dennoch nicht.

=> Wird ausgemustert und durch eine 860 Pro ersetzt.

Wenigstens tat mir die SSD den Gefallen, durch niedrige Performance auf
sich aufmerksam zu machen und hat nicht klammheimlich meine Daten
zerhackstückelt.

Volker
 
On Tue, 14 Dec 2021 21:31:42 +0100, Marcel Mueller wrote:
Am 14.12.21 um 10:53 schrieb Volker Bartheld:
Vielleicht hat die Aktion ein kleinwenig gebracht, die 120MB/s am Ende
eines 10GB-Transfers sind trotzdem inakzeptabel: bessere
Netzwerkgeschwindigkeit. Man muß also davon ausgehen, daß es die SSD
hinter sich hat, allen anderslautenden Aussagen der SMART-Parameter zum
Trotz.
Nein, aber du hast gerade die Funktionsweise eines SLC-Cache entdeckt. ;-)
Dessen Größe kann je nach Zustand bzw. Alterung auch dynamisch variieren.

Du willst sagen, die 840 Evo hat irgendwas um die xGB SLC Cache, der
wurde nun auf eine von mir meß- und fühlbare Größe runtergerockt und
deswegen verkacken die Transferraten nun schon bei ~2GB statt wie
früher bei >xxGB? Während die TBW bzw. Restlebensdauer im
SMART-Monitoring weiterhin komplett unauffällig sind, weil sie sich nur
auf den MLC-Anteil der SSD beziehen?

Das kann natürlich sein und würde durchaus zu den Beobachtungen passen.

Deswegen jetzt die nagelneue 860 Pro reindübeln, dort das Backup
draufspielen und sehen, ob sich die erwarteten Transferraten (wieder)
einstellen. Was ich hoffe, weil ein Problem mit irgendwelchen Treibern oder
gar dem SATA-Controller wäre unerfreulich. Sehr.

In der Consumer-Class wirst du das beschriebene Verhalten bei großen
Transfers /immer/ feststellen.

Na, sagen wir so: Profesioneller als mit der 860 Pro wird\'s bei Samsung
eher nicht mehr, wenn man mal von der utopisch großen und teuren 860
DCT absieht. Und wenn das Dingens wieder 8+ Jahre hält, dann isses ja
gut. Alldieweil es mich angesichts von...

> Bei neuen zum Teil schlimmer als bei alten.

.... an Stellen juckt, an denen ich mich nicht kratzen kann. Also mal
sehen.

Volker

P.S.: Wenn mir ein Hersteller erklärt, sein Laufwerk hätte eine
kontinuierliche Transfergeschwindigkeit von - sagen wir - 300MB/s, dann
erwarte ich, daß die beibehalten wird, bis das Teil voll ist. In...

https://www.compuram.de/documents/datasheet/Samsung_SSD_840_EVO_Brochure_2.pdf

.... ist natürlich die Rede von \"Max. 540MB/s\", die Angabe kann man also
getrost vergessen. Nun beträgt aber die an anderer Stelle etwas
verschämt in Mbps angegebene native Transferrate des Flash 400Mbps
(~50MB/s), d. h. auch nicht, was ich initial sehe. Und die 256MB DRAM
Cache der 120GB Variante sind im Nu voll.

Wenn die Platte also >1GB mit um die 250MB/s durchhält, muß es noch
einen anderen, in den Specs nicht erwähnten Cache geben, der diese
Performance hat. Keine Ahnung, ob ein SLC so schnell ist. Aber
entsprechende SD-Karten schaffen zumindest deutlich über 100MB/s.
 
Hallo Volker Bartheld,

Du schriebst am Wed, 15 Dec 2021 09:54:42 +0100:

Wenigstens tat mir die SSD den Gefallen, durch niedrige Performance
auf sich aufmerksam zu machen und hat nicht klammheimlich meine Daten
zerhackstückelt.

Haste das nachgeprüft oder vermuteste das bloß?
(Nachprüfung z.B. gegen _ältestes_ Backup, das verfügbar und nicht
hoffnungslos überholt ist.)

--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------
 
On Thu, 16 Dec 2021 00:51:39 +0100, Sieghard Schicktanz wrote:
Du schriebst am Wed, 15 Dec 2021 09:54:42 +0100:
Wenigstens tat mir die SSD den Gefallen, durch niedrige Performance
auf sich aufmerksam zu machen und hat nicht klammheimlich meine Daten
zerhackstückelt.
Haste das nachgeprüft oder vermuteste das bloß?

Anhand einer Stichprobe.

Volker
 
Am 15.12.21 um 10:27 schrieb Volker Bartheld:
Nein, aber du hast gerade die Funktionsweise eines SLC-Cache entdeckt. ;-)
Dessen Größe kann je nach Zustand bzw. Alterung auch dynamisch variieren.

Du willst sagen, die 840 Evo hat irgendwas um die xGB SLC Cache, der
wurde nun auf eine von mir meß- und fühlbare Größe runtergerockt und
deswegen verkacken die Transferraten nun schon bei ~2GB statt wie
früher bei >xxGB? Während die TBW bzw. Restlebensdauer im
SMART-Monitoring weiterhin komplett unauffällig sind, weil sie sich nur
auf den MLC-Anteil der SSD beziehen?

Sowas in der Art stand zumindest im c\'t Bericht über SSDs vor ein paar
Monaten. Das war ein ziemlich ausführlicher Artikel, indem die
verschiedenen Strategien der Hersteller mit ihren jeweiligen Vor- und
Nachteilen aufgeführt waren. Ich weiß leider die genaue Ausgabe nicht mehr.
Ob es genau für /dieses/ Modell mit dieser Firmware gilt, ist natürlich
das Geheimnis des Herstellers. Solche Angaben finden sich nur äußerst
selten bis gar nicht.

Alles ab MLC/TLC/QLC wurde beim Schreiben halt immer langsamer, und dazu
gehört die EVO definitiv. AFAIK war sie sogar schon TLC. Und je öfter
die Flash-Zellen schon gelöscht wurden desto langsamer werden sie.
Und da macht man halt allerlei Tricks, um den Biestern in der Praxis
oder besser noch im Benchmark Beine zu machen. Tatsächlich hilft das
sogar in der Praxis oft, aber es hat eben auch Grenzen.

AFAIR hatten die 840 EVO aber auch noch ganz andere Probleme. Da gab es
wohl Versionen, wo die Firmware ziemlich buggy war. Und das äußerte sich
auch in Verlangsamung. Da musste man erst mal eine gescheite Firmware
aufspielen, und da hatte wohl in manchen Fällen den Verlust aller Daten
zur Folge, oder aber die Erholung trat erst nach vollständigem Löschen
ein, weil die alte Firmware die Verwaltungs-Datenstrukturen so
beschädigt hatte. So zumindest meine dunkle Erinnerung.

Ich habe noch eine der ersten 840 ohne EVO. Die waren noch MLC. Und da
gab es keine (bekannten) Firmwareprobleme.


Das kann natürlich sein und würde durchaus zu den Beobachtungen passen.

Deswegen jetzt die nagelneue 860 Pro reindübeln, dort das Backup
draufspielen und sehen, ob sich die erwarteten Transferraten (wieder)
einstellen. Was ich hoffe, weil ein Problem mit irgendwelchen Treibern oder
gar dem SATA-Controller wäre unerfreulich. Sehr.

In der Consumer-Class wirst du das beschriebene Verhalten bei großen
Transfers /immer/ feststellen.

Na, sagen wir so: Profesioneller als mit der 860 Pro wird\'s bei Samsung
eher nicht mehr, wenn man mal von der utopisch großen und teuren 860

Ja, bei Samsung ist da Schluss. Und im allgemeinen sind die Samsungs ja
auch mit unter den besten in der Consumerclass. Solange man da nicht das
Transaktionslog der Datenbank darauf parkt, überleben die im Schnitt
recht lange. Gegen die vor allem in der Anfangszeit der TLCs allgemein
recht verbreiteten Firmwarebugs hilft das freilich nicht.


DCT absieht. Und wenn das Dingens wieder 8+ Jahre hält, dann isses ja
gut. Alldieweil es mich angesichts von...

Bei neuen zum Teil schlimmer als bei alten.

... an Stellen juckt, an denen ich mich nicht kratzen kann. Also mal
sehen.

Ja klar ist das Gemecker auf Niveau.

Ich meine die Dreheisen waren Jahrzehnte lang das Bottleneck in nahezu
jedem Rechner, zumal sich ihre Gschwindligkeit kaum entwickelt hat -
con Benchmarks einmal abgesehen.
Und das galt sogar für die richtig schnellen Modelle. Ich hatte die
letzte Platte mit <7200 UpM AFAIK in den frühen 90ern gekauft und zum
Schluss alles 10k oder sogar 15k im PC. Trotzdem war das oft der
Engpass. Als ich in dem schon gut abgehangenen Rechner damals die
15k-Platte gegen eine Intel Postville G2 SSD getauscht habe, die noch
dazu am IDE/SATA Adapter hing, wurde die Kiste gefühlt nochmal 30%
schneller.

Ich kaufe seit über 10 Jahren ausschließlich SSDs - nur eine
Constellation ES aus einer alten Clariion dreht noch zeitweise als
Filmarchiv. Und ich kann nur sagen, es gab in meiner ganzen
Computerlaufbahn nie eine einzelne Komponente, die die Rechner so
preiswert beschleunigt hat, wie eine SSD. Und damit schließe ich die
Anfangszeit, wo man für über 100 ¤ nur wenige Dutzend GB bekommen hat
explizit mit ein. So ein Ding in den VM-Server und für jede VM ein paar
GB für das nötigste zur Verfügung stellen, und die VMs laufen gefühlt
alle 4-mal so schnell.
Sobald ich irgendeinen Gebrauchtrechner oder -Laptop in die Finger
bekomme, habe ich als erstes die Platte rausgeschmissen und durch eine
günstige SSD ersetzt. Für gut 20¤ bekommt man seit einigen Jahren
jeweils genug Platz für das Wesentliche.

Von den SSDs ist mir auch noch nie eine verreckt, und die sind alle
Consumerclass. Allerdings habe ich immer von den Chip-Herstellern
gekauft und Reseller gemieden; also Intel, Samsung, Micron. Einzige
Ausnahme sind die Billigdinger für Altrechner. Da habe ich Kingston
genommen, die zwar Nonameware verkaufen, aber für eine relativ gute
Qualitätssicherung bekannt sind - weniger für ihre Geschwindigkeit. Aber
das ist mir sowieso egal, denn jede noch so langsame SSD ist im
Alltagseinsatz 100-mal Schneller als jede Platte.

Die alte Postville habe ich jetzt im PC - mehr als die 35GB brauche ich
da sowieso nicht, wenn die wesentlichen Daten auf dem Server liegen. Mal
sehen, wie lange sie noch macht. ;-)


P.S.: Wenn mir ein Hersteller erklärt, sein Laufwerk hätte eine
kontinuierliche Transfergeschwindigkeit von - sagen wir - 300MB/s, dann
erwarte ich, daß die beibehalten wird, bis das Teil voll ist. In...

Nein. Das gab es noch nie. Also ich meine, dass mit 300MB/s /sustained
write/ geworben wurde. Die geben immer nur max write und vielleicht
sustained reaad an. Die wissen schon warum.

> https://www.compuram.de/documents/datasheet/Samsung_SSD_840_EVO_Brochure_2.pdf

Da steht auch nichts von kontinuierlich. Das ist Wunschdenken.

... ist natürlich die Rede von \"Max. 540MB/s\", die Angabe kann man also
getrost vergessen. Nun beträgt aber die an anderer Stelle etwas
verschämt in Mbps angegebene native Transferrate des Flash 400Mbps
(~50MB/s), d. h. auch nicht, was ich initial sehe. Und die 256MB DRAM
Cache der 120GB Variante sind im Nu voll.

Die Größe der SSD hat noch wesentlichen Einfluss auf die Geschwindigkeit
und auch darauf, wie schnell sie einbricht. Die Controller sind nämlich
im allgemeinen so schlau, die geschriebenen Daten gleichmäßig auf alle
vorhandenen Flash-Chips zu verteilen, wodurch sich die Datenraten
multiplizieren.

Wenn die Platte also >1GB mit um die 250MB/s durchhält, muß es noch
einen anderen, in den Specs nicht erwähnten Cache geben, der diese
Performance hat. Keine Ahnung, ob ein SLC so schnell ist.

Ja, ist es.
Das ist auch kein dedizierter Cache, man schreibt einfach in dieselben
Speicherzellen als SLC, also schnell und unsauber, aber eben so, dass
man nur 2 Zustände unterscheiden muss und nicht 4, 8 oder 16.

Aber
entsprechende SD-Karten schaffen zumindest deutlich über 100MB/s.

.... und verrecken dabei im Eiltempo. Es gibt kaum was unzuverlässigeres.
Jedenfalls wenn man sie mit vergleichbaren Schreibraten wie eine SSD
tracktiert.


Marcel
 
On Thu, 16 Dec 2021 08:03:49 +0100, Marcel Mueller wrote:
Am 15.12.21 um 10:27 schrieb Volker Bartheld:
Nein, aber du hast gerade die Funktionsweise eines SLC-Cache entdeckt. ;-)
Dessen Größe kann je nach Zustand bzw. Alterung auch dynamisch variieren.
Du willst sagen, die 840 Evo hat irgendwas um die xGB SLC Cache, der
wurde nun auf eine von mir meß- und fühlbare Größe runtergerockt und
deswegen verkacken die Transferraten nun schon bei ~2GB statt wie
früher bei >xxGB?

Sowas in der Art stand zumindest im c\'t Bericht über SSDs vor ein paar
Monaten.

Interessant. Vielleicht erinnert ja wer die konkrete Ausgabe, dann besorge
ich mir die.

Alles ab MLC/TLC/QLC wurde beim Schreiben halt immer langsamer, und dazu
gehört die EVO definitiv. AFAIK war sie sogar schon TLC.

Nach meinen Erkenntnissen eine MLC mit drei Bits je Zelle oder volkstümlich
TLC [1].

AFAIR hatten die 840 EVO aber auch noch ganz andere Probleme. Da gab es
wohl Versionen, wo die Firmware ziemlich buggy war.

Das leidige Problem mit den slow reads bei alten Daten [2] für dessen
Lösung Samsung zwei Anläufe brauchte. Trat bei mir nicht auf, da ich gerne
mal ein Backup zurückspiele und die Daten deswegen \"frisch\" sind.

In der Consumer-Class wirst du das beschriebene Verhalten bei großen
Transfers /immer/ feststellen.
Profesioneller als mit der 860 Pro wird\'s bei Samsung
eher nicht mehr
Ja, bei Samsung ist da Schluss. Und im allgemeinen sind die Samsungs ja
auch mit unter den besten in der Consumerclass.

Eben. Das war Gegenstand meiner Kaufentscheidung.

Ich meine die Dreheisen waren Jahrzehnte lang das Bottleneck in nahezu
jedem Rechner, zumal sich ihre Gschwindligkeit kaum entwickelt hat -
Sobald ich irgendeinen Gebrauchtrechner oder -Laptop in die Finger
bekomme, habe ich als erstes die Platte rausgeschmissen und durch eine
günstige SSD ersetzt.
Von den SSDs ist mir auch noch nie eine verreckt, und die sind alle
Consumerclass. Allerdings habe ich immer von den Chip-Herstellern
gekauft und Reseller gemieden

Genau so schauts aus und letztlich genau das, was ich Herrn Schellong
geschrieben habe. SSDs haben ihre ganz eigenen Probleme (wieder was
dazugelernt), denen man begegnen muß. Einen generellen Grund, SSDs _nicht_
in einem PC zu verwenden, gibt es für mich nicht. Ich finds schade, daß ich
jetzt möglicherweise den EeePC nur wegen der Nichtverfügbarkeit brauchbarer
Akkus wegschmeißen muß, denn mit einer 250er Samsung SSD war selbst der
olle Intel Atom mit einer moderat aktuellen Version von Linux Mint im
Praxisgebrauch vollkommen akzeptabel einzusetzen. Also surfen, mal ein
Dokument bearbeiten, Bilder und Filme gucken, e-Mail, Navigation, usw.

Wenn die Platte also >1GB mit um die 250MB/s durchhält, muß es noch
einen anderen, in den Specs nicht erwähnten Cache geben, der diese
Performance hat. Keine Ahnung, ob ein SLC so schnell ist.
Ja, ist es.
Das ist auch kein dedizierter Cache, man schreibt einfach in dieselben
Speicherzellen als SLC, also schnell und unsauber

Puh. Magie also. ;-)

Aber entsprechende SD-Karten schaffen zumindest deutlich über 100MB/s.
... und verrecken dabei im Eiltempo. Es gibt kaum was unzuverlässigeres.
Jedenfalls wenn man sie mit vergleichbaren Schreibraten wie eine SSD
tracktiert.

Das war auch nur als Beispiel dafür gedacht, daß es kein prinzipielles
Problem darstellen sollte, für irgendeinen Cache in irgendeiner SSD einen
auf Flash basierenden Speicher zu basteln, der 100MB/s abkann. Meine
SD-Karten für Foto und Film stammen von SanDisk (meist die Extreme Pro),
bislang keine Auffälligkeiten. Ich habe an der Knipse auch Transcend im
Einsatz, ebenfalls (noch) OK.

Volker

[1] https://www.anandtech.com/show/7173/samsung-ssd-840-evo-review-120gb-250gb-500gb-750gb-1tb-models-tested
[2] https://techreport.com/review/27212/samsungs-840-evo-update-fixes-slow-reads-with-old-data/
 
Am 16.12.21 um 08:03 schrieb Marcel Mueller:

Nein. Das gab es noch nie. Also ich meine, dass mit 300MB/s /sustained
write/ geworben wurde. Die geben immer nur max write und vielleicht
sustained reaad an. Die wissen schon warum.

Ich hatte eine Zeit lang 4 gestripede WD Raptors, à 70 GB mit
einem extra PCI Controller mit Cache.
Das Ding kam auf 500 MB/sec durch das Linux-Filesystem,
war aber unerträglich laut.

Die Raptors gab\'s auch mit weniger Drehzahl & 4-facher Größe.
Halt deutlich langsamer und unter anderem Namen.

Gerhard
 
Am 16.12.21 um 07:56 schrieb Volker Bartheld:

Wenigstens tat mir die SSD den Gefallen, durch niedrige Performance
auf sich aufmerksam zu machen und hat nicht klammheimlich meine Daten
zerhackstückelt.
Haste das nachgeprüft oder vermuteste das bloß?

Anhand einer Stichprobe.

Der hier sicherlich mit lesende Gerrit hatte mal das Problem, daß eine
längere Zeit (dreiviertel Jahr oder so) unbenutzt gelagerte noname-SSD
bei manchen Dateien Grütze zurückgab, ohne jegliche Fehlermeldung. Ob
man das bei Stichproben merkt ist dann halt Glückssache.

Andererseits gehe ich bei Samsung schon davon aus, daß die eine
vernünftige Fehlerbehandlung bei Leseproblemen haben. Dennoch...

Hanno

--
The modern conservative is engaged in one of man\'s oldest exercises in
moral philosophy; that is, the search for a superior moral justification
for selfishness.
- John Kenneth Galbraith
 
On 12/16/21 10:29 AM, Hanno Foest wrote:
Am 16.12.21 um 07:56 schrieb Volker Bartheld:

Wenigstens tat mir die SSD den Gefallen, durch niedrige Performance
auf sich aufmerksam zu machen und hat nicht klammheimlich meine Daten
zerhackstückelt.
Haste das nachgeprüft oder vermuteste das bloß?

Anhand einer Stichprobe.

Der hier sicherlich mit lesende Gerrit hatte mal das Problem, daß eine
längere Zeit (dreiviertel Jahr oder so) unbenutzt gelagerte noname-SSD
bei manchen Dateien Grütze zurückgab, ohne jegliche Fehlermeldung. Ob
man das bei Stichproben merkt ist dann halt Glückssache.

Ja... und deshalb unterziehe ich eines meiner Backups (jedesmal ein
anderes) alle paar Monate einem vollen Verify. Dauert mehr ein paar
Tags, aber danach weiss ich woran ich bin.

Die fragliche SSD habe ich noch, aber inzwischen meldet sie sich gar
nicht mehr. Hatten die vielleicht die eigene Firmware auch im Flash?

Gerrit
 
On Thu, 16 Dec 2021 10:49:55 +0100, Gerrit Heitsch wrote:
On 12/16/21 10:29 AM, Hanno Foest wrote:
Am 16.12.21 um 07:56 schrieb Volker Bartheld:
Wenigstens tat mir die SSD den Gefallen, durch niedrige Performance
auf sich aufmerksam zu machen und hat nicht klammheimlich meine Daten
zerhackstückelt.
Haste das nachgeprüft oder vermuteste das bloß?
Anhand einer Stichprobe.
Der hier sicherlich mit lesende Gerrit hatte mal das Problem, daß eine
längere Zeit (dreiviertel Jahr oder so) unbenutzt gelagerte noname-SSD
bei manchen Dateien Grütze zurückgab, ohne jegliche Fehlermeldung.

Irgendwas ist ja immer, man kann es sicher auch übertreiben. Das Thema
\"SSD als Offlinespeicher\" hatten wir ja schon, ich mache sowas aus
guten Gründen nicht.

>> Ob man das bei Stichproben merkt ist dann halt Glückssache.

Jup.

Ja... und deshalb unterziehe ich eines meiner Backups (jedesmal ein
anderes) alle paar Monate einem vollen Verify.

Womit bzw. gegen welche Referenz? Dein in Betrieb befindliches OS (und
darum ging es bei mir konkret) hat sich natürlich bereits vom Backup
wegentwickelt. Updates, temporäre Dateien, Logs, usw. Ähnlich wird es
bei archivierten Backups zu unterschiedlichen Zeitpunkten sein. Also
mußt Du irgendwelche Prüfsummen für Dateien erstellen und verifizieren.
Ich vertraue dabei auf mein NAS und die Macht von BTRFS. Natürlich
werden die Volumes das NAS regelmäßig auf externe Drehplatten (im
USB-3.0-Gehäuse) gespielt.

Jetzt kann man reichlich akademisch werden und anmerken, daß natürlich
auch Festplatten und die beteiligten Controller eine von Null
verschiedene Rate nicht wiederherstellbarer Fehler und sogar nicht
wiederherstellbarer UND unentdeckter Fehler haben. Außerdem kannst Du
nicht sicher ausschließen, ob Du möglicherweise Müll wegspeicherst,
selbst als stolzer Eigentümer von ECC-RAM.

Ich erinnere da an ein Problem im Chipsatz von IIRC Athlon-Boards, der
bei DMA-Transfers großer Dateien Fehler eingebaut hat. Ob der
DMA-Controller Prüfsummen gezogen hat? Nein. Und gegen den guten alten
FDIV-Bug ist bzw. war auch kein Kraut gewachsen. Man fand es halt durch
Zufall irgendwann raus.

Zurück zu meiner schwächelnden Samsung 840 EVO. Inzwischen habe ich die
860 PRO eingebaut und erfolgreich in Betrieb genommen.

Vorher natürlich ein Backup der Bootpartition, das gestaltete sich mit
der Runtime-Live-CD http://www.runtime.org/data-recovery-live-cd.htm
und dem darauf befindlichen DriveImage XML vollkommen unkompliziert.
Ich habe dann die Festplatten getauscht, von der
Windows-Wiederherstellungs-CD gebootet und

diskpart.exe
SEL DISK 0
CREATE PARTITION PRIMARY
SEL PART 1
FORMAT FS=NTFS QUICK OVERRIDE LABEL=\"BOOT\"
ACTIVE

ausgeführt, um die Partition zu erstellen, denn DriveImage XML hätte
gerne eine fertige Partition. Danach mit der Runtime-CD die Daten auf
diese Partition zurückspielen. Sodann (leider) nochmal die
Windows-Wiederherstellungs-CD booten und irgendwas reparieren, denn
Windows beschwert sich aus unerfindlichen Gründen über ein nicht
existentes Bootmedium. Vermutlich war irgendwo eine Device-ID
hinterlegt.

Sodann regulär von der SSD booten, fertig, angenehmer Alltag. Natürlich
gibts da sicher auch was von Ratiopharm bzw. eine All-in-One-Lösung mit
Linux, gparted & Co - ich war aber zu faul, mir was zu basteln.

Die neue 860 Pro hält 250MB/s über Transfers mit zweistelligen GB, so
erwarte ich das an einem SATA-2-Port. Und da auf dem Ding nun
verschwenderische 205 von 250GB frei sind, sollte genug Platz für
irgendwelche Schweinereien sein, die Samsung mit den Sektoren
veranstaltet.

Die nun vakante 840er werde ich vielleicht im externen USB-Dock noch
einer eingehenden Prüfung unterziehen und dann entweder in den
DVB-Receiver oder sonst ein Gerät einbauen, wo es auf derart hohe
Transferraten nicht sonderlich ankommt.

Wie sagt der Amerikaner doch so schön: Again what learned.

Volker
 

Welcome to EDABoard.com

Sponsor

Back
Top