Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > de.sci.electronics > #328504 > unrolled thread
| Started by | Helmut Schellong <rip@schellong.biz> |
|---|---|
| First post | 2022-11-03 18:04 +0100 |
| Last post | 2022-11-08 20:45 +0100 |
| Articles | 20 on this page of 114 — 21 participants |
Back to article view | Back to de.sci.electronics
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Helmut Schellong <rip@schellong.biz> - 2022-11-03 18:04 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Hanno Foest <hurga-news2@tigress.com> - 2022-11-03 22:47 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Guido Grohmann <guido.grohmann@gmx.de> - 2022-11-04 07:33 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2022-11-04 07:41 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Helmut Schellong <rip@schellong.biz> - 2022-11-04 10:03 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2022-11-04 10:09 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Helmut Schellong <rip@schellong.biz> - 2022-11-04 15:32 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2022-11-04 22:16 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Helmut Schellong <rip@schellong.biz> - 2022-11-05 12:51 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Rolf Bombach <rolfnospambombach@invalid.invalid> - 2022-11-05 11:43 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Helmut Schellong <rip@schellong.biz> - 2022-11-05 15:20 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten "Peter Heirich" <talk.usenet@info21.heirich.name> - 2022-11-05 00:01 +0000
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Volker Bartheld <news2022@bartheld.net> - 2022-11-05 07:48 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2022-11-05 20:49 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Michael Schwingen <news-1513678000@discworld.dascon.de> - 2022-11-06 13:18 +0000
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2022-11-06 21:45 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Michael Schwingen <news-1513678000@discworld.dascon.de> - 2022-11-07 21:11 +0000
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Hanno Foest <hurga-news2@tigress.com> - 2022-11-07 22:02 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2022-11-08 21:49 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Volker Bartheld <news2022@bartheld.net> - 2022-11-09 16:39 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2022-11-09 21:58 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Volker Bartheld <news2022@bartheld.net> - 2022-11-10 11:18 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2022-11-10 22:03 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2022-11-10 22:23 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Michael Schwingen <news-1513678000@discworld.dascon.de> - 2022-11-11 19:04 +0000
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Rolf Bombach <rolfnospambombach@invalid.invalid> - 2022-11-11 23:12 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2022-11-11 22:16 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Volker Bartheld <news2022@bartheld.net> - 2022-11-09 16:35 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2022-11-09 22:00 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2022-11-10 07:15 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2022-11-10 22:07 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2022-11-10 22:16 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2022-11-11 22:22 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2022-11-12 18:24 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2022-11-12 21:36 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2022-11-12 22:15 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2022-11-13 20:32 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2022-11-13 22:30 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2022-11-14 22:44 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2022-11-15 07:49 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Volker Bartheld <news2022@bartheld.net> - 2022-11-15 14:29 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Volker Bartheld <news2022@bartheld.net> - 2022-11-15 14:36 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2022-11-15 15:50 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Volker Bartheld <news2022@bartheld.net> - 2022-11-15 22:05 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Hanno Foest <hurga-news2@tigress.com> - 2022-11-16 01:00 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Rolf Bombach <rolfnospambombach@invalid.invalid> - 2022-11-16 22:26 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2022-11-16 21:10 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Bernd Laengerich <Bernd.Laengerich@web.de> - 2022-11-15 17:23 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2022-11-15 17:44 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Volker Bartheld <news2022@bartheld.net> - 2022-11-15 22:09 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Michael Schwingen <news-1513678000@discworld.dascon.de> - 2022-11-16 19:36 +0000
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2022-11-17 21:19 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Michael Schwingen <news-1513678000@discworld.dascon.de> - 2022-11-18 17:35 +0000
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Bernd Laengerich <Bernd.Laengerich@web.de> - 2022-11-18 22:31 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten olaf <olaf@criseis.ruhr.de> - 2022-11-19 05:28 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Michael Schwingen <news-1513678000@discworld.dascon.de> - 2022-11-19 10:16 +0000
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Hanno Foest <hurga-news2@tigress.com> - 2022-11-15 18:21 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Ole Jansen <remove.this.kaspernasebaer@gmx.de> - 2022-11-16 07:31 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Guido Grohmann <guido.grohmann@gmx.de> - 2022-11-15 18:01 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2022-11-15 18:09 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Axel Berger <Spam@Berger-Odenthal.De> - 2022-11-15 20:33 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Michael Schwingen <news-1513678000@discworld.dascon.de> - 2022-11-14 19:13 +0000
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2022-11-14 22:39 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Michael Schwingen <news-1513678000@discworld.dascon.de> - 2022-11-16 19:30 +0000
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Rupert Haselbeck <mein-rest-muell@gmx.de> - 2022-11-16 21:20 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Michael Schwingen <news-1513678000@discworld.dascon.de> - 2022-11-16 20:49 +0000
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2022-11-17 05:54 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Michael Schwingen <news-1513678000@discworld.dascon.de> - 2022-11-18 17:31 +0000
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Rolf Bombach <rolfnospambombach@invalid.invalid> - 2022-11-11 23:14 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Leo Baumann <ib@leobaumann.de> - 2022-11-11 23:29 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2022-11-12 18:21 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten "Peter Heirich" <talk.usenet@info21.heirich.name> - 2022-11-05 21:19 +0000
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2022-11-05 22:44 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten "Peter Heirich" <talk.usenet@info21.heirich.name> - 2022-11-06 00:00 +0000
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2022-11-06 08:17 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2022-11-06 08:21 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Volker Bartheld <news2022@bartheld.net> - 2022-11-09 16:55 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2022-11-09 17:32 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Gregor Szaktilla <spam0.sz@ktilla.de> - 2022-11-09 17:34 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2022-11-09 17:37 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2022-11-06 22:12 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Volker Bartheld <news2022@bartheld.net> - 2022-11-09 16:52 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Peter Heirich <talk.usenet@info21.heirich.name> - 2022-11-10 02:34 +0000
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2022-11-05 18:22 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Michael Schwingen <news-1513678000@discworld.dascon.de> - 2022-11-05 18:57 +0000
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Rolf Bombach <rolfnospambombach@invalid.invalid> - 2022-11-22 22:02 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Volker Bartheld <news2022@bartheld.net> - 2022-11-23 17:13 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Holger Schieferdecker <spamless@gmx.de> - 2022-11-24 09:22 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Volker Bartheld <news2022@bartheld.net> - 2022-11-24 12:00 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Rolf Bombach <rolfnospambombach@invalid.invalid> - 2022-11-27 18:16 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Rolf Bombach <rolfnospambombach@invalid.invalid> - 2022-11-27 16:07 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Hanno Foest <hurga-news2@tigress.com> - 2022-11-04 14:57 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Helmut Schellong <rip@schellong.biz> - 2022-11-04 16:24 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Volker Bartheld <news2022@bartheld.net> - 2022-11-04 19:31 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Helmut Schellong <rip@schellong.biz> - 2022-11-04 20:24 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Guido Grohmann <guido.grohmann@gmx.de> - 2022-11-04 17:04 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2022-11-05 18:20 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Volker Bartheld <news2022@bartheld.net> - 2022-11-04 19:28 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Helmut Schellong <rip@schellong.biz> - 2022-11-04 09:49 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Hanno Foest <hurga-news2@tigress.com> - 2022-11-04 14:53 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Helmut Schellong <rip@schellong.biz> - 2022-11-04 15:58 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Rolf Bombach <rolfnospambombach@invalid.invalid> - 2022-11-05 12:53 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Michael Schwingen <news-1513678000@discworld.dascon.de> - 2022-11-05 12:04 +0000
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Rolf Bombach <rolfnospambombach@invalid.invalid> - 2022-11-05 17:42 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Laurenz Trossel <me@example.invalid> - 2022-11-06 14:12 +0000
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Alexander Schreiber <als@usenet.thangorodrim.de> - 2022-11-08 21:49 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Helmut Schellong <rip@schellong.biz> - 2022-11-05 16:06 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Volker Bartheld <news2022@bartheld.net> - 2022-11-04 19:25 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Rolf Bombach <rolfnospambombach@invalid.invalid> - 2022-11-27 16:17 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2022-11-27 16:20 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Volker Bartheld <news2022@bartheld.net> - 2022-11-27 18:13 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Leo Baumann <ib@leobaumann.de> - 2022-11-03 23:23 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Helmut Schellong <rip@schellong.biz> - 2022-11-04 09:36 +0100
Re: [OT-Frage] Sicherer Speicher für wichtige Daten Helmut Schellong <rip@schellong.biz> - 2022-11-08 20:45 +0100
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
| From | Volker Bartheld <news2022@bartheld.net> |
|---|---|
| Date | 2022-11-15 14:29 +0100 |
| Message-ID | <1tiepiuoeownn$.dlg@news.bartheld.net> |
| In reply to | #328935 |
On Tue, 15 Nov 2022 07:49:00 +0100, Gerrit Heitsch wrote: > On 11/14/22 22:44, Sieghard Schicktanz wrote: >>> Of course, SSDs must erase these invalid pages of data at some point, >>> or the usable space on the SSD would eventually fill up. >> Eben. Und _ohne_ "garbage collection" [...], kann es halt >> immer einen Überlauf geben, der durch zunehmende Fragmentierung >> verursacht wird. > Das ist aber wohl heute Standard. Zuerst habe ich es bei Micron > (Crucial) und deren Budget SSD MX100 in der Beschreibung gefunden. Die > kostete mit 512 GB damals (2014, also 8 Jahre her) gerade mal 170 Euro. Genau. Ich finde es auch vergleichsweise merkwürdig, wenn ein Gerät mit in Firmware hinterlegtem, für den Benutzer und sogar das Betriebssystem(!) gänzlich unbekannten inneren Funktion, irgendwelchen Voodoo zur Aufrechterhaltung des nach außen garantierten Verhaltens benötigte. Das soll das Gerät bitte basierend auf den ihm mühleos zugänglichen Daten (hier: die Belegungstabelle der Seiten und deren Inhalt selbst neu sortieren) in Eigenregie erledigen. Und wenn es auf einer SSD dafür notwendig ist, einen Speicherbereich anzulegen, der für Anwenderdaten tabu ist, dann muß eben genau das ab Werk passieren. Und wenn die SSD ihren Müll irgendwie in regelmäßigen Abständen aufräumen muß, dann muß der Controller eben auf die TBW schauen, die aktuelle Auslastung, die Uptime oder sonstwas, was geeignet ist. Wer würde denn auch bei einem Auto den Hinweis akzeptieren, man möge regelmäßig gegen die Reifen treten, damit das ABS zuverlässig seine Funktion erfüllt *)? >> (Und wie die Zuordnungstabellen bei einem solchen Vorgang behandelt >> werden, wird vorsichtshalber nicht beschrieben. Vielleicht liegen >> die auch nicht direkt im Flash-Speicher oder werden gar in einem >> gepufferten RAM gehalten.) > Wie sie das lösen ist mir egal, es muss nur stabil funktionieren und > auch einen Stromausfall überstehen. Exakt so schauts aus. Volker *) Ja, bei manchen Karren ist das ein durchaus probates Mittel, so wie auch anderer Cargo Cult rings um den berühmt-berüchtigten Klemmenwechsel oder den Tausch der Starterbatterie. Zur Ehre der Hersteller gereicht das aber trotzdem nicht.
[toc] | [prev] | [next] | [standalone]
| From | Volker Bartheld <news2022@bartheld.net> |
|---|---|
| Date | 2022-11-15 14:36 +0100 |
| Message-ID | <g1nlb3kq4huu$.dlg@news.bartheld.net> |
| In reply to | #328935 |
On Tue, 15 Nov 2022 07:49:00 +0100, Gerrit Heitsch wrote: > On 11/14/22 22:44, Sieghard Schicktanz wrote: >>> Of course, SSDs must erase these invalid pages of data at some point, >>> or the usable space on the SSD would eventually fill up. >> Eben. Und _ohne_ "garbage collection" [...], kann es halt >> immer einen Überlauf geben, der durch zunehmende Fragmentierung >> verursacht wird. > Das ist aber wohl heute Standard. Zuerst habe ich es bei Micron > (Crucial) und deren Budget SSD MX100 in der Beschreibung gefunden. Die > kostete mit 512 GB damals (2014, also 8 Jahre her) gerade mal 170 Euro. Genau. Ich finde es auch vergleichsweise merkwürdig, wenn ein Gerät mit in Firmware hinterlegter, für den Benutzer und sogar das Betriebssystem(!) gänzlich unbekannter inneren Funktion, irgendwelchen Voodoo zur Aufrechterhaltung des nach außen garantierten Verhaltens benötigte. Das soll das Gerät bitte basierend auf den ihm mühleos zugänglichen Daten (hier: die Belegungstabelle der Seiten und deren Inhalt selbst neu sortieren) in Eigenregie erledigen. Und wenn es auf einer SSD dafür notwendig ist, einen Speicherbereich anzulegen, der für Anwenderdaten tabu ist, dann muß eben genau das ab Werk passieren. Und wenn die SSD ihren Müll irgendwie in regelmäßigen Abständen aufräumen muß, dann muß der Controller eben auf die TBW schauen, die aktuelle Auslastung, die Uptime oder sonstwas, was geeignet ist. Wer würde denn auch bei einem Auto den Hinweis akzeptieren, man möge regelmäßig gegen die Reifen treten, damit das ABS zuverlässig seine Funktion erfüllt *)? >> (Und wie die Zuordnungstabellen bei einem solchen Vorgang behandelt >> werden, wird vorsichtshalber nicht beschrieben. Vielleicht liegen >> die auch nicht direkt im Flash-Speicher oder werden gar in einem >> gepufferten RAM gehalten.) > Wie sie das lösen ist mir egal, es muss nur stabil funktionieren und > auch einen Stromausfall überstehen. Exakt so schauts aus. Volker *) Ja, bei manchen Karren ist das ein durchaus probates Mittel, so wie auch anderer Cargo Cult rings um den berühmt-berüchtigten Klemmenwechsel oder den Tausch der Starterbatterie. Zur Ehre der Hersteller gereicht das aber trotzdem nicht.
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2022-11-15 15:50 +0100 |
| Message-ID | <tl08rf$9bn$1@news.bawue.net> |
| In reply to | #328951 |
On 11/15/22 14:36, Volker Bartheld wrote: > On Tue, 15 Nov 2022 07:49:00 +0100, Gerrit Heitsch wrote: >> On 11/14/22 22:44, Sieghard Schicktanz wrote: >>>> Of course, SSDs must erase these invalid pages of data at some point, >>>> or the usable space on the SSD would eventually fill up. >>> Eben. Und _ohne_ "garbage collection" [...], kann es halt >>> immer einen Überlauf geben, der durch zunehmende Fragmentierung >>> verursacht wird. >> Das ist aber wohl heute Standard. Zuerst habe ich es bei Micron >> (Crucial) und deren Budget SSD MX100 in der Beschreibung gefunden. Die >> kostete mit 512 GB damals (2014, also 8 Jahre her) gerade mal 170 Euro. > > Genau. > > Ich finde es auch vergleichsweise merkwürdig, wenn ein Gerät mit in > Firmware hinterlegter, für den Benutzer und sogar das Betriebssystem(!) > gänzlich unbekannter inneren Funktion, irgendwelchen Voodoo zur > Aufrechterhaltung des nach außen garantierten Verhaltens benötigte. Das > soll das Gerät bitte basierend auf den ihm mühleos zugänglichen Daten > (hier: die Belegungstabelle der Seiten und deren Inhalt selbst neu > sortieren) in Eigenregie erledigen. > > Und wenn es auf einer SSD dafür notwendig ist, einen Speicherbereich > anzulegen, der für Anwenderdaten tabu ist, dann muß eben genau das ab > Werk passieren. Ich fand es nicht so problematisch beim Einrichten einfach ein paar GB keiner Partition zuordnen. Aber weiter will ich nicht gehen müssen. Ich betreibe hier keinen Hochlastserver, der Controller der SSD hat sehr viel freie Zeit in der er aufräumen kann. Gerrit
[toc] | [prev] | [next] | [standalone]
| From | Volker Bartheld <news2022@bartheld.net> |
|---|---|
| Date | 2022-11-15 22:05 +0100 |
| Message-ID | <1m4irr712ovnt.dlg@news.bartheld.net> |
| In reply to | #328954 |
On Tue, 15 Nov 2022 15:50:06 +0100, Gerrit Heitsch wrote: > On 11/15/22 14:36, Volker Bartheld wrote: >> Und wenn es auf einer SSD dafür notwendig ist, einen Speicherbereich >> [für trim] anzulegen, der für Anwenderdaten tabu ist, dann muß eben >> genau das ab Werk passieren. > Ich fand es nicht so problematisch beim Einrichten einfach ein paar GB > keiner Partition zuordnen. Aber weiter will ich nicht gehen müssen. Manchmal passiert das ja auch ganz automatisch. Zumindest habe ich gelegentlich den Eindruck, daß irgendwelche Windows- oder Linuxpartitionen nicht die volle Kapazität der SSD nutzen, sondern wegen irgendwelcher Partitionsgrenzen noch ein Bisserl was übrigbleibt. > Ich betreibe hier keinen Hochlastserver, der Controller der SSD hat sehr > viel freie Zeit in der er aufräumen kann. Genau. Außerdem erinnere ich an den Thread "Der leise Tod einer SSD...?" ab Message-ID: <1trl7ryanh12c$.dlg@news.bartheld.net>. Da haben bei einer Samsung 840 Evo mit 120GB (75% Restlebensdauer) weder irgendwelche Formatierungs- oder Neuinstallationsversuche funktioniert, um die schwächelnde Leistung wieder herzustellen. Ultima Ratio: https://wiki.ubuntuusers.de/SSD/Secure-Erase/ . Ebenfalls ein Fehlschlag. 860 Pro mit 250GB eingebaut, Sache erledigt. Auf dem Ding sind rund 200GB frei, da kann der Controller TRIMmen, bis der Arzt kommt. Volker
[toc] | [prev] | [next] | [standalone]
| From | Hanno Foest <hurga-news2@tigress.com> |
|---|---|
| Date | 2022-11-16 01:00 +0100 |
| Message-ID | <jtinhqFbhk6U3@mid.individual.net> |
| In reply to | #328984 |
On 15.11.22 22:05, Volker Bartheld wrote: >> Ich fand es nicht so problematisch beim Einrichten einfach ein paar GB >> keiner Partition zuordnen. Aber weiter will ich nicht gehen müssen. > > Manchmal passiert das ja auch ganz automatisch. Zumindest habe ich > gelegentlich den Eindruck, daß irgendwelche Windows- oder > Linuxpartitionen nicht die volle Kapazität der SSD nutzen, sondern > wegen irgendwelcher Partitionsgrenzen noch ein Bisserl was übrigbleibt. Sichwort Alignment. Sollte aber nicht viel ausmachen. Es gibt noch einen weiteren Grund, die Platten nicht ganz auszureizen: Nicht alle Hersteller interpretieren 2TB (oder sonstwas) auf das GB genau gleich. Versucht man dann, eine ausgefallene Platte durch eine "gleich große" andere zu ersetzen, kann es sein, daß das nicht paßt. Ich hab gerade ein RAID1 aus zwei nominell gleich großen, aber absichtlich nicht baugleichen SSDs gebaut, da war der Unterschied 45GB. Ich hab dann bei der kleineren bei der Partitionierung noch mal so viel freigelassen, einerseits für Overprovisioning als TRIM Ersatz, andererseits als Reserve, falls eine Ersatzplatte noch kleiner sein sollte. Hanno -- The modern conservative is engaged in one of man's oldest exercises in moral philosophy; that is, the search for a superior moral justification for selfishness. - John Kenneth Galbraith
[toc] | [prev] | [next] | [standalone]
| From | Rolf Bombach <rolfnospambombach@invalid.invalid> |
|---|---|
| Date | 2022-11-16 22:26 +0100 |
| Message-ID | <tl3khj$2efoh$1@dont-email.me> |
| In reply to | #328992 |
Hanno Foest schrieb: > > Es gibt noch einen weiteren Grund, die Platten nicht ganz auszureizen: Nicht alle Hersteller interpretieren 2TB (oder sonstwas) auf das GB genau gleich. https://xkcd.com/394/ -- mfg Rolf Bombach
[toc] | [prev] | [next] | [standalone]
| From | Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> |
|---|---|
| Date | 2022-11-16 21:10 +0100 |
| Message-ID | <20221116211006.4ce0d3a53c7631c423f88f20@SchS.de> |
| In reply to | #328984 |
Hallo Volker, Du schriebst am Tue, 15 Nov 2022 22:05:43 +0100: > 860 Pro mit 250GB eingebaut, Sache erledigt. Auf dem Ding sind rund > 200GB frei, da kann der Controller TRIMmen, bis der Arzt kommt. Ja, nachdem ja Speicherplatz inzwischen sowieso nix mewhr kostet, ist das auch kein Problem mehr. Früher hätte das bedeutet, daß der benutzte Platz dadurch das 5-fache (ge)kostet (hätte). BTW, wo gibt's eigentlich diese kostenlosen SSDs u.ä.? Ich finde immer nur welche mit Preisen... -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) ----------------------------------------------------------- Mit freundlichen Grüßen, S. Schicktanz -----------------------------------------------------------
[toc] | [prev] | [next] | [standalone]
| From | Bernd Laengerich <Bernd.Laengerich@web.de> |
|---|---|
| Date | 2022-11-15 17:23 +0100 |
| Message-ID | <jthsotF44vjU1@mid.individual.net> |
| In reply to | #328951 |
Am 15.11.2022 um 14:36 schrieb Volker Bartheld: > Ich finde es auch vergleichsweise merkwürdig, wenn ein Gerät mit in > Firmware hinterlegter, für den Benutzer und sogar das Betriebssystem(!) > gänzlich unbekannter inneren Funktion, irgendwelchen Voodoo zur > Aufrechterhaltung des nach außen garantierten Verhaltens benötigte. Das > soll das Gerät bitte basierend auf den ihm mühleos zugänglichen Daten > (hier: die Belegungstabelle der Seiten und deren Inhalt selbst neu > sortieren) in Eigenregie erledigen. Tut sie ja auch. Aber dazu ist es nötig, entweder TRIM zu unterstützen (hier wird dem Controller halt vom OS mitgeteilt welche Blöcke gerade frei werden) *ODER*, wenn das OS dies nicht unterstützt, einen leeren Bereich (da diese Blöcke nie beschrieben werden, sind sie immer frei). Man muß nur dafür sorgen daß sie wirklich nie beschrieben wurden, also eine lediglich neu partitionierte gebrauchte SSD ist da ggf. ungeeignet. > Und wenn es auf einer SSD dafür notwendig ist, einen Speicherbereich > anzulegen, der für Anwenderdaten tabu ist, dann muß eben genau das ab > Werk passieren. Das kann man so sehen, aber man verschenkt dann halt Kapazität, da jedes halbwegs moderne OS TRIM unterstützt. Bernd
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2022-11-15 17:44 +0100 |
| Message-ID | <tl0fio$9bn$5@news.bawue.net> |
| In reply to | #328957 |
On 11/15/22 17:23, Bernd Laengerich wrote: > Am 15.11.2022 um 14:36 schrieb Volker Bartheld: >> Ich finde es auch vergleichsweise merkwürdig, wenn ein Gerät mit in >> Firmware hinterlegter, für den Benutzer und sogar das Betriebssystem(!) >> gänzlich unbekannter inneren Funktion, irgendwelchen Voodoo zur >> Aufrechterhaltung des nach außen garantierten Verhaltens benötigte. Das >> soll das Gerät bitte basierend auf den ihm mühleos zugänglichen Daten >> (hier: die Belegungstabelle der Seiten und deren Inhalt selbst neu >> sortieren) in Eigenregie erledigen. > > Tut sie ja auch. Aber dazu ist es nötig, entweder TRIM zu unterstützen > (hier wird dem Controller halt vom OS mitgeteilt welche Blöcke gerade > frei werden) *ODER*, wenn das OS dies nicht unterstützt, einen leeren > Bereich (da diese Blöcke nie beschrieben werden, sind sie immer frei). > Man muß nur dafür sorgen daß sie wirklich nie beschrieben wurden, also > eine lediglich neu partitionierte gebrauchte SSD ist da ggf. ungeeignet. Einmal ein SATA Secure Erase Kommando drüber und schon sollte das Problem, so es eines ist, gelöst sein. >> Und wenn es auf einer SSD dafür notwendig ist, einen Speicherbereich >> anzulegen, der für Anwenderdaten tabu ist, dann muß eben genau das ab >> Werk passieren. > > Das kann man so sehen, aber man verschenkt dann halt Kapazität, da jedes > halbwegs moderne OS TRIM unterstützt. Interessant wird das, wenn das Filesystem nicht direkt auf der SSD sitzt sondern da noch einige Layer zwischen sind. Volumemanager, Cryptolayer... Gerrit
[toc] | [prev] | [next] | [standalone]
| From | Volker Bartheld <news2022@bartheld.net> |
|---|---|
| Date | 2022-11-15 22:09 +0100 |
| Message-ID | <q05z6acacvos.dlg@news.bartheld.net> |
| In reply to | #328960 |
On Tue, 15 Nov 2022 17:44:55 +0100, Gerrit Heitsch wrote: > On 11/15/22 17:23, Bernd Laengerich wrote: >> Am 15.11.2022 um 14:36 schrieb Volker Bartheld: >>> Ich finde es auch vergleichsweise merkwürdig, wenn ein Gerät [...] >>> irgendwelchen Voodoo zur Aufrechterhaltung des nach außen >>> garantierten Verhaltens benötigte. Das soll das Gerät [...] in >>> Eigenregie erledigen. >> Tut sie ja auch. Aber dazu ist es nötig, entweder TRIM zu unterstützen >> [...] *ODER*, wenn das OS dies nicht unterstützt, einen leeren >> Bereich [...]. >> Man muß nur dafür sorgen daß sie wirklich nie beschrieben wurden, also >> eine lediglich neu partitionierte gebrauchte SSD ist da ggf. ungeeignet. > Einmal ein SATA Secure Erase Kommando drüber und schon sollte das > Problem, so es eines ist, gelöst sein. Message-ID: <1swoaw81084c0$.dlg@news.bartheld.net> Das Problem könnte natürlich auch ein anderes gewesen sein. Das Sympton "SSD wird lahm" des nämlichen Exemplars besserte sich durch ein SATA Secure Erase jedenfalls nicht. Volker
[toc] | [prev] | [next] | [standalone]
| From | Michael Schwingen <news-1513678000@discworld.dascon.de> |
|---|---|
| Date | 2022-11-16 19:36 +0000 |
| Message-ID | <slrntnaetc.28h.news-1513678000@a-tuin.ms.intern> |
| In reply to | #328985 |
On 2022-11-15, Volker Bartheld <news2022@bartheld.net> wrote: > > Das Problem könnte natürlich auch ein anderes gewesen sein. Das Sympton > "SSD wird lahm" des nämlichen Exemplars besserte sich durch ein SATA > Secure Erase jedenfalls nicht. Ich habe hier das Gegenteil - das war eine SSD, die durch Betrieb in einem dauerlaufenden Router mit reichlich logging schnarchlangsam geworden war. Überschreiben mit Nullen hilft nicht. Nach einem secure erase ist die wieder flott. Das war eine 32GB von Apacer, also nicht unbedingt high-end. cu Michael
[toc] | [prev] | [next] | [standalone]
| From | Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> |
|---|---|
| Date | 2022-11-17 21:19 +0100 |
| Message-ID | <20221117211948.dca4f87e7fa6623becc163eb@SchS.de> |
| In reply to | #329047 |
Hallo Michael,
Du schriebst am 16 Nov 2022 19:36:12 GMT:
> Ich habe hier das Gegenteil - das war eine SSD, die durch Betrieb in
> einem dauerlaufenden Router mit reichlich logging schnarchlangsam
> geworden war. Überschreiben mit Nullen hilft nicht. Nach einem secure
> erase ist die wieder flott.
"Möglicherweise" hat die das Überschreiben mit Nullen als
"Vollschreiben" interpretiert, weil sie als Zustand "gelöscht" evtl.,
wie bei "vielen" elektronischen Festwertspeichern, den ansieht, in dem
alle Bits gesetzt ("1", "high") sind. Dazu hättest Du sie evtl. mit
lauter "0xFF" beschreiben müssen. Das ginge allerdings auch nur, wenn
sie nicht die Schreiboperationen in einem internen Bereich als solche
registriert, der nur mit diesem "secure erase" zurückgesetzt werden
kann. Es sagt einem halt kein( Herstell)er, was da in einzelnen abläuft.
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------
[toc] | [prev] | [next] | [standalone]
| From | Michael Schwingen <news-1513678000@discworld.dascon.de> |
|---|---|
| Date | 2022-11-18 17:35 +0000 |
| Message-ID | <slrntnfgjg.28h.news-1513678000@a-tuin.ms.intern> |
| In reply to | #329101 |
On 2022-11-17, Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> wrote:
>> Ich habe hier das Gegenteil - das war eine SSD, die durch Betrieb in
>> einem dauerlaufenden Router mit reichlich logging schnarchlangsam
>> geworden war. Überschreiben mit Nullen hilft nicht. Nach einem secure
>> erase ist die wieder flott.
>
> "Möglicherweise" hat die das Überschreiben mit Nullen als
> "Vollschreiben" interpretiert, weil sie als Zustand "gelöscht" evtl.,
> wie bei "vielen" elektronischen Festwertspeichern, den ansieht, in dem
> alle Bits gesetzt ("1", "high") sind.
Oder sie sieht sich die Daten überhaupt nicht an und schreibt die immer 1:1,
und man braucht halt trim oder secure erase, um Blöcke wirklich wieder
freizugeben. Zu den Interna der SSD-Firmwaren gibt es kaum detaillierte
Angaben.
Das ist aus meiner Sicht auch OK: trim und secure erase existieren und
funktionieren, das Überschreiben war nur ein Test um zu sehen, wie sich das
Teil verhält.
cu
Michael
[toc] | [prev] | [next] | [standalone]
| From | Bernd Laengerich <Bernd.Laengerich@web.de> |
|---|---|
| Date | 2022-11-18 22:31 +0100 |
| Message-ID | <jtqbtuF9hcdU1@mid.individual.net> |
| In reply to | #329131 |
Am 18.11.2022 um 18:35 schrieb Michael Schwingen: > Oder sie sieht sich die Daten überhaupt nicht an und schreibt die immer 1:1, > und man braucht halt trim oder secure erase, um Blöcke wirklich wieder > freizugeben. Zu den Interna der SSD-Firmwaren gibt es kaum detaillierte > Angaben. Sich die geschriebenen Daten nicht anzusehen wäre in erster Näherung ja auch sinnvoll und viel einfacher zu implementieren. Denn sonst müsste sich der SSD-Controller ja merken, daß Sektoren mit lauter 0en existieren die er recyclet hat. Und die beschreibbare Größe könnte die tatsächliche Größe übersteigen, je nach Inhalt. Und der Controller könnte dann out of memory laufen wenn jemand in die "leeren" Blöcke mal ein 1-Bit schreibt. Bernd
[toc] | [prev] | [next] | [standalone]
| From | olaf <olaf@criseis.ruhr.de> |
|---|---|
| Date | 2022-11-19 05:28 +0100 |
| Message-ID | <3k2m4j-2ls.ln1@criseis.ruhr.de> |
| In reply to | #329144 |
Bernd Laengerich <Bernd.Laengerich@web.de> wrote: >sinnvoll und viel einfacher zu implementieren. Denn sonst müsste sich der >SSD-Controller ja merken, daß Sektoren mit lauter 0en existieren die er >recyclet hat. Und die beschreibbare Größe könnte die tatsächliche Größe Solche Sektoren wird es nicht geben. DAs was eine SSD nach aussen hin als Sektor darstellt wird erheblich von den inneren Dastellungen abweichen. Da wird es immer noch Zusatzdaten fuer Pruefsummen Korrekturwerte geben. Olaf
[toc] | [prev] | [next] | [standalone]
| From | Michael Schwingen <news-1513678000@discworld.dascon.de> |
|---|---|
| Date | 2022-11-19 10:16 +0000 |
| Message-ID | <slrntnhb8d.28h.news-1513678000@a-tuin.ms.intern> |
| In reply to | #329144 |
On 2022-11-18, Bernd Laengerich <Bernd.Laengerich@web.de> wrote: > > Sich die geschriebenen Daten nicht anzusehen wäre in erster Näherung ja auch > sinnvoll und viel einfacher zu implementieren. Denn sonst müsste sich der > SSD-Controller ja merken, daß Sektoren mit lauter 0en existieren die er > recyclet hat. Das geht im Aufwand der sowieso vorhandenen internen Verwaltung (wear levelling, garbage collection etc.) vermutlich unter. In realen Nutzungsszenarien kommt das aber vermutlich so selten vor, daß es nicht lohnt, dafür so eine Optimierung einzubauen (und potentielle Fehlerquellen). Bei Dateisystemen sind solche Optimierungen für Dateien mit 0 oder wenigen Bytes durchaus gängig, d.h. man bringt die Daten im Verzeichniseintrag unter und belegt keinen Datensektor. > Und die beschreibbare Größe könnte die tatsächliche Größe > übersteigen, je nach Inhalt. Und der Controller könnte dann out of memory > laufen wenn jemand in die "leeren" Blöcke mal ein 1-Bit schreibt. Andersrum: die so geparten Blöcke werden dem Reservepool zugeschlagen, der Benutzer merkt nichts davon, aber die SSD hat intern mehr Platz zum ummappen. Eine SSD hat *immer* intern deutlich mehr Blöcke als die nach aussen sichtbare Kapazität, alleine, um im Betrieb ausfallende Blöcke ersetzen zu können (und für eine effiziente garbage collection, wear-levelling etc). cu Michael
[toc] | [prev] | [next] | [standalone]
| From | Hanno Foest <hurga-news2@tigress.com> |
|---|---|
| Date | 2022-11-15 18:21 +0100 |
| Message-ID | <jti041F83hsU1@mid.individual.net> |
| In reply to | #328957 |
Am 15.11.22 um 17:23 schrieb Bernd Laengerich: > Tut sie ja auch. Aber dazu ist es nötig, entweder TRIM zu unterstützen > (hier wird dem Controller halt vom OS mitgeteilt welche Blöcke gerade > frei werden) *ODER*, wenn das OS dies nicht unterstützt, einen leeren > Bereich (da diese Blöcke nie beschrieben werden, sind sie immer frei). > Man muß nur dafür sorgen daß sie wirklich nie beschrieben wurden, also > eine lediglich neu partitionierte gebrauchte SSD ist da ggf. ungeeignet. Secure Erase könnte helfen. Ist aber unklar, wie der jeweilige Hersteller das implementiert. https://www.antary.de/2015/01/18/ssd-secure-erase-was-ist-das-und-informationen-zur-durchfuehrung/ Oder man skriptet einen TRIM auf alle Blöcke. hab ich noch nicht gemacht, sollte aber ja wohl gehen. >> Und wenn es auf einer SSD dafür notwendig ist, einen Speicherbereich >> anzulegen, der für Anwenderdaten tabu ist, dann muß eben genau das ab >> Werk passieren. > > Das kann man so sehen, aber man verschenkt dann halt Kapazität, da jedes > halbwegs moderne OS TRIM unterstützt. Na ja, wenige Prozent. Früher war TRIM ein Problem, wenn man Linux mit Systemverschlüsselung einsetzte, aber inzwischen geht das wohl auch. Hanno -- The modern conservative is engaged in one of man's oldest exercises in moral philosophy; that is, the search for a superior moral justification for selfishness. - John Kenneth Galbraith
[toc] | [prev] | [next] | [standalone]
| From | Ole Jansen <remove.this.kaspernasebaer@gmx.de> |
|---|---|
| Date | 2022-11-16 07:31 +0100 |
| Message-ID | <jtjeebFf7giU1@mid.individual.net> |
| In reply to | #328957 |
Am 15.11.22 um 17:23 schrieb Bernd Laengerich: > Tut sie ja auch. Aber dazu ist es nötig, entweder TRIM zu unterstützen > (hier wird dem Controller halt vom OS mitgeteilt welche Blöcke gerade > frei werden) *ODER*, wenn das OS dies nicht unterstützt, einen leeren > Bereich (da diese Blöcke nie beschrieben werden, sind sie immer frei). > Man muß nur dafür sorgen daß sie wirklich nie beschrieben wurden, also > eine lediglich neu partitionierte gebrauchte SSD ist da ggf. ungeeignet. Schwund ist immer dabei. Alle SSDs haben als Reserve oder für Verlagerung physisch mehr Speicher als logisch. Der Grad der Überprovisionierung kann von 7% bei Consumer bis 50 Prozent für spezielle Serverplatten betragen. Einige Hersteller bieten Werkzeuge an mit denen sich die Überprovisionierung nachträglich anpassen lässt. O.J.
[toc] | [prev] | [next] | [standalone]
| From | Guido Grohmann <guido.grohmann@gmx.de> |
|---|---|
| Date | 2022-11-15 18:01 +0100 |
| Message-ID | <jthuvcF891lU1@mid.individual.net> |
| In reply to | #328935 |
Gerrit Heitsch schrieb: > Wie sie das lösen ist mir egal, es muss nur stabil funktionieren und > auch einen Stromausfall überstehen. Ein Stromausfall ist nicht das Problem. Ein Problem bekommst du dann, Wenn eine SSD jahrelang unbenutzt herumliegt, ohne einmal Strom zu sehen. Dann gehen deine Daten u.U. in den Orkus. BTDT. Guido
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2022-11-15 18:09 +0100 |
| Message-ID | <tl0h18$9bn$7@news.bawue.net> |
| In reply to | #328962 |
On 11/15/22 18:01, Guido Grohmann wrote: > Gerrit Heitsch schrieb: > >> Wie sie das lösen ist mir egal, es muss nur stabil funktionieren und >> auch einen Stromausfall überstehen. > > Ein Stromausfall ist nicht das Problem. Ein Problem bekommst du dann, > Wenn eine SSD jahrelang unbenutzt herumliegt, ohne einmal Strom zu > sehen. Dann gehen deine Daten u.U. in den Orkus. BTDT. Ja, kenne ich. Wenn dann auch noch die Firmware der SSD auf dem Flash ist und im echten 'ROM' nur ein Bootloader hast du eine SSD gehabt. Ich hab eine SSD in einem externen 2.5" Gehäuse, die brauche ich selten. Zur Sicherheit hänge ich die alle paar Monate für einen Tag an den Rechner damit sie Strom hat und der Controller seinen Job machen kann. Gerrit
[toc] | [prev] | [next] | [standalone]
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
Back to top | Article view | de.sci.electronics
csiph-web