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

[Volker Bartheld]

Hallo!

Moderat themaverfehlend aber vielleicht dennoch interessant für den einen
oder anderen hierzugroups.

Wir hatten ja die Diskussion über SSDs, deren Zuverlässigkeit, Lebensdauer,
TBW, usw., usf. Gestern auf meinem PC recht merkwürdiges Verhalten,
Transfers vom NAS (1+1GBit/s, Link Aggregation) rasten erst mit über
100MB/s los, um dann nach einigen Sekunden plötzlich mehr und mehr zu
schwächeln - bis hin zu recht ernüchternden Datenraten, die schon einem
besseren USB-Stick die Schamesröte ins Gesicht treiben würden.

Natürlich hatte ich erst den Switch im Verdacht, ein kürzlich hinzugefügter
DGS-108 von D-Link. Man kennt ja seine Pappenheimer. Danach schaute ich
dem NAS genauer auf die Finger. Schließlich konnte ich das Verhalten
selbst an exakt demselben Port mit exakt demselben Kabel aber auf dem
Windows-10-Laptop nicht verifizieren.

Also der PC, der altgediente und zuverlässige ASUS P7P55D mit Core i7
Prozessor. Na supi, das hatte mir ja gerade noch gefehlt!

Weitere Experimente mit

fsutil file createnew d:\\temp\\test1 10000000000
fsutil file createnew c:\\temp\\test2 10000000000
robocopy d:\\temp c:\\temp test1
robocopy c:\\temp d:\\temp test2

(Linux, Windows Explorer, Total Commander, rsync, usw. sinngemäß) ergaben,
daß das Problem nur beim Übertragen großer Dateien von d: nach c: auftrat,
nicht aber andersherum.

Hinter dem Mountpoint C verbirgt sich eine Samsung 840 Evo mit 120GB, D ist
eine Samsung 850 Evo mit 500GB. Natürlich jeweils aktuelle Firmware (da
gabs mal was mit lahmen Transferraten bei selten genutzten Dateien), Test
mit HWinfo und SMART-Parameter unauffällig, keine Einträge in
irgendwelchen Fehlerprotokollen, der TRIM-Befehl und AHCI sind aktiviert,
Partition-Alignment stimmt.

Die 840er hat noch 75% \"Restlebensduer\", die 850er sogar noch 97%.

Nachdem ich das Verhalten unter Windows 7 hart reproduzieren kann (Test mit
einem Live-Linux steht noch aus, obwohl ich es für einigermaßen abwegig
haltet, daß die Auffälligkeit vom Betriebssystem abhängt), werde ich das
OS nebst Programmen also auf eine für derartig besondere Anlässe
bereitgehaltene 860 Pro rüberklonen und diese stattdessen einbauen, bevor
ich weitere Experimente wie Neuformatierung, usw. veranstalte.

Schon merkwürdig.

Volker

P.S.: Natürlich gibt es Backups. Schwitzflecken unter den Achseln habe ich
deswegen nicht.

 

[Arno Welzel]

Volker Bartheld:

[...]

(Linux, Windows Explorer, Total Commander, rsync, usw. sinngemäß) ergaben,
daß das Problem nur beim Übertragen großer Dateien von d: nach c: auftrat,
nicht aber andersherum.

Was dann ja ein recht klares Indiz ist, dass das Laufwerk für c: keine
hohe Schreibrate hat.

