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 1 of 6 [1] 2 3 4 5 6 Next page →
| From | Helmut Schellong <rip@schellong.biz> |
|---|---|
| Date | 2022-11-03 18:04 +0100 |
| Subject | Re: [OT-Frage] Sicherer Speicher für wichtige Daten |
| Message-ID | <tk0sbd$c972$1@solani.org> |
|On 03/17/2021 12:11, Helmut Schellong wrote: On 03/17/2021 10:16, Hanno Foest wrote: > Am 17.03.21 um 00:52 schrieb Helmut Schellong: > >> Wenn allerdings lediglich 2 Festplatten eines Backup-Systems >> innerhalb eines Zeitraumes von 5 Jahren durch Verschleiß >> defekt werden, ist ein gleichzeitiger Defekt extrem unwahrscheinlich. >> Das ergibt sich auch durch Anwendung von Wahrscheinlichkeitsrechnung. > > Sind die Ereignisse unabhängig voneinander? Zeitabhängiger Serienfehler? > |Unabhängige Ereignisse. |Das war war hier ja von Beginn an der Tenor, bei der |Bildung eines Backup-Systems. |Auch ich selbst nutze ein solches Backup-System. |Bei dem Beispiel oben betrachte ich den Zeitraum |nach dem flachen Teil der Badewannenkurve. |Dort beginnen ja die Ausfälle wegen Verschleiß. |Model Family: Western Digital RE2 Serial ATA |Device Model: WDC WD5000YS-01MPB0 |ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE | 1 Raw_Read_Error_Rate 0x000f 200 200 051 Pre-fail Always - 0 | 3 Spin_Up_Time 0x0003 210 206 021 Pre-fail Always - 6500 | 4 Start_Stop_Count 0x0032 094 094 000 Old_age Always - 6577 | 5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0 | 7 Seek_Error_Rate 0x000f 200 200 051 Pre-fail Always - 0 | 9 Power_On_Hours 0x0032 051 051 000 Old_age Always - 35799 | 10 Spin_Retry_Count 0x0013 100 100 051 Pre-fail Always - 0 | 11 Calibration_Retry_Count 0x0012 100 100 051 Old_age Always - 0 | 12 Power_Cycle_Count 0x0032 095 095 000 Old_age Always - 5356 |194 Temperature_Celsius 0x0022 253 253 000 Old_age Always - 53 |196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0 |197 Current_Pending_Sector 0x0012 200 200 000 Old_age Always - 0 |198 Offline_Uncorrectable 0x0010 200 200 000 Old_age Offline - 0 |199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0 |200 Multi_Zone_Error_Rate 0x0009 200 200 051 Pre-fail Offline - 0 |Model Family: Western Digital RE3 Serial ATA |Device Model: WDC WD1002FBYS-01A6B0 |ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE | 1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 0 | 3 Spin_Up_Time 0x0027 253 253 021 Pre-fail Always - 1300 | 4 Start_Stop_Count 0x0032 096 096 000 Old_age Always - 4386 | 5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0 | 7 Seek_Error_Rate 0x002e 200 200 000 Old_age Always - 0 | 9 Power_On_Hours 0x0032 059 059 000 Old_age Always - 30561 | 10 Spin_Retry_Count 0x0032 100 100 000 Old_age Always - 0 | 11 Calibration_Retry_Count 0x0032 100 100 000 Old_age Always - 0 | 12 Power_Cycle_Count 0x0032 096 096 000 Old_age Always - 4352 |192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 631 |193 Load_Cycle_Count 0x0032 199 199 000 Old_age Always - 4386 |194 Temperature_Celsius 0x0022 104 096 000 Old_age Always - 46 |196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0 |197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0 |198 Offline_Uncorrectable 0x0030 200 200 000 Old_age Offline - 0 |199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0 |200 Multi_Zone_Error_Rate 0x0008 200 200 000 Old_age Offline - 0 http://www.schellong.de/htm/defekt.htm Nun ist auch die zweite alte Festplatte defekt gegangen. Mit etwa 13 Monaten zeitlichem Abstand. Es ist folglich extrem unwahrscheinlich, daß zwei Festplatten gleichzeitig defekt gehen, so daß sie ab sofort keinen Datenverkehr mehr erlauben. -- Mit freundlichen Grüßen Helmut Schellong var@schellong.biz http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/math87.htm http://www.schellong.de/htm/dragon.c.html
[toc] | [next] | [standalone]
| From | Hanno Foest <hurga-news2@tigress.com> |
|---|---|
| Date | 2022-11-03 22:47 +0100 |
| Message-ID | <jsir7uFdbf4U1@mid.individual.net> |
| In reply to | #328504 |
On 03.11.22 18:04, Helmut Schellong wrote: > Nun ist auch die zweite alte Festplatte defekt gegangen. > Mit etwa 13 Monaten zeitlichem Abstand. > > Es ist folglich extrem unwahrscheinlich, daß zwei Festplatten > gleichzeitig defekt gehen, > so daß sie ab sofort keinen Datenverkehr mehr erlauben. Statistik am Einzelfall, immer wieder sehr beliebt. Und dann kommt sowas https://en.wikipedia.org/wiki/Deskstar#IBM_Deskstar_75GXP_failures und man guckt in die Röhre. 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 | Guido Grohmann <guido.grohmann@gmx.de> |
|---|---|
| Date | 2022-11-04 07:33 +0100 |
| Message-ID | <jsjq23Fhs8aU1@mid.individual.net> |
| In reply to | #328521 |
Hanno Foest schrieb: > On 03.11.22 18:04, Helmut Schellong wrote: > >> Nun ist auch die zweite alte Festplatte defekt gegangen. >> Mit etwa 13 Monaten zeitlichem Abstand. >> >> Es ist folglich extrem unwahrscheinlich, daß zwei Festplatten >> gleichzeitig defekt gehen, >> so daß sie ab sofort keinen Datenverkehr mehr erlauben. > > Statistik am Einzelfall, immer wieder sehr beliebt. Und dann kommt sowas > > https://en.wikipedia.org/wiki/Deskstar#IBM_Deskstar_75GXP_failures Wir hatten die Dinger im Einsatz und die sind gestorben wie die Fliegen. Die steckten in den Servern in einem Raid-Käfig, ich hatte durchweg RAID 1 verwendet. Manchmal mehrfach pro Woche hab ich eine defekte HDD irgendwo rausgezogen und eine neue reingeschoben. Irgendwann bekam ich dann mal PLatten eines anderen Herstellers, da war der Spuk vorbei. Es ist tatsächich nie der Fall eingetreten, daß 2 HDDs eines RAID1 gleichzeitig kaputtgegangen sind. Nie! Hab mein Backup zum Glück nie gebraucht. Das müssen so 50+ Einzelfälle gewesen sein. Guido
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2022-11-04 07:41 +0100 |
| Message-ID | <tk2c58$89o$1@news.bawue.net> |
| In reply to | #328530 |
On 11/4/22 07:33, Guido Grohmann wrote: > Es ist tatsächich nie der Fall eingetreten, daß 2 HDDs eines RAID1 > gleichzeitig kaputtgegangen sind. Dann hast du Glück gehabt. Ich hatte das und es waren nicht einmal die erwähnten IBM. Da es das Boot-RAID1 war, war danach der komplette Server offline und man musste erst einmal ein Minimal-OS installieren bevor man das Backup zurückspielen konnte. War kein schöner Tag. Gerrit
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <rip@schellong.biz> |
|---|---|
| Date | 2022-11-04 10:03 +0100 |
| Message-ID | <tk2kgq$d1or$1@solani.org> |
| In reply to | #328531 |
On 11/04/2022 07:41, Gerrit Heitsch wrote: > On 11/4/22 07:33, Guido Grohmann wrote: > >> Es ist tatsächich nie der Fall eingetreten, daß 2 HDDs eines RAID1 gleichzeitig kaputtgegangen sind. > > Dann hast du Glück gehabt. Nein, er hat den Normalfall erlebt. Man kann die Wahrscheinlichkeit, daß eine Festplatte überhaupt defekt wird, vielleicht durch 15 Mio. dividieren, um die Wahrscheinlichkeit zu erhalten, daß zwei Festplatten innerhalb derselben Sekunde defekt werden. -- Mit freundlichen Grüßen Helmut Schellong var@schellong.biz http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/math87.htm http://www.schellong.de/htm/dragon.c.html
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2022-11-04 10:09 +0100 |
| Message-ID | <tk2kpu$89o$5@news.bawue.net> |
| In reply to | #328540 |
On 11/4/22 10:03, Helmut Schellong wrote: > On 11/04/2022 07:41, Gerrit Heitsch wrote: >> On 11/4/22 07:33, Guido Grohmann wrote: >> >>> Es ist tatsächich nie der Fall eingetreten, daß 2 HDDs eines RAID1 >>> gleichzeitig kaputtgegangen sind. >> >> Dann hast du Glück gehabt. > > Nein, er hat den Normalfall erlebt. > > Man kann die Wahrscheinlichkeit, daß eine Festplatte überhaupt > defekt wird, vielleicht durch 15 Mio. dividieren, um die Wahrscheinlichkeit > zu erhalten, daß zwei Festplatten innerhalb derselben Sekunde defekt > werden. Innerhalb derselben Sekunde? Das ist eine deutlich längere Zeit in der die zweite HD eines RAID1 nicht sterben darf. Nämlich die Zeit von der Meldung, daß eine HD defekt ist bis zu dem Zeitpunkt an dem der Resync des RAID1 erledigt ist. Das sind eher Stunden, mit Pech mehr als 1 Tag. Noch schöner ist, daß die zweite HD schon defekt sein kann, es aber bisher noch nicht aufgefallen ist weil der defekte Bereich schon länger nicht mehr gelesen wurde. Beim Resync wird aber alles gelesen und dann fällt es auf. Gerrit
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <rip@schellong.biz> |
|---|---|
| Date | 2022-11-04 15:32 +0100 |
| Message-ID | <tk37pa$dbn5$1@solani.org> |
| In reply to | #328542 |
On 11/04/2022 10:09, Gerrit Heitsch wrote: > On 11/4/22 10:03, Helmut Schellong wrote: >> On 11/04/2022 07:41, Gerrit Heitsch wrote: >>> On 11/4/22 07:33, Guido Grohmann wrote: >>> >>>> Es ist tatsächich nie der Fall eingetreten, daß 2 HDDs eines RAID1 gleichzeitig kaputtgegangen sind. >>> >>> Dann hast du Glück gehabt. >> >> Nein, er hat den Normalfall erlebt. >> >> Man kann die Wahrscheinlichkeit, daß eine Festplatte überhaupt >> defekt wird, vielleicht durch 15 Mio. dividieren, um die Wahrscheinlichkeit >> zu erhalten, daß zwei Festplatten innerhalb derselben Sekunde defekt werden. > > Innerhalb derselben Sekunde? Das ist eine deutlich längere Zeit in der die zweite HD eines RAID1 nicht sterben darf. Nämlich die Zeit von der Meldung, daß eine HD defekt ist bis zu dem Zeitpunkt an dem der Resync des RAID1 erledigt ist. Das sind eher Stunden, mit Pech mehr als 1 Tag. > > Noch schöner ist, daß die zweite HD schon defekt sein kann, es aber bisher noch nicht aufgefallen ist weil der defekte Bereich schon länger nicht mehr gelesen wurde. Beim Resync wird aber alles gelesen und dann fällt es auf. > Man stelle sich vor, 10 Millionen Festplatten werden mit sehr hoher Wahrscheinlichkeit innerhalb des kommenden halben Jahres defekt gehen. Ein halbes Jahr hat etwa 15 Millionen Sekunden. Es kann gut sein, daß dabei gar keine >1 Festplatten in derselben Sekunde defekt gehen. Wie verhält sich das, wenn nur 2 statt 10000000 Festplatten betrachtet werden? Es gibt hier eine Ähnlichkeit zu dem Spiel, wo Kugeln vertikal durch ein Feld aus Nägeln und abschließend in Aufbewahrungs-Röhren fallen. -- Mit freundlichen Grüßen Helmut Schellong var@schellong.biz http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/math87.htm http://www.schellong.de/htm/dragon.c.html
[toc] | [prev] | [next] | [standalone]
| From | Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> |
|---|---|
| Date | 2022-11-04 22:16 +0100 |
| Message-ID | <20221104221611.49b8adffebc0aab845c47668@SchS.de> |
| In reply to | #328556 |
Hallo Helmut, Du schriebst am Fri, 4 Nov 2022 15:32:18 +0100: > Man stelle sich vor, 10 Millionen Festplatten werden mit sehr hoher > Wahrscheinlichkeit innerhalb des kommenden halben Jahres defekt gehen. > Ein halbes Jahr hat etwa 15 Millionen Sekunden. > Es kann gut sein, daß dabei gar keine >1 Festplatten in derselben > Sekunde defekt gehen. > > Wie verhält sich das, wenn nur 2 statt 10000000 Festplatten > betrachtet werden? Das verhält sich halt so, daß Statistik recht zufällig individuelle Ergebnisse liefert. -- (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 | Helmut Schellong <rip@schellong.biz> |
|---|---|
| Date | 2022-11-05 12:51 +0100 |
| Message-ID | <tk5inn$fdgi$1@solani.org> |
| In reply to | #328567 |
On 11/04/2022 22:16, Sieghard Schicktanz wrote: > Hallo Helmut, > > Du schriebst am Fri, 4 Nov 2022 15:32:18 +0100: > >> Man stelle sich vor, 10 Millionen Festplatten werden mit sehr hoher >> Wahrscheinlichkeit innerhalb des kommenden halben Jahres defekt gehen. >> Ein halbes Jahr hat etwa 15 Millionen Sekunden. >> Es kann gut sein, daß dabei gar keine >1 Festplatten in derselben >> Sekunde defekt gehen. >> >> Wie verhält sich das, wenn nur 2 statt 10000000 Festplatten >> betrachtet werden? > > Das verhält sich halt so, daß Statistik recht zufällig individuelle > Ergebnisse liefert. > Es geht um Wahrscheinlichkeiten und Wahrscheinlichkeitsrechnung. Die Wahrscheinlichkeit sinkt (auf den ersten Blick) auf ein 5000000-stel der ersten Wahrscheinlichkeit: w2 = w1 / (10000000/2) (Die mathematische Darstellung einer Wahrscheinlichkeit ist hier undefiniert.) -- Mit freundlichen Grüßen Helmut Schellong var@schellong.biz http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/math87.htm http://www.schellong.de/htm/dragon.c.html
[toc] | [prev] | [next] | [standalone]
| From | Rolf Bombach <rolfnospambombach@invalid.invalid> |
|---|---|
| Date | 2022-11-05 11:43 +0100 |
| Message-ID | <tk5ep5$2df97$1@dont-email.me> |
| In reply to | #328556 |
Helmut Schellong schrieb: > > Man stelle sich vor, 10 Millionen Festplatten werden mit sehr hoher Wahrscheinlichkeit > innerhalb des kommenden halben Jahres defekt gehen. > Ein halbes Jahr hat etwa 15 Millionen Sekunden. > Es kann gut sein, daß dabei gar keine >1 Festplatten in derselben Sekunde defekt gehen. Die Platten gehen aber unabhängig voneinander spontan kaputt. Es gibt zwei Grenzfälle: - Eine Uhr tickt ein mal pro Sekunde. - Ein Geigerzähler tickt ein mal pro Sekunde. Wir sind nahe an Grenzfall 2. Also Stochastik. Die sagt, dass die Wahrscheinlichkeit eines Plattenausfalls am grössten ist unmittelbar nach einem andern Plattenausfall. Danach nimmt sie exponentiell ab. Wahrscheinlich werden zumindest phasenweise¹ mehr Platten innerhalb einer Sekunde kaputt gehen als ausserhalb. Ja, psychologisch ist das schwer fassbar, aber leicht statistisch erfassbar. ¹Sobald sehr viele weg sind, werden natürlich immer weniger kaputt gehen. > Wie verhält sich das, wenn nur 2 statt 10000000 Festplatten betrachtet werden? Dann passiert das seltener. > Es gibt hier eine Ähnlichkeit zu dem Spiel, wo Kugeln vertikal durch ein Feld aus Nägeln > und abschließend in Aufbewahrungs-Röhren fallen. Damit hat das exakt gar nichts zu tun. -- mfg Rolf Bombach
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <rip@schellong.biz> |
|---|---|
| Date | 2022-11-05 15:20 +0100 |
| Message-ID | <tk5ret$fiaq$1@solani.org> |
| In reply to | #328578 |
On 11/05/2022 11:43, Rolf Bombach wrote: > Helmut Schellong schrieb: >> >> Man stelle sich vor, 10 Millionen Festplatten werden mit sehr hoher Wahrscheinlichkeit >> innerhalb des kommenden halben Jahres defekt gehen. >> Ein halbes Jahr hat etwa 15 Millionen Sekunden. >> Es kann gut sein, daß dabei gar keine >1 Festplatten in derselben Sekunde defekt gehen. > > Die Platten gehen aber unabhängig voneinander spontan kaputt. Ja, bei dieser Betrachtung sind die Abhängigkeiten voneinander vernachlässigbar. > Es gibt zwei Grenzfälle: > - Eine Uhr tickt ein mal pro Sekunde. > - Ein Geigerzähler tickt ein mal pro Sekunde. > > Wir sind nahe an Grenzfall 2. Also Stochastik. Die sagt, > dass die Wahrscheinlichkeit eines Plattenausfalls am > grössten ist unmittelbar nach einem andern Plattenausfall. > Danach nimmt sie exponentiell ab. Ja, entsprechende Punktewolken enthalten fast immer stoßweise Häufungen. > Wahrscheinlich werden zumindest phasenweise¹ mehr Platten > innerhalb einer Sekunde kaputt gehen als ausserhalb. > Ja, psychologisch ist das schwer fassbar, aber leicht > statistisch erfassbar. > > ¹Sobald sehr viele weg sind, werden natürlich immer weniger > kaputt gehen. Ich hatte mir 1978 einen TI59 mit mehreren Zusatzmodulen gekauft und mich sehr intensiv damit beschäftigt. Ich bin hinsichtlich der Themen Wahrscheinlichkeitsrechnung, Statistik, Verteilungen, Lineare Regression, Kombinatorik, etc., ein kleiner Experte. Psychologie spielt bei meinen solchen Betrachtungen nie eine Rolle. >> Wie verhält sich das, wenn nur 2 statt 10000000 Festplatten betrachtet werden? > > Dann passiert das seltener. Ja, sehr sehr sehr sehr sehr sehr viel seltener. Es geht auch hier um eine Wahrscheinlichkeit. Gegenüberstellung: Bei wievielen Testläufen von 1 Million kommt es statistisch vor, daß diese jew. beiden Festplatten innerhalb derselben Sekunde (von 15 Mio. Sek.) kaputt gehen? Höchstwahrscheinlich in gar keinem Testlauf dieser 1 Mio. Testläufe! Es ist auch unwahrscheinlich, daß die erste Festplatte in Sekunde x und die zweite Festplatte in Sekunde x+1 kaputt geht. Jedoch bei 10 Mio. statt zwei Festplatten ist es wahrscheinlicher, daß es nicht wenige Sekunden gibt, während denen jeweils so 2..7 Festplatten kaputt gehen. >> Es gibt hier eine Ähnlichkeit zu dem Spiel, wo Kugeln vertikal durch ein Feld aus Nägeln >> und abschließend in Aufbewahrungs-Röhren fallen. > > Damit hat das exakt gar nichts zu tun. > Es geht mir hier von Anfang an immer nur um einen jeweiligen Endzustand, nicht um einen inneren Verlauf. Und dabei gibt es zweifellos eine Ähnlichkeit, wie ich schrieb: Die Anzahl Kugeln entsprechen der Anzahl Festplatten. Die Anzahl Aufbewahrungs-Röhren entsprechen der Anzahl Sekunden. http://www.schellong.de/htm/defekt.htm#zweite -- Mit freundlichen Grüßen Helmut Schellong var@schellong.biz http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html http://www.schellong.de/htm/deutsche_bahn.htm http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/math87.htm http://www.schellong.de/htm/dragon.c.html
[toc] | [prev] | [next] | [standalone]
| From | "Peter Heirich" <talk.usenet@info21.heirich.name> |
|---|---|
| Date | 2022-11-05 00:01 +0000 |
| Message-ID | <xn0nozeif4o6hjv001@news.heirich.name> |
| In reply to | #328542 |
Gerrit Heitsch wrote: >Noch schöner ist, daß die zweite HD schon defekt sein kann, es aber >bisher noch >nicht aufgefallen ist weil der defekte Bereich schon länger nicht mehr >gelesen >wurde. Beim Resync wird aber alles gelesen und dann fällt es auf. M.E. eher unwahrscheinlich. In einem ordentlich designten Sytem sollte minimal 1x die Woche der Virenscanner alles mal prüfen. Peter
[toc] | [prev] | [next] | [standalone]
| From | Volker Bartheld <news2022@bartheld.net> |
|---|---|
| Date | 2022-11-05 07:48 +0100 |
| Message-ID | <1wmpxrwcfwci$.dlg@news.bartheld.net> |
| In reply to | #328568 |
> Gerrit Heitsch wrote: >> Noch schöner ist, daß die zweite HD schon defekt sein kann, es aber >> bisher noch nicht aufgefallen ist weil der defekte Bereich schon >> länger nicht mehr gelesen wurde. Beim Resync wird aber alles gelesen >> und dann fällt es auf. On Sat, 5 Nov 2022 00:01:47 -0000 (UTC), Peter Heirich wrote: > M.E. eher unwahrscheinlich. In einem ordentlich designten Sytem sollte > minimal 1x die Woche der Virenscanner alles mal prüfen. Warum? Welche Relevanz hätte die Existenz von Virensignaturen z. B. auf einem NAS, das Dateien zwar schreibt und liest, aber nie ausführt? Ich würde mich außerdem schönstens bedanken, wenn irgendein "ordentlich designtes System" 1x/Woche meine 4TB an Mediendaten durchschrabbelt. Und selbst wenn das passierte: Bist Du sicher, daß z. B. in einer RAID-1-Architektur tatsächlich beide Kopien gelesen werden und nicht etwa nur die, die grad am opportunsten ist? "Zur Erhöhung der Sicherheit kann ein RAID-1-System beim Lesen stets auf mehr als eine Festplatte zugreifen. Dabei werden die Antwortdatenströme der Festplatten verglichen. Bei Unstimmigkeiten wird eine Fehlermeldung ausgegeben, da die Spiegelung nicht länger besteht. Diese Funktion bieten nur wenige Controller an, auch reduziert sie die Geschwindigkeit des Systems geringfügig." [1] liest sich nicht so, als sei das ein Feature, auf das man sich verlassen könnte. Volker [1] https://de.wikipedia.org/wiki/RAID#RAID_1:_Mirroring_%E2%80%93_Spiegelung
[toc] | [prev] | [next] | [standalone]
| From | Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> |
|---|---|
| Date | 2022-11-05 20:49 +0100 |
| Message-ID | <20221105204939.f7143d95c0d606764814fa74@SchS.de> |
| In reply to | #328571 |
Hallo Volker, Du schriebst am Sat, 5 Nov 2022 07:48:11 +0100: > ausführt? Ich würde mich außerdem schönstens bedanken, wenn irgendein > "ordentlich designtes System" 1x/Woche meine 4TB an Mediendaten > durchschrabbelt. Wird Dir aber nicht erspart bleiben - wenn auch evtl. mit anderen Abständen - wenn das Zeugs auf SSDs liegt. Die brauchen "gelegentlich" mal eine Auffrischung, bevor die Fehlerkorrektur die Daten nicht mehr wiederherstellen kann. > Und selbst wenn das passierte: Bist Du sicher, daß z. B. in einer > RAID-1-Architektur tatsächlich beide Kopien gelesen werden und nicht > etwa nur die, die grad am opportunsten ist? Nee, da werden schon beide gelesen, wenn der Controller gut ist, und zwar so ineinander verschachtelt (aka "interleaved"), daß die Daten möglichst schneller komplett gelesen sind, als das eine einzelne Platte schaffen könnte. (Relativiert sich aber wohl derzeit wegen der SSDs.) -- (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-06 13:18 +0000 |
| Message-ID | <slrntmfd0e.28h.news-1513678000@a-tuin.ms.intern> |
| In reply to | #328604 |
On 2022-11-05, Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> wrote:
> Nee, da werden schon beide gelesen, wenn der Controller gut ist, und
> zwar so ineinander verschachtelt (aka "interleaved"), daß die Daten
> möglichst schneller komplett gelesen sind, als das eine einzelne Platte
> schaffen könnte. (Relativiert sich aber wohl derzeit wegen der SSDs.)
Wieso sollta man die doppelte Datenmenge lesen und dann 50% wegwerfen, wenn
man auf Lesegeschwindigkeit optimieren will?
Will sagen: es wird 50% vom einen und die anderen 50% vom anderen Laufwerk
gelesen (ja, interleaved). Das gibt doppeltes Tempo, aber keinen
100%-Lesetest.
Bei Linux-md-RAID gibt es eine check-Funktion, die periodisch ausgeführt das
tut, was man wirklich braucht (man 4 md):
As storage devices can develop bad blocks at any time it is valuable to
regularly read all blocks on all devices in an array so as to catch
such bad blocks early. This process is called scrubbing.
md arrays can be scrubbed by writing either check or repair to the file
md/sync_action in the sysfs directory for the device.
Requesting a scrub will cause md to read every block on every device in
the array, and check that the data is consistent. For RAID1 and
RAID10, this means checking that the copies are identical. For RAID4,
RAID5, RAID6 this means checking that the parity block is (or blocks
are) correct.
If a read error is detected during this process, the normal read-error
handling causes correct data to be found from other devices and to be
written back to the faulty device. In many case this will effectively
fix the bad block.
Debian macht das per Default 1* im Monat.
Wie man das bei anderen Raid-Systemen macht, bleibt dem Leser als
Rechercheaufgabe überlassen.
cu
Michael
[toc] | [prev] | [next] | [standalone]
| From | Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> |
|---|---|
| Date | 2022-11-06 21:45 +0100 |
| Message-ID | <20221106214537.ee67e0f20299928aacb98853@SchS.de> |
| In reply to | #328618 |
Hallo Michael, Du schriebst am 6 Nov 2022 13:18:06 GMT: > > Nee, da werden schon beide gelesen, wenn der Controller gut ist, und > > zwar so ineinander verschachtelt (aka "interleaved"), daß die Daten > > möglichst schneller komplett gelesen sind, als das eine einzelne ... > Wieso sollta man die doppelte Datenmenge lesen und dann 50% > wegwerfen, wenn man auf Lesegeschwindigkeit optimieren will? Wie machst Du das dann, wenn Du nicht verhindern kannst, daß die Daten ständig unter dem Lesekopf durchrauschen und Du zudem sicherstellen mußt, daß auch die richtigen Daten jeweils den Weg zur Anwendung finden? Klar, wenn das letzte Byte von Platte X im Buffer gelandet ist, kann man Platte Y ignorieren. Weiterlaufen wird die trotzdem. Ja, wie ja geschrieben: das relativiert sich wohl aktuell mit der Verbreitung der SSDs, aber sogar die haben Geschwindigkeitsgrenzen. > Will sagen: es wird 50% vom einen und die anderen 50% vom anderen > Laufwerk gelesen (ja, interleaved). Das gibt doppeltes Tempo, aber > keinen 100%-Lesetest. Von "Lesetest" war ja auch nicht die Rede. -- (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-07 21:11 +0000 |
| Message-ID | <slrntmit3a.28h.news-1513678000@a-tuin.ms.intern> |
| In reply to | #328627 |
On 2022-11-06, Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> wrote: >> Wieso sollta man die doppelte Datenmenge lesen und dann 50% >> wegwerfen, wenn man auf Lesegeschwindigkeit optimieren will? > > Wie machst Du das dann, wenn Du nicht verhindern kannst, daß die Daten > ständig unter dem Lesekopf durchrauschen und Du zudem sicherstellen > mußt, daß auch die richtigen Daten jeweils den Weg zur Anwendung > finden? Das macht die Platte selber. Wenn ich erst Block 0-99 anfordere und dann 200-299, seekt die halt passend - das ist jedenfalls nicht langsamer, als die unbenutzten Blöcke 100-199 ebenfalls zu lesen, ins RAM zu transferieren und dann wegzuwerfen, und die Daten liegen ohne umkopieren da, wo sie gebraucht werden. Der Datentransfer per SATA incl. Bufferhandling, Interrupts etc. ist nicht gratis, also lohnt es, von jeder Platte nur die Daten zu lesen, die man wirklich braucht. > Klar, wenn das letzte Byte von Platte X im Buffer gelandet ist, > kann man Platte Y ignorieren. Weiterlaufen wird die trotzdem. > Ja, wie ja geschrieben: das relativiert sich wohl aktuell mit der > Verbreitung der SSDs, aber sogar die haben Geschwindigkeitsgrenzen. > >> Will sagen: es wird 50% vom einen und die anderen 50% vom anderen >> Laufwerk gelesen (ja, interleaved). Das gibt doppeltes Tempo, aber >> keinen 100%-Lesetest. > > Von "Lesetest" war ja auch nicht die Rede. Doch, es wurde argumentiert, daß durch das doppelte Lesen sichergestellt sei, daß die Daten lesbar & OK seien - das ist nicht der Fall, ein Lesefehler auf einem der Blöcke wird mit 50% Wahrscheinlichkeit beim einmaligen Lesen des RAID-Devices nicht bemerkt. cu Michael
[toc] | [prev] | [next] | [standalone]
| From | Hanno Foest <hurga-news2@tigress.com> |
|---|---|
| Date | 2022-11-07 22:02 +0100 |
| Message-ID | <jsta2nF19tfU1@mid.individual.net> |
| In reply to | #328604 |
On 05.11.22 20:49, Sieghard Schicktanz wrote: >> ausführt? Ich würde mich außerdem schönstens bedanken, wenn irgendein >> "ordentlich designtes System" 1x/Woche meine 4TB an Mediendaten >> durchschrabbelt. > > Wird Dir aber nicht erspart bleiben - wenn auch evtl. mit anderen > Abständen - wenn das Zeugs auf SSDs liegt. Die brauchen "gelegentlich" > mal eine Auffrischung, bevor die Fehlerkorrektur die Daten nicht mehr > wiederherstellen kann. Das machen die aber intern, dazu muß man nicht selber Hand anlegen. 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 | Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> |
|---|---|
| Date | 2022-11-08 21:49 +0100 |
| Message-ID | <20221108214945.3602053702be828b6078f2ab@SchS.de> |
| In reply to | #328642 |
Hallo Hanno, Du schriebst am Mon, 7 Nov 2022 22:02:14 +0100: > >> irgendein "ordentlich designtes System" 1x/Woche meine 4TB an > >> Mediendaten durchschrabbelt. > > > > Wird Dir aber nicht erspart bleiben - wenn auch evtl. mit anderen > > Abständen - wenn das Zeugs auf SSDs liegt. Die brauchen > > "gelegentlich" mal eine Auffrischung, bevor die Fehlerkorrektur die > > Daten nicht mehr wiederherstellen kann. > > Das machen die aber intern, dazu muß man nicht selber Hand anlegen. Ja, das ist schon richtig. Aber damit sie das machen können, müssen sie halt in Betrieb sein und nicht stromlos rumstehen oder (z.B. im Schrank) -liegen -- (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 | Volker Bartheld <news2022@bartheld.net> |
|---|---|
| Date | 2022-11-09 16:39 +0100 |
| Message-ID | <1u1k2angbxq9q.dlg@news.bartheld.net> |
| In reply to | #328660 |
On Tue, 8 Nov 2022 21:49:45 +0100, Sieghard Schicktanz wrote: > Du schriebst am Mon, 7 Nov 2022 22:02:14 +0100: >>>> irgendein "ordentlich designtes System" 1x/Woche meine 4TB an >>>> Mediendaten durchschrabbelt. >>> Wird Dir aber nicht erspart bleiben - wenn auch evtl. mit anderen >>> Abständen - wenn das Zeugs auf SSDs liegt. Die brauchen >>> "gelegentlich" mal eine Auffrischung, bevor die Fehlerkorrektur die >>> Daten nicht mehr wiederherstellen kann. >> Das machen die aber intern, dazu muß man nicht selber Hand anlegen. > Ja, das ist schon richtig. Aber damit sie das machen können, müssen sie > halt in Betrieb sein und nicht stromlos rumstehen oder (z.B. im Schrank) > -liegen Und HDDs als RAID-Verbund würden einen scrub machen, während sie stromlos im NAS liegen? Datenfehler schleichen sich auch auf HDDs nicht nur im laufenden Betrieb ein. Vol"Die Flüchtigkeit von Daten auf unbenutzten SSD wird deutlich überbewertet, zumindest insofern man die Dinger nicht monate- und jahrelang verstauben läßt."ker
[toc] | [prev] | [next] | [standalone]
Page 1 of 6 [1] 2 3 4 5 6 Next page →
Back to top | Article view | de.sci.electronics
csiph-web