Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > de.sci.electronics > #315156 > unrolled thread
| Started by | Volker Bartheld <news2021@bartheld.net> |
|---|---|
| First post | 2021-12-13 10:39 +0100 |
| Last post | 2021-12-25 18:14 +0100 |
| Articles | 20 on this page of 91 — 22 participants |
Back to article view | Back to de.sci.electronics
Der leise Tod einer SSD...? Volker Bartheld <news2021@bartheld.net> - 2021-12-13 10:39 +0100
Re: Der leise Tod einer SSD...? Arno Welzel <usenet@arnowelzel.de> - 2021-12-13 12:34 +0100
Re: Der leise Tod einer SSD...? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-12-13 12:52 +0100
Re: Der leise Tod einer SSD...? Volker Bartheld <news2021@bartheld.net> - 2021-12-13 13:32 +0100
Re: Der leise Tod einer SSD...? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-12-13 14:33 +0100
Re: Der leise Tod einer SSD...? Volker Bartheld <news2021@bartheld.net> - 2021-12-13 14:53 +0100
Re: Der leise Tod einer SSD...? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-12-13 15:10 +0100
Re: Der leise Tod einer SSD...? Volker Bartheld <news2021@bartheld.net> - 2021-12-13 14:39 +0100
Re: Der leise Tod einer SSD...? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-12-13 15:52 +0100
Re: Der leise Tod einer SSD...? Volker Bartheld <news2021@bartheld.net> - 2021-12-13 18:08 +0100
Re: Der leise Tod einer SSD...? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-12-13 18:28 +0100
Re: Der leise Tod einer SSD...? Volker Bartheld <news2021@bartheld.net> - 2021-12-13 18:34 +0100
Re: Der leise Tod einer SSD...? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-12-13 18:45 +0100
Re: Der leise Tod einer SSD...? Joerg <news@analogconsultants.com> - 2021-12-13 12:06 -0800
Re: Der leise Tod einer SSD...? Volker Bartheld <news2021@bartheld.net> - 2021-12-14 10:26 +0100
Re: Der leise Tod einer SSD...? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-12-14 10:50 +0100
Re: Der leise Tod einer SSD...? Volker Bartheld <news2021@bartheld.net> - 2021-12-14 10:59 +0100
Re: Der leise Tod einer SSD...? Joerg <news@analogconsultants.com> - 2021-12-14 12:17 -0800
Re: Der leise Tod einer SSD...? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-12-14 21:36 +0100
Re: Der leise Tod einer SSD...? Joerg <news@analogconsultants.com> - 2021-12-14 15:40 -0800
Re: Der leise Tod einer SSD...? Arno Welzel <usenet@arnowelzel.de> - 2021-12-20 16:37 +0100
Re: Der leise Tod einer SSD...? Joerg <news@analogconsultants.com> - 2021-12-27 12:34 -0800
Re: Der leise Tod einer SSD...? Arno Welzel <usenet@arnowelzel.de> - 2021-12-20 16:36 +0100
Re: Der leise Tod einer SSD...? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-12-20 16:42 +0100
Re: Der leise Tod einer SSD...? Thorsten Böttcher <thorsten_nospam@gmx.net> - 2021-12-20 11:13 +0100
Re: Der leise Tod einer SSD...? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-12-20 11:36 +0100
Re: Der leise Tod einer SSD...? Thorsten Böttcher <thorsten_nospam@gmx.net> - 2021-12-20 12:22 +0100
Re: Der leise Tod einer SSD...? Arno Welzel <usenet@arnowelzel.de> - 2021-12-20 16:34 +0100
Re: Der leise Tod einer SSD...? Thomas Prufer <prufer.public@mnet-online.de.invalid> - 2021-12-20 17:21 +0100
Re: Der leise Tod einer SSD...? Bernd Mayer <beam.bam.boom@knuut.de> - 2021-12-13 23:25 +0100
Re: Der leise Tod einer SSD...? Volker Bartheld <news2021@bartheld.net> - 2021-12-15 09:54 +0100
Re: Der leise Tod einer SSD...? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-12-16 00:51 +0100
Re: Der leise Tod einer SSD...? Volker Bartheld <news2021@bartheld.net> - 2021-12-16 07:56 +0100
Re: Der leise Tod einer SSD...? Hanno Foest <hurga-news2@tigress.com> - 2021-12-16 10:29 +0100
Re: Der leise Tod einer SSD...? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-12-16 10:49 +0100
Re: Der leise Tod einer SSD...? Volker Bartheld <news2021@bartheld.net> - 2021-12-16 11:32 +0100
Re: Der leise Tod einer SSD...? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-12-16 12:01 +0100
Re: Der leise Tod einer SSD...? Hartmut Kraus <hartmut.melina@web.de> - 2021-12-16 13:37 +0100
Re: Der leise Tod einer SSD...? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-12-16 13:43 +0100
Re: Der leise Tod einer SSD...? Hartmut Kraus <hartmut.melina@web.de> - 2021-12-16 14:18 +0100
Re: Der leise Tod einer SSD...? Ole Jansen <remove.this.kaspernasebaer@gmx.de> - 2021-12-16 15:24 +0100
Re: Der leise Tod einer SSD...? Volker Bartheld <news2021@bartheld.net> - 2021-12-16 18:21 +0100
Re: Der leise Tod einer SSD...? "Wolfgang Allinger" <all2001@spambog.com> - 2021-12-16 16:32 -0300
Re: Der leise Tod einer SSD...? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-12-16 23:21 +0100
Re: Der leise Tod einer SSD...? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-12-17 06:52 +0100
Re: Der leise Tod einer SSD...? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-12-17 23:00 +0100
Re: Der leise Tod einer SSD...? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-12-18 18:24 +0100
Re: Der leise Tod einer SSD...? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-12-18 21:50 +0100
Re: Der leise Tod einer SSD...? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-12-18 22:21 +0100
Re: Der leise Tod einer SSD...? Volker Bartheld <news2021@bartheld.net> - 2021-12-17 17:46 +0100
Re: Der leise Tod einer SSD...? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-12-17 23:17 +0100
Re: Der leise Tod einer SSD...? Volker Bartheld <news2021@bartheld.net> - 2021-12-18 11:36 +0100
Re: Der leise Tod einer SSD...? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-12-18 21:53 +0100
Re: Der leise Tod einer SSD...? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-12-16 22:50 +0100
Re: Der leise Tod einer SSD...? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-12-17 06:48 +0100
Re: Der leise Tod einer SSD...? Michael Schwingen <news-1513678000@discworld.dascon.de> - 2021-12-17 18:56 +0000
Re: Der leise Tod einer SSD...? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-12-18 18:19 +0100
Re: Der leise Tod einer SSD...? "Wolfgang Allinger" <all2001@spambog.com> - 2021-12-16 16:26 -0300
Re: Der leise Tod einer SSD...? Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2021-12-16 22:47 +0100
Re: Der leise Tod einer SSD...? Volker Bartheld <news2021@bartheld.net> - 2021-12-17 17:34 +0100
Re: Der leise Tod einer SSD...? Hanno Foest <hurga-news2@tigress.com> - 2021-12-17 22:50 +0100
Re: Der leise Tod einer SSD...? Volker Bartheld <news2021@bartheld.net> - 2021-12-18 11:40 +0100
Re: Der leise Tod einer SSD...? Hanno Foest <hurga-news2@tigress.com> - 2021-12-18 14:29 +0100
Re: Der leise Tod einer SSD...? Volker Bartheld <news2021@bartheld.net> - 2021-12-18 22:53 +0100
Re: Der leise Tod einer SSD...? Axel Berger <Spam@Berger-Odenthal.De> - 2021-12-19 01:39 +0100
Re: Der leise Tod einer SSD...? Rolf Bombach <rolfnospambombach@invalid.invalid> - 2021-12-30 15:31 +0100
Re: Der leise Tod einer SSD...? Hartmut Kraus <hartmut.melina@web.de> - 2021-12-30 16:53 +0100
Re: Der leise Tod einer SSD...? Rolf Bombach <rolfnospambombach@invalid.invalid> - 2022-01-19 22:04 +0100
Re: Der leise Tod einer SSD...? Hartmut Kraus <hartmut.melina@web.de> - 2022-01-26 22:19 +0100
Re: Der leise Tod einer SSD...? Thomas Prufer <prufer.public@mnet-online.de.invalid> - 2021-12-31 08:33 +0100
Re: Der leise Tod einer SSD...? Helmut Schellong <rip@schellong.biz> - 2021-12-13 17:00 +0100
Re: Der leise Tod einer SSD...? Volker Bartheld <news2021@bartheld.net> - 2021-12-13 17:41 +0100
Re: Der leise Tod einer SSD...? Helmut Schellong <rip@schellong.biz> - 2021-12-13 18:37 +0100
Re: Der leise Tod einer SSD...? Sebastin Wolf <invaild@invaild.net> - 2021-12-13 19:04 +0100
Re: Der leise Tod einer SSD...? Volker Bartheld <news2021@bartheld.net> - 2021-12-13 19:47 +0100
Re: Der leise Tod einer SSD...? Helmut Schellong <rip@schellong.biz> - 2021-12-13 22:47 +0100
Re: Der leise Tod einer SSD...? Arno Welzel <usenet@arnowelzel.de> - 2021-12-20 16:41 +0100
Re: Der leise Tod einer SSD...? Helmut Schellong <rip@schellong.biz> - 2021-12-20 16:59 +0100
Re: Der leise Tod einer SSD...? Volker Bartheld <news2021@bartheld.net> - 2021-12-14 10:53 +0100
Re: Der leise Tod einer SSD...? Marcel Mueller <news.5.maazl@spamgourmet.org> - 2021-12-14 21:31 +0100
Re: Der leise Tod einer SSD...? Volker Bartheld <news2021@bartheld.net> - 2021-12-15 10:27 +0100
Re: Der leise Tod einer SSD...? Marcel Mueller <news.5.maazl@spamgourmet.org> - 2021-12-16 08:03 +0100
Re: Der leise Tod einer SSD...? Volker Bartheld <news2021@bartheld.net> - 2021-12-16 08:44 +0100
Re: Der leise Tod einer SSD...? Holger Schieferdecker <spamless@gmx.de> - 2021-12-16 12:08 +0100
Re: Der leise Tod einer SSD...? Helmut Schellong <rip@schellong.biz> - 2021-12-16 16:25 +0100
Re: Der leise Tod einer SSD...? Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2021-12-16 17:22 +0100
Re: Der leise Tod einer SSD...? Marcel Mueller <news.5.maazl@spamgourmet.org> - 2021-12-16 20:50 +0100
Re: Der leise Tod einer SSD...? Volker Bartheld <news2021@bartheld.net> - 2021-12-16 21:12 +0100
Re: Der leise Tod einer SSD...? Gerhard Hoffmann <dk4xp@arcor.de> - 2021-12-16 08:47 +0100
Re: Der leise Tod einer SSD...? Markus Müller <joe@bla.invalid> - 2021-12-14 20:28 +0100
Re: Der leise Tod einer SSD...? Fritz <mogined@nurfuerspam.de> - 2021-12-25 18:14 +0100
Page 1 of 5 [1] 2 3 4 5 Next page →
| From | Volker Bartheld <news2021@bartheld.net> |
|---|---|
| Date | 2021-12-13 10:39 +0100 |
| Subject | Der leise Tod einer SSD...? |
| Message-ID | <1trl7ryanh12c$.dlg@news.bartheld.net> |
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.
[toc] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2021-12-13 12:34 +0100 |
| Message-ID | <j1opdbFlebrU1@mid.individual.net> |
| In reply to | #315156 |
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
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2021-12-13 12:52 +0100 |
| Message-ID | <sp7c5c$2rq$1@news.bawue.net> |
| In reply to | #315163 |
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
[toc] | [prev] | [next] | [standalone]
| From | Volker Bartheld <news2021@bartheld.net> |
|---|---|
| Date | 2021-12-13 13:32 +0100 |
| Message-ID | <1xqgms82ue3h.dlg@news.bartheld.net> |
| In reply to | #315164 |
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
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2021-12-13 14:33 +0100 |
| Message-ID | <sp7i38$5e5$1@news.bawue.net> |
| In reply to | #315166 |
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
[toc] | [prev] | [next] | [standalone]
| From | Volker Bartheld <news2021@bartheld.net> |
|---|---|
| Date | 2021-12-13 14:53 +0100 |
| Message-ID | <1wttzab55itkd.dlg@news.bartheld.net> |
| In reply to | #315175 |
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
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2021-12-13 15:10 +0100 |
| Message-ID | <sp7k86$6gd$1@news.bawue.net> |
| In reply to | #315176 |
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
[toc] | [prev] | [next] | [standalone]
| From | Volker Bartheld <news2021@bartheld.net> |
|---|---|
| Date | 2021-12-13 14:39 +0100 |
| Message-ID | <19yh51a6e17nl$.dlg@news.bartheld.net> |
| In reply to | #315177 |
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
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2021-12-13 15:52 +0100 |
| Message-ID | <sp7mmg$7dn$1@news.bawue.net> |
| In reply to | #315179 |
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
[toc] | [prev] | [next] | [standalone]
| From | Volker Bartheld <news2021@bartheld.net> |
|---|---|
| Date | 2021-12-13 18:08 +0100 |
| Message-ID | <3ybmjneal6yw.dlg@news.bartheld.net> |
| In reply to | #315181 |
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/
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2021-12-13 18:28 +0100 |
| Message-ID | <sp7vsa$bdq$1@news.bawue.net> |
| In reply to | #315188 |
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
[toc] | [prev] | [next] | [standalone]
| From | Volker Bartheld <news2021@bartheld.net> |
|---|---|
| Date | 2021-12-13 18:34 +0100 |
| Message-ID | <vtjmbsvgpsoh.dlg@news.bartheld.net> |
| In reply to | #315190 |
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
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2021-12-13 18:45 +0100 |
| Message-ID | <sp80s5$bsh$1@news.bawue.net> |
| In reply to | #315192 |
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
[toc] | [prev] | [next] | [standalone]
| From | Joerg <news@analogconsultants.com> |
|---|---|
| Date | 2021-12-13 12:06 -0800 |
| Message-ID | <j1pne4Fr4aqU1@mid.individual.net> |
| In reply to | #315190 |
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/
[toc] | [prev] | [next] | [standalone]
| From | Volker Bartheld <news2021@bartheld.net> |
|---|---|
| Date | 2021-12-14 10:26 +0100 |
| Message-ID | <9z0eye5ybc42.dlg@news.bartheld.net> |
| In reply to | #315199 |
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
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2021-12-14 10:50 +0100 |
| Message-ID | <sp9pch$5kg$1@news.bawue.net> |
| In reply to | #315220 |
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. Gerrit
[toc] | [prev] | [next] | [standalone]
| From | Volker Bartheld <news2021@bartheld.net> |
|---|---|
| Date | 2021-12-14 10:59 +0100 |
| Message-ID | <1prvq56yawh1k.dlg@news.bartheld.net> |
| In reply to | #315223 |
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
[toc] | [prev] | [next] | [standalone]
| From | Joerg <news@analogconsultants.com> |
|---|---|
| Date | 2021-12-14 12:17 -0800 |
| Message-ID | <j1scedFc6m4U1@mid.individual.net> |
| In reply to | #315225 |
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/
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2021-12-14 21:36 +0100 |
| Message-ID | <spav8i$lqa$1@news.bawue.net> |
| In reply to | #315263 |
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
[toc] | [prev] | [next] | [standalone]
| From | Joerg <news@analogconsultants.com> |
|---|---|
| Date | 2021-12-14 15:40 -0800 |
| Message-ID | <j1soatFec82U1@mid.individual.net> |
| In reply to | #315267 |
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/
[toc] | [prev] | [next] | [standalone]
Page 1 of 5 [1] 2 3 4 5 Next page →
Back to top | Article view | de.sci.electronics
csiph-web