Hinter dem Mountpoint C verbirgt sich eine Samsung 840 Evo mit 120GB, D ist
eine Samsung 850 Evo mit 500GB. Natürlich jeweils aktuelle Firmware (da

Die 840 Evo mit 128 GB dürfte schon etliche Jahre alt sein
(Markteinführung war 2013) und keine ungenutzten Blöcke mehr haben.

Jeder bereits genutzte Block muss bei Schreibzugriffen erstmal komplett
ausgelesen, gelöscht und dann wieder zurückgeschrieben werden. Wenn noch
etwas Platz frei ist, besteht die Chance, dass man noch leere Blöcke hat
und sich den Schritt \"Block löschen\" sparen kann - aber das muss nicht
so sein.

[...]

Nachdem ich das Verhalten unter Windows 7 hart reproduzieren kann (Test mit
einem Live-Linux steht noch aus, obwohl ich es für einigermaßen abwegig
haltet, daß die Auffälligkeit vom Betriebssystem abhängt), werde ich das
OS nebst Programmen also auf eine für derartig besondere Anlässe
bereitgehaltene 860 Pro rüberklonen und diese stattdessen einbauen, bevor
ich weitere Experimente wie Neuformatierung, usw. veranstalte.

Schon merkwürdig.

Nein, eher das normale Verhalten, wenn günstigere SSDs schon länger in
Verwendung sind.


--
Arno Welzel
https://arnowelzel.de

 

[Gerrit Heitsch]

On 12/13/21 12:34 PM, Arno Welzel wrote:

Volker Bartheld:

[...]
(Linux, Windows Explorer, Total Commander, rsync, usw. sinngemäß) ergaben,
daß das Problem nur beim Übertragen großer Dateien von d: nach c: auftrat,
nicht aber andersherum.

Was dann ja ein recht klares Indiz ist, dass das Laufwerk für c: keine
hohe Schreibrate hat.

Hinter dem Mountpoint C verbirgt sich eine Samsung 840 Evo mit 120GB, D ist
eine Samsung 850 Evo mit 500GB. Natürlich jeweils aktuelle Firmware (da

Die 840 Evo mit 128 GB dürfte schon etliche Jahre alt sein
(Markteinführung war 2013) und keine ungenutzten Blöcke mehr haben.

Jeder bereits genutzte Block muss bei Schreibzugriffen erstmal komplett
ausgelesen, gelöscht und dann wieder zurückgeschrieben werden. Wenn noch
etwas Platz frei ist, besteht die Chance, dass man noch leere Blöcke hat
und sich den Schritt \"Block löschen\" sparen kann - aber das muss nicht
so sein.

Eigentlich hatte man dafür TRIM implementiert... Setzt natürlich voraus,
daß da freier Platz ist.

Gerrit

 

[Volker Bartheld]

On Mon, 13 Dec 2021 12:52:12 +0100, Gerrit Heitsch wrote:

On 12/13/21 12:34 PM, Arno Welzel wrote:
Volker Bartheld:
(Linux, Windows Explorer, Total Commander, rsync, usw. sinngemäß) ergaben,
daß das Problem nur beim Übertragen großer Dateien von d: nach c: auftrat,
nicht aber andersherum.
Was dann ja ein recht klares Indiz ist, dass das Laufwerk für c: keine
hohe Schreibrate hat.

Das will ich meinen.

Hinter dem Mountpoint C verbirgt sich eine Samsung 840 Evo mit 120GB, D ist
eine Samsung 850 Evo mit 500GB. Natürlich jeweils aktuelle Firmware (da
Die 840 Evo mit 128 GB dürfte schon etliche Jahre alt sein
(Markteinführung war 2013) und keine ungenutzten Blöcke mehr haben.

Möglich.

Jeder bereits genutzte Block muss bei Schreibzugriffen erstmal komplett
ausgelesen, gelöscht und dann wieder zurückgeschrieben werden. Wenn noch
etwas Platz frei ist, besteht die Chance, dass man noch leere Blöcke hat
und sich den Schritt \"Block löschen\" sparen kann - aber das muss nicht
so sein.
Eigentlich hatte man dafür TRIM implementiert... Setzt natürlich voraus,
daß da freier Platz ist.

TRIM ist aktiviert (zuminmdest antwortet mir fsutil behavior query
DisableDeleteNotify mit 0), auf der 840 sind 70 von 120GB frei. Ich hatte
naiverweise angenommen, das kleine Wunderding könnte sich dann
einigermaßen zuverlässig um sich selbst kümmern, ohne daß Papi immer mal
wieder durchputzen muß.

Was also nun tun? Neuformatierung? Samsung Magician? Und wie Derartiges in
Zukunft vermeiden? Nein, defrag /o ist keine Option auf Windows 7.

Volker

 

[Gerrit Heitsch]

On 12/13/21 1:32 PM, Volker Bartheld wrote:

On Mon, 13 Dec 2021 12:52:12 +0100, Gerrit Heitsch wrote:
On 12/13/21 12:34 PM, Arno Welzel wrote:
Volker Bartheld:
(Linux, Windows Explorer, Total Commander, rsync, usw. sinngemäß) ergaben,
daß das Problem nur beim Übertragen großer Dateien von d: nach c: auftrat,
nicht aber andersherum.
Was dann ja ein recht klares Indiz ist, dass das Laufwerk für c: keine
hohe Schreibrate hat.

Das will ich meinen.

Hinter dem Mountpoint C verbirgt sich eine Samsung 840 Evo mit 120GB, D ist
eine Samsung 850 Evo mit 500GB. Natürlich jeweils aktuelle Firmware (da
Die 840 Evo mit 128 GB dürfte schon etliche Jahre alt sein
(Markteinführung war 2013) und keine ungenutzten Blöcke mehr haben.

Möglich.

Jeder bereits genutzte Block muss bei Schreibzugriffen erstmal komplett
ausgelesen, gelöscht und dann wieder zurückgeschrieben werden. Wenn noch
etwas Platz frei ist, besteht die Chance, dass man noch leere Blöcke hat
und sich den Schritt \"Block löschen\" sparen kann - aber das muss nicht
so sein.
Eigentlich hatte man dafür TRIM implementiert... Setzt natürlich voraus,
daß da freier Platz ist.

TRIM ist aktiviert (zuminmdest antwortet mir fsutil behavior query
DisableDeleteNotify mit 0), auf der 840 sind 70 von 120GB frei. Ich hatte
naiverweise angenommen, das kleine Wunderding könnte sich dann
einigermaßen zuverlässig um sich selbst kümmern, ohne daß Papi immer mal
wieder durchputzen muß.

Wenn du dem OS erlaubt hast TRIM zu verwenden, dann sollte das so sein,
ja. Ich hab das hier mit Underprovisionung gelöst, also von den 256 GB
meiner SSD nur 220 GB überhaupt verwendet. Der Rest ist in keiner
Partition enthalten. Damit hat sie immer einen Pool ungenutzter Blöcke
wenn die Firmware so schlau ist, einen Block, den sie gerade durch einen
aus dem freien Pool ersetzt hat, automatisch zu löschen. Scheint bei
meinen SSDs von Crucial und WDC bisher zu funktionieren.

Es gibt auch eine Möglichkeit TRIM on Hand auszulösen. Befehl unter
Linux dazu ist \'fstrim\' wenn ich das noch richtig weiss.

Was also nun tun? Neuformatierung? Samsung Magician? Und wie Derartiges in
Zukunft vermeiden? Nein, defrag /o ist keine Option auf Windows 7.

Wenn der Hersteller nicht komplett gepennt hat sollte ein
SATA-Secure-Erase alle Blocks löschen. Dann das Image vom Backup wieder
drauf.

Gerrit

 

[Volker Bartheld]

On Mon, 13 Dec 2021 14:33:28 +0100, Gerrit Heitsch wrote:

[Samsung 840 Evo lahmt beim Empfang größeren Dateien]
On 12/13/21 1:32 PM, Volker Bartheld wrote:
TRIM ist aktiviert (zuminmdest antwortet mir fsutil behavior query
DisableDeleteNotify mit 0), auf der 840 sind 70 von 120GB frei. Ich hatte
naiverweise angenommen, das kleine Wunderding könnte sich dann
einigermaßen zuverlässig um sich selbst kümmern
Wenn du dem OS erlaubt hast TRIM zu verwenden, dann sollte das so sein,

*seufz*

Es gibt auch eine Möglichkeit TRIM on Hand auszulösen. Befehl unter
Linux dazu ist \'fstrim\' wenn ich das noch richtig weiss.

Ich könnte dazu natürlich fix Ubuntu vom Stick booten. Ist das egal, wenn
auf der verbauten Platte ein NTFS-Dateisystem drauf ist?

Was also nun tun? Neuformatierung? Samsung Magician? Und wie Derartiges in
Zukunft vermeiden? Nein, defrag /o ist keine Option auf Windows 7.

Wenn der Hersteller nicht komplett gepennt hat sollte ein
SATA-Secure-Erase alle Blocks löschen. Dann das Image vom Backup wieder
drauf.

Fürs SATA-Secure-Erase braucht es dann aber auch wieder ein tolles (und vor
allem proprietäres) Tool? Bin ja gespannt, wie diese Self-Encrypting-SSDs
das lösen. Dort wird ja nur der eingangs zufällig erzeugte Schlüssel
\"vergessen\", die - zwar nicht lesbaren - Daten bleiben drauf. Muß dann der
Controller trotzdem jeden einzelnen Block auf \"kann wieder beschrieben
werden\" oder gar auf 0 setzen?

Und wenn ich die dergestalt aufgefrischte SSD temporär mit Daten zuknalle,
diese dann kurz darauf wieder lösche, dann beginnt - trotz aktiviertem
TRIM - das lustige Spiel von vorne? So hatte ich mir die Funktionalität
irgendwie nicht vorgestellt. Kommt ja gleich nach Drehplatten, wo man
ständig defragmentieren mußte.

Volker

 

[Gerrit Heitsch]

On 12/13/21 2:53 PM, Volker Bartheld wrote:

On Mon, 13 Dec 2021 14:33:28 +0100, Gerrit Heitsch wrote:
[Samsung 840 Evo lahmt beim Empfang größeren Dateien]
On 12/13/21 1:32 PM, Volker Bartheld wrote:
TRIM ist aktiviert (zuminmdest antwortet mir fsutil behavior query
DisableDeleteNotify mit 0), auf der 840 sind 70 von 120GB frei. Ich hatte
naiverweise angenommen, das kleine Wunderding könnte sich dann
einigermaßen zuverlässig um sich selbst kümmern
Wenn du dem OS erlaubt hast TRIM zu verwenden, dann sollte das so sein,

*seufz*

Es gibt auch eine Möglichkeit TRIM on Hand auszulösen. Befehl unter
Linux dazu ist \'fstrim\' wenn ich das noch richtig weiss.

Ich könnte dazu natürlich fix Ubuntu vom Stick booten. Ist das egal, wenn
auf der verbauten Platte ein NTFS-Dateisystem drauf ist?

Das besser lassen. Oder zumindest vorher ein aktuelles Backup auf mehr
als ein Medium ziehen und sicherstellen, daß man das System davon
wiederherstellen kann.

Was also nun tun? Neuformatierung? Samsung Magician? Und wie Derartiges in
Zukunft vermeiden? Nein, defrag /o ist keine Option auf Windows 7.

Wenn der Hersteller nicht komplett gepennt hat sollte ein
SATA-Secure-Erase alle Blocks löschen. Dann das Image vom Backup wieder
drauf.

Fürs SATA-Secure-Erase braucht es dann aber auch wieder ein tolles (und vor
allem proprietäres) Tool? Bin ja gespannt, wie diese Self-Encrypting-SSDs
das lösen. Dort wird ja nur der eingangs zufällig erzeugte Schlüssel
\"vergessen\", die - zwar nicht lesbaren - Daten bleiben drauf. Muß dann der
Controller trotzdem jeden einzelnen Block auf \"kann wieder beschrieben
werden\" oder gar auf 0 setzen?

Damit es sinnvoll wird müsste er jeden Block löschen. Bei EPROMs waren
damals nach dem Löschen alle Bits auf \'1\' und nicht auf \'0\'.

Und wenn ich die dergestalt aufgefrischte SSD temporär mit Daten zuknalle,
diese dann kurz darauf wieder lösche, dann beginnt - trotz aktiviertem
TRIM - das lustige Spiel von vorne?

Bei funktionierendem TRIM sollte das nicht der Fall sein, denn genau
dafür ist es gedacht.

Gerrit

 

[Volker Bartheld]

On Mon, 13 Dec 2021 15:10:14 +0100, Gerrit Heitsch wrote:

On 12/13/21 2:53 PM, Volker Bartheld wrote:
On Mon, 13 Dec 2021 14:33:28 +0100, Gerrit Heitsch wrote:
[Samsung 840 Evo lahmt beim Empfang größeren Dateien]
On 12/13/21 1:32 PM, Volker Bartheld wrote:
Es gibt auch eine Möglichkeit TRIM on Hand auszulösen. Befehl unter
Linux dazu ist \'fstrim\' wenn ich das noch richtig weiss.
Ich könnte dazu natürlich fix Ubuntu vom Stick booten. Ist das egal, wenn
auf der verbauten Platte ein NTFS-Dateisystem drauf ist?
Das besser lassen. Oder zumindest vorher ein aktuelles Backup auf mehr
als ein Medium ziehen und sicherstellen, daß man das System davon
wiederherstellen kann.

Habe ich. Ergebnis von fstrim war, daß (erwartungsgemäß) irgendwas um
die 60GB \"getrimmt\" wurden, d. h. der freie Bereich. Dann wieder Win7
gebootet, klappte einwandfrei. Beim ersten Kopierversuch irgendwas im
Bereich von 250MB/s, was ich bei der Platte an SATA-2 auch erwarte.
Beim zweiten Versuch dann wieder das altbekannte Verhalten, nach
schnellem Start Einbruch der Transferrate auf deutlich unter 100MB/s
bis hin zu 60MB/s.

Das macht so keinen Spaß. Keine Ahnung, ob ich hier Samsung verdächtigen
soll (vermutlich hat niemand außer mir mehr so eine anachronistische
SSD am Start) oder ob es mal wieder das Produkt aus Redmont ist.
Natürlich könnte es noch was mit exakt diesem SATA-Controller an genau
diesem Port zu tun haben, aber das käme für mich eher als allerletzte
Ursache in Frage.

Und wenn ich die dergestalt aufgefrischte SSD temporär mit Daten zuknalle,
diese dann kurz darauf wieder lösche, dann beginnt - trotz aktiviertem
TRIM - das lustige Spiel von vorne?
Bei funktionierendem TRIM sollte das nicht der Fall sein, denn genau
dafür ist es gedacht.

So war auch meine bisherige Arbeitshypothese und ich sorge schon dafür,
daß auf den SSD immer genug Platz frei ist. Naja, ich werde berichten.
Was sollte ich mit der vielen Freizeit denn auch sonst anfangen als
PC-Bastelei...?

Volker

 

[Gerrit Heitsch]

On 12/13/21 2:39 PM, Volker Bartheld wrote:

On Mon, 13 Dec 2021 15:10:14 +0100, Gerrit Heitsch wrote:
On 12/13/21 2:53 PM, Volker Bartheld wrote:
On Mon, 13 Dec 2021 14:33:28 +0100, Gerrit Heitsch wrote:
[Samsung 840 Evo lahmt beim Empfang größeren Dateien]
On 12/13/21 1:32 PM, Volker Bartheld wrote:
Es gibt auch eine Möglichkeit TRIM on Hand auszulösen. Befehl unter
Linux dazu ist \'fstrim\' wenn ich das noch richtig weiss.
Ich könnte dazu natürlich fix Ubuntu vom Stick booten. Ist das egal, wenn
auf der verbauten Platte ein NTFS-Dateisystem drauf ist?
Das besser lassen. Oder zumindest vorher ein aktuelles Backup auf mehr
als ein Medium ziehen und sicherstellen, daß man das System davon
wiederherstellen kann.

Habe ich. Ergebnis von fstrim war, daß (erwartungsgemäß) irgendwas um
die 60GB \"getrimmt\" wurden, d. h. der freie Bereich. Dann wieder Win7
gebootet, klappte einwandfrei. Beim ersten Kopierversuch irgendwas im
Bereich von 250MB/s, was ich bei der Platte an SATA-2 auch erwarte.
Beim zweiten Versuch dann wieder das altbekannte Verhalten, nach
schnellem Start Einbruch der Transferrate auf deutlich unter 100MB/s
bis hin zu 60MB/s.

Das macht so keinen Spaß. Keine Ahnung, ob ich hier Samsung verdächtigen
soll (vermutlich hat niemand außer mir mehr so eine anachronistische
SSD am Start) oder ob es mal wieder das Produkt aus Redmont ist.

Ich habe eine ähnlich alte von Crucial mit 128 GB. Bis zum Ausbau aus
der Linux-Kiste 2018 hatte ich damit keine Probleme. Jetzt hängt sie
schon eine Weile via USB3 an einem Pi4 welcher davon bootet.

Natürlich könnte es noch was mit exakt diesem SATA-Controller an genau
diesem Port zu tun haben, aber das käme für mich eher als allerletzte
Ursache in Frage.

Eher unwahrscheinlich. Intel hatte mal ein Chipset wo die schnellen
SATA-Ports nach ein paar Monaten den Geist aufgaben, aber das ist eine
Weile her und wäre bei dir als \'bootet nicht mehr\' aufgefallen.

Und wenn ich die dergestalt aufgefrischte SSD temporär mit Daten zuknalle,
diese dann kurz darauf wieder lösche, dann beginnt - trotz aktiviertem
TRIM - das lustige Spiel von vorne?
Bei funktionierendem TRIM sollte das nicht der Fall sein, denn genau
dafür ist es gedacht.

So war auch meine bisherige Arbeitshypothese und ich sorge schon dafür,
daß auf den SSD immer genug Platz frei ist. Naja, ich werde berichten.
Was sollte ich mit der vielen Freizeit denn auch sonst anfangen als
PC-Bastelei...?

Aufräumen und Ausmisten wäre auf eine Idee. Aber Vorsicht... was man
heute an Technik rauswirft braucht in spätestens einem Monat. Wirft man
es nicht raus braucht man es nie wieder.

Gerrit

 

[Helmut Schellong]

On 12/13/2021 13:32, Volker Bartheld wrote:

On Mon, 13 Dec 2021 12:52:12 +0100, Gerrit Heitsch wrote:
On 12/13/21 12:34 PM, Arno Welzel wrote:
Volker Bartheld:
(Linux, Windows Explorer, Total Commander, rsync, usw. sinngemäß) ergaben,
daß das Problem nur beim Übertragen großer Dateien von d: nach c: auftrat,
nicht aber andersherum.
Was dann ja ein recht klares Indiz ist, dass das Laufwerk für c: keine
hohe Schreibrate hat.

Hinter dem Mountpoint C verbirgt sich eine Samsung 840 Evo mit 120GB, D ist
eine Samsung 850 Evo mit 500GB. Natürlich jeweils aktuelle Firmware (da
Die 840 Evo mit 128 GB dürfte schon etliche Jahre alt sein
(Markteinführung war 2013) und keine ungenutzten Blöcke mehr haben.
[...]
TRIM ist aktiviert (zuminmdest antwortet mir fsutil behavior query
DisableDeleteNotify mit 0), auf der 840 sind 70 von 120GB frei. Ich hatte
naiverweise angenommen, das kleine Wunderding könnte sich dann
einigermaßen zuverlässig um sich selbst kümmern, ohne daß Papi immer mal
wieder durchputzen muß.

Was also nun tun? Neuformatierung? Samsung Magician? Und wie Derartiges in
Zukunft vermeiden? Nein, defrag /o ist keine Option auf Windows 7.

.
Du kannst da mit an Sicherheit grenzender Wahrscheinlichkeit gar nichts Wirksames tun.

Flash-Speicher altert nun mal mit jedem Schreibvorgang - bis hin zur Unbrauchbarkeit.
Das ist unverhinderbar!
Die Lebensdauer von Standard-Flash wird offiziell mit 10000 Schreibvorgängen angegeben.
In der konkreten Praxis werden _meistens_ 100000 erreicht - also das 10-fache.
EEPROM hat da 1000000 Schreibvorgänge.

Bei SSD mit Wearleveling wird die Lebensdauer mit TBW angegeben.
Beispielsweise 400 TBW.
Das muß ernst genommen werden!
Nach mehr als 400 TB write kann dieser Baustein tatsächlich unbrauchbar sein.
Er wird schon lange davor merkbar langsamer geworden sein.

Man kann sich wappnen, durch sehr erhebliche Überdimensionierung.
Beispielsweise man braucht etwa 300 GB Speicher: ==> 2 TB kaufen!

Ich habe mehr als einmal von Defekten beim Kunden gehört.
Und zwar durch Fehler in der Programmierung.
Da waren Flash-Bausteine nach etwa 70000 unbeabsichtigten Schreibvorgängen in 2-3 Monaten defekt.

Deshalb verwende ich Flash nur für Backup-Zwecke und Konfiguration.
Flash-Speicher ist für darauf gespeicherte Betriebssysteme IMO gänzlich ungeeignet.


--
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

 

[Volker Bartheld]

On Mon, 13 Dec 2021 17:00:39 +0100, Helmut Schellong wrote:

On 12/13/2021 13:32, Volker Bartheld wrote:
On Mon, 13 Dec 2021 12:52:12 +0100, Gerrit Heitsch wrote:
On 12/13/21 12:34 PM, Arno Welzel wrote:
Volker Bartheld:
[Samsung 840 Evo 120GB lahmt beim Empfangen großer Dateien]
Flash-Speicher altert nun mal mit jedem Schreibvorgang - bis hin zur
Unbrauchbarkeit. Das ist unverhinderbar! Die Lebensdauer von
Standard-Flash wird offiziell mit 10000 Schreibvorgängen angegeben.

Was genau an \"Die 840er hat noch 75% \"Restlebensduer\", die 850er sogar noch
97%.\" in meinem Eingangsposting hast Du nicht verstanden?

> Nach mehr als 400 TB write kann dieser Baustein tatsächlich unbrauchbar sein.

Wovon beide SSDs noch meilenweit entfernt sind.

> Er wird schon lange davor merkbar langsamer geworden sein.

Er wurde bis vor wenigen Tagen _überhaupt nicht_ merkbar langsamer
(CrystalDiskMark, gleichgelagerte Kopiervorgänge wie die kürzlich
durchgeführten) und dann ziemlich schnell ziemlich spektakulär.

> Ich habe mehr als einmal von Defekten beim Kunden gehört.

Ich auch.

> Und zwar durch Fehler in der Programmierung.

Ich auch.

> Deshalb verwende ich Flash nur für Backup-Zwecke und Konfiguration.

Ich nicht.

> Flash-Speicher ist für darauf gespeicherte Betriebssysteme IMO gänzlich ungeeignet.

Sehe ich 180° anders. Du magst die Zeit haben, Dich mit lahmem Dreheisen
totzulangweilen, der Rest der computernutzenden Welt nicht.

Volker

 

[Volker Bartheld]

On Mon, 13 Dec 2021 15:52:00 +0100, Gerrit Heitsch wrote:

On 12/13/21 2:39 PM, Volker Bartheld wrote:
On Mon, 13 Dec 2021 15:10:14 +0100, Gerrit Heitsch wrote:
On 12/13/21 2:53 PM, Volker Bartheld wrote:
On Mon, 13 Dec 2021 14:33:28 +0100, Gerrit Heitsch wrote:
[Samsung 840 Evo lahmt beim Empfang größeren Dateien]
Ergebnis von fstrim war, daß (erwartungsgemäß) irgendwas um
die 60GB \"getrimmt\" wurden, d. h. der freie Bereich. Dann wieder Win7
gebootet, klappte einwandfrei. Beim ersten Kopierversuch irgendwas im
Bereich von 250MB/s, was ich bei der Platte an SATA-2 auch erwarte.
Beim zweiten Versuch dann wieder das altbekannte Verhalten
[...] Keine Ahnung, ob ich hier Samsung verdächtigen
soll (vermutlich hat niemand außer mir mehr so eine anachronistische
SSD am Start) oder ob es mal wieder das Produkt aus Redmont ist.
Ich habe eine ähnlich alte von Crucial mit 128 GB. Bis zum Ausbau aus
der Linux-Kiste 2018 hatte ich damit keine Probleme.

So hätte ich das auch erwartet. Jetzt, einige Iterationen mit dem famosen
Samsung Disk Magician später, revidiere ich meine Meinung hinsichtlich der
Softwareentwicklungskompetenz dieser Firma. Damit, daß der
InnoSetup-Installer nach Deinstallation allerhand Müll hinterläßt, muß man
sich ja inzwischen irgendwie abfinden. Die vollkommen überfrachtete,
aufgeblähte GUI, die natürlich sofort automagisch mit Windows starten will
und gleich mal einen Dienst ins System hängt, ignoriert sich ebenfalls
weg.

Etwas mehr Sorge habe ich mit der Tatsache, daß für ein \"Secure Erase\"
_unbedingt_ irgendeine Bootumgebung zur Wiederherstellung auf einem
USB-Stick gespeichert werden soll. OK, fliegt ja als Schüttgut rum.

Der Abschuß war dann, daß mir ein Update der Firmware der 860 Evo empfohlen
wurde - und zwar auf die Version RVT04B6Q. Auf meiner Kiste schlummert
noch RVT01B6Q. So richtig ausgereift scheint das Update eher nicht zu sein
[1], daher war es ganz gut, daß der Updateversuch sowieso fehlschlug, denn
den o. g. Forenthread habe ich zu meinem großen Entsetzen erst später
gelesen.

In Summe reichlich ernüchternd. Schneller habe ich die SSD jetzt jedenfalls
nicht gekriegt und bevor ich es tatsächlich mit einem Safe Erase versuche,
muß ich noch eine Lösung finden, die Windowspartition nebst ihrer
versteckten Bootpartition effizient und ohne Nervenzusammenbruch
zurückzuspielen. Oder ich lösche letztere gleich ganz [2].

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.

Aber das scheint mir irgendwie langsam das kleinere Übel zu sein. Echt
wahr.

Natürlich könnte es noch was mit exakt diesem SATA-Controller an genau
diesem Port zu tun haben, aber das käme für mich eher als allerletzte
Ursache in Frage.

Eher unwahrscheinlich. Intel hatte mal ein Chipset wo die schnellen
SATA-Ports nach ein paar Monaten den Geist aufgaben, aber das ist eine
Weile her und wäre bei dir als \'bootet nicht mehr\' aufgefallen.

Eben. M. E. n. hat das Brett zwar einen Intel-Chipsatz (P55), der verhält
sich aber normal recht gutartig.

Und wenn ich die dergestalt aufgefrischte SSD temporär mit Daten zuknalle,
diese dann kurz darauf wieder lösche, dann beginnt - trotz aktiviertem
TRIM - das lustige Spiel von vorne?
Bei funktionierendem TRIM sollte das nicht der Fall sein, denn genau
dafür ist es gedacht.
So war auch meine bisherige Arbeitshypothese und ich sorge schon dafür,
daß auf den SSD immer genug Platz frei ist. Naja, ich werde berichten.
Was sollte ich mit der vielen Freizeit denn auch sonst anfangen als
PC-Bastelei...?

Aufräumen und Ausmisten wäre auf eine Idee.

*LOL* Ja, Ideen und Betätigungsmöglichkeiten gäbs genug. Ich hätte aber
gerne zumindest _einen_ funktionsfähigen Privat-PC, denn sonst kriege ich
den ganzen Plunder nicht via Ebay-Kleinanzeigen verschenkt oder verkauft.

Und meine Ambition, jetzt schnell noch einen ThreadRipper mir ECC und
Monster-GPU hinzustellen, hält sich angesichts des weltweiten
Chipengpasses und der damit verbundenen Preise in recht überschaubaren
Grenzen. Zumal ich so ein System auch überhaupt nicht brauche. Selbst für
Videoschnitt in FHD reicht das existente System, wenn man es mit
irgendwelchen Filtern nicht übertreibt.

Aber Vorsicht... was man
heute an Technik rauswirft braucht in spätestens einem Monat. Wirft man
es nicht raus braucht man es nie wieder.

Das eh. Die Bootplatte wieder in schnell(er) würde mir fürs Erste schon
vollkommen reichen. Glücklicherweise ist sie ja (noch) nicht kaputt,
sondern nur etwas verschnupft.

Volker


[1] https://us.community.samsung.com/t5/Monitors-and-Memory/860-EVO-Firmware-RVT04B6Q/td-p/992098
[2] https://kb.terabyteunlimited.com/kb-articles/how-to-remove-the-windows-system-reserved-partition/

 

[Gerrit Heitsch]

On 12/13/21 6:08 PM, Volker Bartheld wrote:

On Mon, 13 Dec 2021 15:52:00 +0100, Gerrit Heitsch wrote:
On 12/13/21 2:39 PM, Volker Bartheld wrote:
On Mon, 13 Dec 2021 15:10:14 +0100, Gerrit Heitsch wrote:
On 12/13/21 2:53 PM, Volker Bartheld wrote:
On Mon, 13 Dec 2021 14:33:28 +0100, Gerrit Heitsch wrote:
[Samsung 840 Evo lahmt beim Empfang größeren Dateien]
Ergebnis von fstrim war, daß (erwartungsgemäß) irgendwas um
die 60GB \"getrimmt\" wurden, d. h. der freie Bereich. Dann wieder Win7
gebootet, klappte einwandfrei. Beim ersten Kopierversuch irgendwas im
Bereich von 250MB/s, was ich bei der Platte an SATA-2 auch erwarte.
Beim zweiten Versuch dann wieder das altbekannte Verhalten
[...] Keine Ahnung, ob ich hier Samsung verdächtigen
soll (vermutlich hat niemand außer mir mehr so eine anachronistische
SSD am Start) oder ob es mal wieder das Produkt aus Redmont ist.
Ich habe eine ähnlich alte von Crucial mit 128 GB. Bis zum Ausbau aus
der Linux-Kiste 2018 hatte ich damit keine Probleme.

So hätte ich das auch erwartet. Jetzt, einige Iterationen mit dem famosen
Samsung Disk Magician später, revidiere ich meine Meinung hinsichtlich der
Softwareentwicklungskompetenz dieser Firma. Damit, daß der
InnoSetup-Installer nach Deinstallation allerhand Müll hinterläßt, muß man
sich ja inzwischen irgendwie abfinden. Die vollkommen überfrachtete,
aufgeblähte GUI, die natürlich sofort automagisch mit Windows starten will
und gleich mal einen Dienst ins System hängt, ignoriert sich ebenfalls
weg.

Etwas mehr Sorge habe ich mit der Tatsache, daß für ein \"Secure Erase\"
_unbedingt_ irgendeine Bootumgebung zur Wiederherstellung auf einem
USB-Stick gespeichert werden soll. OK, fliegt ja als Schüttgut rum.

Der Abschuß war dann, daß mir ein Update der Firmware der 860 Evo empfohlen
wurde - und zwar auf die Version RVT04B6Q. Auf meiner Kiste schlummert
noch RVT01B6Q. So richtig ausgereift scheint das Update eher nicht zu sein
[1], daher war es ganz gut, daß der Updateversuch sowieso fehlschlug, denn
den o. g. Forenthread habe ich zu meinem großen Entsetzen erst später
gelesen.

Ich hab mir Firmwareupdates auf meinen SSD bisher auch fast immer
verkniffen. Nur wenn ein Bug ist der wirklich immer auftritt und das
vielleicht mit Zeitverzögerung, dann mache ich das Update. Problem ist,
bei einer SSD geht ein Firmwareupgrade oft mit komplettem Datenverlust
einher, man müsste also das OS neu installieren.

In Summe reichlich ernüchternd. Schneller habe ich die SSD jetzt jedenfalls
nicht gekriegt und bevor ich es tatsächlich mit einem Safe Erase versuche,
muß ich noch eine Lösung finden, die Windowspartition nebst ihrer
versteckten Bootpartition effizient und ohne Nervenzusammenbruch
zurückzuspielen. Oder ich lösche letztere gleich ganz [2].

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.

Das meiste davon sollte beherrschbar sein. Anbindung ans NAS? Kann das
kein NFS?

Gerrit

 

[Volker Bartheld]

On Mon, 13 Dec 2021 18:28:42 +0100, Gerrit Heitsch wrote:

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.
Das meiste davon sollte beherrschbar sein. Anbindung ans NAS? Kann das
kein NFS?

Doch, klar. NFS, HTTP(S), FTP, SMB, ... Es geht mehr um die ganze
Mounterei, die Backupskripte, Namensauflösung, etc. Um das NAS (NetGear
RN214) mache ich mir wirklich die allergeringsten Sorgen, obwohl ich da
schon auch so meine Erfahrungen gesammelt habe:

https://community.netgear.com/t5/Using-your-ReadyNAS-in-Business/Admin-page-unavailable-after-cancelled-backup-job-amp-hard/m-p/2142882
https://community.netgear.com/t5/Using-your-ReadyNAS-in-Business/RN214-refuses-to-take-snapshots/m-p/2159703

Der Teufel ist bekanntlich ein Eichhörnchen und ein NAS mit ssh immer eine
gute Sache.

Volker

 

[Helmut Schellong]

On 12/13/2021 17:41, Volker Bartheld wrote:

On Mon, 13 Dec 2021 17:00:39 +0100, Helmut Schellong wrote:
On 12/13/2021 13:32, Volker Bartheld wrote:
On Mon, 13 Dec 2021 12:52:12 +0100, Gerrit Heitsch wrote:
On 12/13/21 12:34 PM, Arno Welzel wrote:
Volker Bartheld:
[Samsung 840 Evo 120GB lahmt beim Empfangen großer Dateien]
Flash-Speicher altert nun mal mit jedem Schreibvorgang - bis hin zur
Unbrauchbarkeit. Das ist unverhinderbar! Die Lebensdauer von
Standard-Flash wird offiziell mit 10000 Schreibvorgängen angegeben.

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.
Wie kommst Du darauf, daß ich etwas nicht verstanden habe?

Aber Du hast offenbar meine Aussagen nicht verstanden.

Nach mehr als 400 TB write kann dieser Baustein tatsächlich unbrauchbar sein.

Wovon beide SSDs noch meilenweit entfernt sind.

Ja.

Er wird schon lange davor merkbar langsamer geworden sein.

Er wurde bis vor wenigen Tagen _überhaupt nicht_ merkbar langsamer
(CrystalDiskMark, gleichgelagerte Kopiervorgänge wie die kürzlich
durchgeführten) und dann ziemlich schnell ziemlich spektakulär.

Was schrieb ich denn wirklich?
Ich schrieb von einem hypothetischen Exemplar mit Lebensdauer 400 TBW, welches
schon lange vor Erreichen von 400 TB langsamer geworden sein wird.

Vielleicht hat Deine SSD vor kurzer Zeit ihre letzten Reserven verbraucht.

Ich habe mehr als einmal von Defekten beim Kunden gehört.

Ich auch.

Und zwar durch Fehler in der Programmierung.

Ich auch.

Deshalb verwende ich Flash nur für Backup-Zwecke und Konfiguration.

Ich nicht.

Ich unter _allen_ Umständen!

Ein Speicher, der fortlaufend langsamer wird und zudem nach nur 1000 internen Schreibvorgängen
unbrauchbar wird, ist vollkommen indiskutabel für mich für den genannten Zweck.

Da lobe ich mir Festplatten, die inzwischen _schnell genug_ sind, nicht langsamer
werden, Milliarden von Schreibvorgängen aushalten und ≥15 Jahre lang laufen.

Flash-Speicher ist für darauf gespeicherte Betriebssysteme IMO gänzlich ungeeignet.

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?

Ich hatte bisher etwa 15 HDD, die alle >10 Jahre in Betrieb waren/sind und von denen
nur eine nach 15 Jahren defekt ging.


--
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

 

[Gerrit Heitsch]

On 12/13/21 6:34 PM, Volker Bartheld wrote:

On Mon, 13 Dec 2021 18:28:42 +0100, Gerrit Heitsch wrote:
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.
Das meiste davon sollte beherrschbar sein. Anbindung ans NAS? Kann das
kein NFS?

Doch, klar. NFS, HTTP(S), FTP, SMB, ... Es geht mehr um die ganze
Mounterei, die Backupskripte, Namensauflösung, etc. Um das NAS (NetGear
RN214) mache ich mir wirklich die allergeringsten Sorgen, obwohl ich da
schon auch so meine Erfahrungen gesammelt habe:

https://community.netgear.com/t5/Using-your-ReadyNAS-in-Business/Admin-page-unavailable-after-cancelled-backup-job-amp-hard/m-p/2142882
https://community.netgear.com/t5/Using-your-ReadyNAS-in-Business/RN214-refuses-to-take-snapshots/m-p/2159703

Der Teufel ist bekanntlich ein Eichhörnchen und ein NAS mit ssh immer eine
gute Sache.

Deshalb läuft hier einfach ein älterer PC mit einem Phenom II als
Fileserver. Da ein normales Linux (Server, also kein X11) drauf und
passt. Man hat dann alle Freiheiten. Backups via selbstgeschriebene
Scripte mit rsync.

Den Nameserver macht mein Router dank OpenWRT nebenher.

Gerrit

 

[Sebastin Wolf]

Am 13.12.2021 um 18:37 schrieb Helmut Schellong:
> Wie kommst Du darauf, daß ich etwas nicht verstanden habe?

Erfahrung!

 

[Volker Bartheld]

Ach so, Du wolltest nur generalisieren. Me culpa. Und jetzt huschhusch,
zurück ins Körbchen.

Volker

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?

 

[Volker Bartheld]

Ach so, Du wolltest nur generalisieren [sup: und theoretisieren]. Me culpa.
Und jetzt huschhusch, zurück ins Körbchen.

Volker

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?

 

[Joerg]

On 12/13/21 9:28 AM, Gerrit Heitsch wrote:

On 12/13/21 6:08 PM, Volker Bartheld wrote:
On Mon, 13 Dec 2021 15:52:00 +0100, Gerrit Heitsch wrote:
On 12/13/21 2:39 PM, Volker Bartheld wrote:
On Mon, 13 Dec 2021 15:10:14 +0100, Gerrit Heitsch wrote:
On 12/13/21 2:53 PM, Volker Bartheld wrote:
On Mon, 13 Dec 2021 14:33:28 +0100, Gerrit Heitsch wrote:
[Samsung 840 Evo lahmt beim Empfang größeren Dateien]
Ergebnis von fstrim war, daß (erwartungsgemäß) irgendwas um
die 60GB \"getrimmt\" wurden, d. h. der freie Bereich. Dann wieder Win7
gebootet, klappte einwandfrei. Beim ersten Kopierversuch irgendwas im
Bereich von 250MB/s, was ich bei der Platte an SATA-2 auch erwarte.
Beim zweiten Versuch dann wieder das altbekannte Verhalten
[...] Keine Ahnung, ob ich hier Samsung verdächtigen
soll (vermutlich hat niemand außer mir mehr so eine anachronistische
SSD am Start) oder ob es mal wieder das Produkt aus Redmont ist.

Anachronistisch? Ich habe hier eine Samsung EVO 860 mit 240GB, Vor 2-3
Jahren gekauft, loeppt gut. Erst mit Windows 7 und seit das abgekuendigt
wurde mit MX-Linux.

[...]

Ich hab mir Firmwareupdates auf meinen SSD bisher auch fast immer
verkniffen. Nur wenn ein Bug ist der wirklich immer auftritt und das
vielleicht mit Zeitverzögerung, dann mache ich das Update. Problem ist,
bei einer SSD geht ein Firmwareupgrade oft mit komplettem Datenverlust
einher, man müsste also das OS neu installieren.

Das koennte man ja vorher mit dd oder aehnlichem auf eine andere Platte
spiegeln.

In Summe reichlich ernüchternd. Schneller habe ich die SSD jetzt
jedenfalls
nicht gekriegt und bevor ich es tatsächlich mit einem Safe Erase
versuche,
muß ich noch eine Lösung finden, die Windowspartition nebst ihrer
versteckten Bootpartition effizient und ohne Nervenzusammenbruch
zurückzuspielen. Oder ich lösche letztere gleich ganz [2].

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?

[...]

--
Gruesse, Joerg

http://www.analogconsultants.com/