Re: [OT-Frage] Sicherer Speicher für wichtige Daten

[Helmut Schellong]

|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 v...@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

[Hanno Foest]

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

[Leo Baumann]

Am 03.11.2022 um 18:04 schrieb Helmut Schellong:
> Nun ist auch die zweite alte Festplatte defekt gegangen.
> Mit etwa 13 Monaten zeitlichem Abstand.

Ihr könnt mich für übervorsichtig halten.

Ich habe meine Daten alle 2 Mal redundant gespiegelt auf ext. HDDs.
Zur Vorsicht habe ich nochmal eine Kopie in der IONOS-Cloud für 3 € pro
Monat.
Die Synchronisation mache ich mit DirSync.

Wichtige dauernde Daten, fertige Projekte, Software, Internet-Seite habe
ich zusätzlich auf CD, DVD, DVD-DL.

Grüße

[Guido Grohmann]

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

[Gerrit Heitsch]

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

[Helmut Schellong]

Ich bin hier derjenige, der bereits seit Jahren mehrfach gepostet hat, daß er
Backup auf einer zweiten Festplatte, und auf ein oder gar zwei Speicherkarten, und
in der Cloud (1 €) vornimmt.
Wegen der Cloud habe ich mehrere Verschlüsselungs-Algorithmen in C implementiert
undein Verschlüsselungs-Skript entwickelt.
Auch alles mehrfach gepostet; steht auch zum Teil in meiner Signatur.

[Helmut Schellong]

On 11/03/2022 22:47, Hanno Foest wrote:
> 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.

Ich beachte _nur_ eigene konkrete Erfahrungen und _solche_ aus meinem Umfeld.
Betreffend Festplatten und PC-Netzteile.

Diese sagen mir ganz klar, daß es extrem unwahrscheinlich ist, daß zwei Festplatten
zum gleichen Zeitpunkt defekt gehen und sofort keinen Datenverkehr mehr zulassen.

Ich verwende seit Jahrzehnten ausnahmslos Festplatten WD Gold Enterprise 24/7.
IBM produziert seit Jahrzehnten keine mehr - und ist damit irrelevant.

[Helmut Schellong]

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.

[Gerrit Heitsch]

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

[Hanno Foest]

On 04.11.22 09:49, Helmut Schellong wrote:

>> 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.
>
> Ich beachte _nur_ eigene konkrete Erfahrungen und _solche_ aus meinem
> Umfeld.
> Betreffend Festplatten und PC-Netzteile.

Das ist hierzugroups zweifellos bekannt, daß dein geistiger Horizont
eingeschränkt ist, und du unfähig bist, über deinen Tellerrand
hinauszugucken.

[Hanno Foest]

On 04.11.22 10:03, Helmut Schellong 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 weiß demnach, daß das nicht der Normalfall ist, wenn die Daten
aufgrund eines RAID1-Doppelausfalls futsch sind. Toll, kann man sich
sicher viel für kaufen.

> 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? Erst mal muß du es merken, dann muß das
Ersatzteil da sein, und schließlich der Resync durch. Platten sterben
gerne gerade bei der höheren Belastung beim Resync...

[Helmut Schellong]

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.

[Helmut Schellong]

On 11/04/2022 14:53, Hanno Foest wrote:
> On 04.11.22 09:49, Helmut Schellong wrote:
>
>>> 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.
>>
>> Ich beachte _nur_ eigene konkrete Erfahrungen und _solche_ aus meinem Umfeld.
>> Betreffend Festplatten und PC-Netzteile.
>
> Das ist hierzugroups zweifellos bekannt, daß dein geistiger Horizont eingeschränkt ist, und du unfähig bist, über deinen Tellerrand hinauszugucken.
>

Es ist anders herum:
Ich kann mich nur auf eigene konkrete Erfahrungen _verlassen_.
Betreffend eigene Hardware und Hardware in meinem Umfeld.
Hinter dem Tellerrand habe ich zu oft Müll gelesen und erfahren.

[Helmut Schellong]

On 11/04/2022 14:57, Hanno Foest wrote:
> On 04.11.22 10:03, Helmut Schellong 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 weiß demnach, daß das nicht der Normalfall ist, wenn die Daten aufgrund eines RAID1-Doppelausfalls futsch sind. Toll, kann man sich sicher viel für kaufen.
>
>> 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? Erst mal muß du es merken, dann muß das Ersatzteil da sein, und schließlich der Resync durch. Platten sterben gerne gerade bei der höheren Belastung beim Resync...
>

.
Alles irrelevant.

Klärende Zusammenfassung:
==============================================================================================

On 11/04/2022 07:33, Guido Grohmann wrote:
|> 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.

Ich schrieb direkt zuvor:

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

==============================================================================================

Es geht nicht um Ersatzteile, Resync, und ähnlich.
Es geht nur um Spiegelung von Dateisystemen und Verzeichnissen, und
um die Wahrscheinlichkeit von gleichzeitigem Defekt von ≥2 Festplatten.
Ich mache das per Skript mit rsync.
Guido Grohman machte das mit RAID1.

Ich hatte nie IBM_Deskstar_75GXP in Gebrauch - dies ist also ebenso irrelevant.

[Guido Grohmann]

Gerrit Heitsch schrieb:

Wenn mir das passiert wäre, hätte ich zwei neue HDDs reingesteckt, die
Kiste von CD gebootet (Linux) und das Windows von einem Imageserver
wieder eingespielt. Dieses Image enthielt das System und die
erforderliche Datenbank-Software (Oracle). Die Datenbank selber befand
sich auf einem oder zwei weiteren RAID-Volumes. Ein paar Befehle später
fuhr die Bank wieder hoch, machte noch ein Instance-Recovery und war
wieder verfügbar. Je nach Alter des Betriebssystem-Images waren vor dem
Starten der DB noch ein paar bis ein paar mehr Windows-Updates nachzuziehen.

Ein Recovery einer defekten Datenbank nach Ausfall beider Platten eines
Datenbank-RAIDs hätte etwas länger gedauert.

Guido

[Volker Bartheld]

On Thu, 3 Nov 2022 22:47:42 +0100, Hanno Foest wrote:
> 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 [gleiche] Festplatten [im identischen Umfeld] 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.

Oder Du ha(tte)st ein Athlon-Motherboard mit einem Chipsatz der bei
DMA-Übertragung größerer Dateien die Daten klammheimlich korrumpiert.
Der altbekannte Pentium FDIV Bug ist nur die Spitze des Eisbergs,
seitdem wurden dutzende Male irgendwelche Bugs im Microcode
ausgebügelt. Auch gab es schon einige Firmwareupdates für SSDs, die
nicht nur mangelnde Performance sondern mögliche Integritätsprobleme
behoben. Hast Du mehrere von den Dingern mit identischem Patchlevel am
Start, geht es geht es plötzlich nicht mehr um zwei stochastisch
unabhängige Ereignisse und auf die versprochene MTBF ist vollkommen
geschissen.

Und last not least schlägt natürlich genau dann ein Überspannungshoppala
vom DSL-Hausanschluß auf die Netzwerkleitung durch, während das
ach-so-tolle RAID-5-System die gerade eben wegen defektem Spindelmotor
ausgetauschte Festplatte aufsynchronisiert.

Und über Layer-8-Einflüsse à la "erst löschen, dann kopieren" oder
robocopy /mir bzw. rsync --delete mit versehentlich vertauschtem Quell-
und Zielverzeichnis oder ein SSD-Secure-Erase auf dem falschen Gerät
haben wir noch gar nicht gesprochen.

Wenn Du dann nicht einen richtig guten Plan zur Datenwiederherstellung
hast, ist Deine digitale Existenz in Sekundenbruchteilen vernichtet.

Volker

[Volker Bartheld]

https://community.netgear.com/t5/Using-your-ReadyNAS-in-Business/Admin-page-unavailable-after-cancelled-backup-job-amp-hard/m-p/2142882/highlight/true#M193800

Das war echt haarscharf. Mutmaßliche Ursache: Externe Backupplatte
ausgeworfen, bevor der rsync-Job fertig war. Kein SSH Zugang
eingerichtet.

Volker

[Volker Bartheld]

On Fri, 4 Nov 2022 14:57:24 +0100, Hanno Foest wrote:
> On 04.11.22 10:03, Helmut Schellong 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 weiß demnach, daß das nicht der Normalfall ist, wenn die Daten
> aufgrund eines RAID1-Doppelausfalls futsch sind. Toll, kann man sich
> sicher viel für kaufen.
>> 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? Erst mal muß du es merken, dann muß das
> Ersatzteil da sein, und schließlich der Resync durch. Platten sterben
> gerne gerade bei der höheren Belastung beim Resync...

Nicht bei unserem allwissenden, allmächtigen Oberauskenner. Der Chuck
Norris der IT-Branche, wie er allein durch Stirnrunzeln den
festgefressenen Spindelmotor wieder gangbar macht.

Volker

[Helmut Schellong]

On 11/04/2022 19:31, Volker Bartheld wrote:
> On Fri, 4 Nov 2022 14:57:24 +0100, Hanno Foest wrote:
>> On 04.11.22 10:03, Helmut Schellong 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 weiß demnach, daß das nicht der Normalfall ist, wenn die Daten
>> aufgrund eines RAID1-Doppelausfalls futsch sind. Toll, kann man sich
>> sicher viel für kaufen.
>>> 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? Erst mal muß du es merken, dann muß das
>> Ersatzteil da sein, und schließlich der Resync durch. Platten sterben
>> gerne gerade bei der höheren Belastung beim Resync...
>
> Nicht bei unserem allwissenden, allmächtigen Oberauskenner.

Das ist korrekt.
Das was vorstehend geschrieben wurde, ist nämlich komplett irrelevant.
Wurde auch von Dir ignoriert.
Ebenso ignoriert Dein Posting von 19:25 einfach alles - irrelevant.
Es geht nur um das zeitliche Defektwerden von Festplatten.

> Der Chuck
> Norris der IT-Branche, wie er allein durch Stirnrunzeln den
> festgefressenen Spindelmotor wieder gangbar macht.
>

Ich setze mehrere spezielle Bisse auf der Festplatte, um sie zu reparieren.

[Sieghard Schicktanz]

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

[Peter Heirich]

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

[Volker Bartheld]

> 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

[Rolf Bombach]

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

[Helmut Schellong]

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

[Rolf Bombach]

Helmut Schellong schrieb:

>
> Ich beachte _nur_ eigene konkrete Erfahrungen und _solche_ aus meinem Umfeld.
> Betreffend Festplatten und PC-Netzteile.
>
> Diese sagen mir ganz klar, daß es extrem unwahrscheinlich ist, daß zwei Festplatten
> zum gleichen Zeitpunkt defekt gehen und sofort keinen Datenverkehr mehr zulassen.

Kommt doch auf den Ausfallmechanismus an. Jede Platte für sich, ja.
Allerdings gibt es auch gemeinsame Ursachen: Netzteil explodiert (BDTD),
Decke stürzt auf PC, Blitzschlag, Brand, Hochwasser (etwa 4 PCs hab
ich bei Feuerwehreinsätzen aus dem Wasser gezogen).

>
> Ich verwende seit Jahrzehnten ausnahmslos Festplatten WD Gold Enterprise 24/7.
> IBM produziert seit Jahrzehnten keine mehr - und ist damit irrelevant.

Die Kurven wurden hier gezeigt; fast alle Hersteller hatten
ihre Höhen und Tiefen. So schlecht wie WDC im Sommer 18 war
eigentlich kein anderer Hersteller. IBM ist jetzt wohl HGST,
die haben eigentlich sehr tiefe Ausfallraten.

--
mfg Rolf Bombach

[Michael Schwingen]

On 2022-11-05, Rolf Bombach <rolfnosp...@invalid.invalid> wrote:
>>
>> Diese sagen mir ganz klar, daß es extrem unwahrscheinlich ist, daß zwei Festplatten
>> zum gleichen Zeitpunkt defekt gehen und sofort keinen Datenverkehr mehr zulassen.
>
> Kommt doch auf den Ausfallmechanismus an. Jede Platte für sich, ja.
> Allerdings gibt es auch gemeinsame Ursachen: Netzteil explodiert (BDTD),
> Decke stürzt auf PC, Blitzschlag, Brand, Hochwasser (etwa 4 PCs hab
> ich bei Feuerwehreinsätzen aus dem Wasser gezogen).

+ Fertigungsfehler und Firmware-Bugs. Es gab da welche, die durchaus zum
Ausfall von 2 Platten kurz nacheinander (oder nach der gleichen Anzahl von
Einschaltvorgängen) führte, ich habe da mal bei einem RAID aus baugleichen
Seagate-Platten Daten retten dürfen.

Seitdem versuche ich, unterschiedliche Platten einzusetzen.

cu
Michael

[Helmut Schellong]

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

[Helmut Schellong]

On 11/05/2022 12:53, Rolf Bombach wrote:
> Helmut Schellong schrieb:
>>
>> Ich beachte _nur_ eigene konkrete Erfahrungen und _solche_ aus meinem Umfeld.
>> Betreffend Festplatten und PC-Netzteile.
>>
>> Diese sagen mir ganz klar, daß es extrem unwahrscheinlich ist, daß zwei Festplatten
>> zum gleichen Zeitpunkt defekt gehen und sofort keinen Datenverkehr mehr zulassen.
>
> Kommt doch auf den Ausfallmechanismus an. Jede Platte für sich, ja.

Genau so meine ich das, und genau so schreibe ich das überall.
Ich meine stets meinen Festplatten-Mirror in meinem PC.

> Allerdings gibt es auch gemeinsame Ursachen: Netzteil explodiert (BDTD),

Kenne ich; wurde vor Jahren schon hier besprochen.
Meine eigene Erfahrung zeigte mir bisher _nur_ Spannungen, die fehlerhaft klein waren.
Also z.B. 1,6V statt 12V, und vergleichbar.
Auch 5Vstb war mal plötzlich bei 0,8V.

> Decke stürzt auf PC, Blitzschlag, Brand, Hochwasser (etwa 4 PCs hab
> ich bei Feuerwehreinsätzen aus dem Wasser gezogen).

Ich kopiere auch in meine Cloud.

>> Ich verwende seit Jahrzehnten ausnahmslos Festplatten WD Gold Enterprise 24/7.
>> IBM produziert seit Jahrzehnten keine mehr - und ist damit irrelevant.
>
> Die Kurven wurden hier gezeigt; fast alle Hersteller hatten
> ihre Höhen und Tiefen. So schlecht wie WDC im Sommer 18 war
> eigentlich kein anderer Hersteller. IBM ist jetzt wohl HGST,
> die haben eigentlich sehr tiefe Ausfallraten.
>

Es kommt auch darauf an, aus welcher HDD-Familie gekauft wird.

Ich kenne grob die Historie von WDC.
Ganz früh, als Conner noch gängig war, war WDC gut.
Dann hatte WDC eine lange kritische Phase.
Danach, bis heute, habe ich keinen Grund zur Klage.
Seagate und WDC sind seit Jahrzehnten führend.
WDC hat Hitachi-HDD und Sandisk geschluckt.

[Rolf Bombach]

Michael Schwingen schrieb:

>
> + Fertigungsfehler und Firmware-Bugs. Es gab da welche, die durchaus zum
> Ausfall von 2 Platten kurz nacheinander (oder nach der gleichen Anzahl von
> Einschaltvorgängen) führte, ich habe da mal bei einem RAID aus baugleichen
> Seagate-Platten Daten retten dürfen.
>
> Seitdem versuche ich, unterschiedliche Platten einzusetzen.

Materialbeschaffer/Bewirtschafter einer Serverfarm dürfte
ein Albtraumberuf sein. Aber sicher interessant.

--
mfg Rolf Bombach

[Gerrit Heitsch]

On 11/4/22 17:04, Guido Grohmann wrote:
> Gerrit Heitsch schrieb:
>> 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.
>
> Wenn mir das passiert wäre, hätte ich zwei neue HDDs reingesteckt, die
> Kiste von CD gebootet (Linux) und das Windows von einem Imageserver
> wieder eingespielt.

Eine neue HD hatte ich... Eine zweite musste erst geliefert werden. Es
war ein Solaris-Server. Backup war vorhanden, aber damit man das
zurückspielen kann braucht man natürlich erst einmal ein Minimalsystem.

Die Daten selbst waren auf FCAL angebundenen LUNs.

Gerrit

[Gerrit Heitsch]

Virenscanner? Wir reden hier von Servern, nicht von Desktopsystemen und
Windows ist da schon gar nicht im Spiel.

Gerrit

[Michael Schwingen]

On 2022-11-05, Peter Heirich <talk....@info21.heirich.name> wrote:
>
> M.E. eher unwahrscheinlich. In einem ordentlich designten Sytem sollte
> minimal 1x die Woche der Virenscanner alles mal prüfen.

Virenscanner lesen nicht die ganze Datei ein, sondern nur die Teile, die zur
Untersuchung nötig sind.

cu
Michael

[Sieghard Schicktanz]

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

[Peter Heirich]

Volker Bartheld wrote:

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

Ich war etwas verkürzt.

Es geht nicht darum, das NAS selbst zu schützen.

Deshalb läuft auf meiner QNAP der QNAP-übliche Malware-Remover, der
eigentlich ein Clamav ist.

Sinn ist ein Zeitvorsprung in folgendem Szenario:

Eine nicht erkannte Ransom-ware wird u.a. auf dem NAS abgelegt. Da sie
dort nicht ausgeführt wurde, installiert sie auch nicht ihre "Tarnkappe".

Das entspricht etwa der "Ausschaltung" von Rootkits durch Boot von einem
frischen, geprüften Datenträger.

Wenn jetzt später diese Ransom-ware irgendwo auffällt und deshalb Eingang
in die Virensignaturen erhält, besteht die Chance, eine Ransom-ware zu
erkennen, bevor diese Totalschaden anrichtet.

Der Trick bei Ransom-ware ist ja, dass ein Rootkit installiert wird, über
längere Zeit die Dateien verschlüsselt und transparent entschlüsselt
werden. Ist das umfassend erledigt, wird der lokale Schlüssel weggeworfen
und man kann, wenn überhaupt, die Backupkopie des Schlüssels "käuflich
erwerben".

Aber: Ich hatte schon Sekunden nach dem Post die Erkenntnis, das
notwendige Backup nicht erwähnt zu haben. RAID ersetzt kein Backup, denn
sowohl Verschlüsselung durch Ransom-ware, als auch simples Löschen oder
Üerschreiben durch Viren bis Bedienfehler, werden auf RAID-Systemen
getreulich auf allen Platten ausgeführt.

Schon durch das Backup werden alle Dateien üblicherweise angefasst. Klar,
es gibt incrementelle oder differenzielle Backups, da dehnt sich die Zeit
der Erkennung bis zum Vollbackup.

Ich persönlich habe auf tägliches deduplizierendes Backup ( Borg ) für
Linux umgestellt. Da werden alle Dateien täglich komplett gelesen.

Um aber wieder etwas On-Topic zu werden:

Kennt jemand einen z.B. USB-Stick, der mit interner Elektronik
kryptographische Prüfsummen des Inhalts bildet und diesen Prüfsummenwert
auf Knopfdruck abspeichert. Stimmt die Prüfsumme nicht mehr, soll der
Stick blinken und quitschen, um Aufmerksamkeit zu erzeugen.

Sinn: Honey-pot für Ransom-ware.

Peter

[Gerrit Heitsch]

On 11/5/22 22:19, Peter Heirich wrote:
> Ich persönlich habe auf tägliches deduplizierendes Backup ( Borg ) für
> Linux umgestellt. Da werden alle Dateien täglich komplett gelesen.

Das möchte ich bezweifeln. Schon bei einstelligen TB würde es mehr als
24h dauern alle Daten zu lesen. Es gibt dazu auch einen Hinweis:

quick detection of unmodified files

deutet auf den üblichen Check von Filesize und Modification date hin.
Dazu braucht man die Datei selbst nicht zu lesen.

BTW: Folgendes würde mich von BORG Abstand halten lassen:

A chunk is considered duplicate if its id_hash value is identical.

Wenn der Hash kürzer ist als der Chunk ist das zwangsläufig nicht 100%
sicher.

Und:

EXPECT THAT WE WILL BREAK COMPATIBILITY REPEATEDLY WHEN MAJOR RELEASE
NUMBER CHANGES (like when going from 0.x.y to 1.0.0 or from 1.x.y to 2.0.0).

Alles von: https://borgbackup.readthedocs.io/en/stable/

Ich bleibe für meine Backups lieber bei rsync, Quelle und Ziel sind
Filesysteme und wenn man will kann man damit versionierte Backups
erstellen die an Timemaschine von MacOS erinnern. Wer wissen will wie
lese nach wie man die Option '--link-dest=<dir>' benutzt.

Gerrit

[Peter Heirich]

Gerrit Heitsch wrote:

>Das möchte ich bezweifeln. Schon bei einstelligen TB würde es mehr als
>24h dauern alle Daten zu lesen. Es gibt dazu auch einen Hinweis:
>
>quick detection of unmodified files

Gutes Argument, möglicherweise ist das sogar so.

Demnächst mal im Quellcode lesen und prüfen ob man das umgehen kann.

Und klar, sind Hash-Kollisionen eine Gefahr.

Ich denke aber, die Gefahr, dass ich selbst getötet werde und kein Backup
mehr brauche ist weit höher.


Peter

[Gerrit Heitsch]

Der Teufel ist ein Eichhörnchen...

Gerrit

[Gerrit Heitsch]

On 11/6/22 01:00, Peter Heirich wrote:

> Gerrit Heitsch wrote:
>
>> Das möchte ich bezweifeln. Schon bei einstelligen TB würde es mehr als
>> 24h dauern alle Daten zu lesen. Es gibt dazu auch einen Hinweis:
>>
>> quick detection of unmodified files
>
> Gutes Argument, möglicherweise ist das sogar so.
>
> Demnächst mal im Quellcode lesen und prüfen ob man das umgehen kann.

Bei 'rsync' kann man es mit der Option '-c'. Und ja, es macht einen
gigantischen Unterschied in der für ein Backup benötigten Zeit. Es
dauert dann immer gleich lang und zwar im Bereich wie das erste Vollbackup.

Gerrit

[Michael Schwingen]

On 2022-11-05, Sieghard Schicktanz <Sieghard....@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

[Laurenz Trossel]

On 2022-11-05, Rolf Bombach <rolfnosp...@invalid.invalid> wrote:

> Materialbeschaffer/Bewirtschafter einer Serverfarm dürfte
> ein Albtraumberuf sein. Aber sicher interessant.

https://www.backblaze.com/blog/backblaze-drive-stats-for-q3-2022/

[Sieghard Schicktanz]

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.

[Sieghard Schicktanz]

Hallo Peter,

Du schriebst am Sat, 5 Nov 2022 21:19:52 -0000 (UTC):

> Kennt jemand einen z.B. USB-Stick, der mit interner Elektronik
> kryptographische Prüfsummen des Inhalts bildet und diesen

Soll das dateiweise sein oder nach sonst einer Aufteilung?
Für dateiweise müßte der Stick selber sein Dateisystem kennen und
bearbeiten können - sowas gibt es AFAIK nicht. (Allerdings habe ich
schon einen Stick, nicht mal gehabt, der _nur_ mit FAT richtig
funktioniert. Ext4 mochte er garnicht, da gab's Fehler, langsame
Übertragung, sogar Hänger. Re(!)formatierung mit FAT machte das wieder
"gut", damit läuft er bisher ohne Auffälligkeit. Sachen gibt's...)

> Prüfsummenwert auf Knopfdruck abspeichert. Stimmt die Prüfsumme nicht
> mehr, soll der Stick blinken und quitschen, um Aufmerksamkeit zu
> erzeugen.

Dafür brauchte er eine recht umfängliche Elektronik, wie ie in den
üblichen Controllern sicher nicht vorhanden ist. Und die Signalisierung
braucht noch weitere Elemente - sehr handlich wird das Ding wohl nicht.
Aber ein kleines Platinchen (Raspberry Pico?) mit so 'nem Ding könnte
einfach gehen und nicht allzu umfangreich ausfallen?

> Sinn: Honey-pot für Ransom-ware.

Dazu müßte sowas reichen.

[Hanno Foest]

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

[Michael Schwingen]

On 2022-11-06, Sieghard Schicktanz <Sieghard....@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

[Helmut Schellong]

On 11/03/2022 18:04, Helmut Schellong wrote:
> |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:
>>

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

http://www.schellong.de/htm/defekt.htm#zweite

Ich habe die neue Festplatte in Betrieb genommen.
Es sind nun zwei gleiche aktuelle mit 2TB in Verwendung.
Die Transfergeschwindigkeit stieg von 65 MB/s auf 160 MB/s.

[Alexander Schreiber]

Eh, Sorgen um den Ausfall einzelner Platten macht man sich nur
bei kleinen Installationen, wo alles in maximal ein/zwei Racks passt.

Bei grossen Installation ist alles so ausgelegt, dass man fest davon
ausgeht, dass:
- jede Einzelkomponente (Platte, Maschine, ...) wird irgendwann ausfallen
- es ist genug Redundanz vorhanden, das einfach abzufangen

Dabei reicht die Redundanz je nach System über die ganze Skala:
- Festplatte/SSD
- Maschine
- Rack
- Datacenter
- Datacenter Campus
- Stadtbereich
- Kontinentweites Rechennetz

Man liest sich,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison

[Sieghard Schicktanz]

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

[Volker Bartheld]

On Sat, 5 Nov 2022 20:49:39 +0100, Sieghard Schicktanz wrote:
> Du schriebst am Sat, 5 Nov 2022 07:48:11 +0100:

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

Da soll sich bitte die Firmware der SSD selbst drum kümmern.

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

Genau. ;-)

Volker

[Volker Bartheld]

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

[Volker Bartheld]

On Sat, 5 Nov 2022 21:19:52 -0000 (UTC), Peter Heirich wrote:
> Volker Bartheld wrote:
>> [Virenscan auf externem Speicher] Welche Relevanz hätte die Existenz

>> von Virensignaturen z. B. auf einem NAS, das Dateien zwar schreibt
>> und liest, aber nie ausführt?

> Es geht nicht darum, das NAS selbst zu schützen.

Auch mein PC muß nicht vor Virensignaturen geschützt werden, die sich
rein zufällig in einer Videodatei befinden.

Oder schmeißt Dein Newsreader im Ernst eine Warnung bei diesem QR-Code?

▄▄▄▄▄▄▄ ▄ ▄▄ ▄ ▄▄▄ ▄▄▄▄▄▄▄
█ ▄▄▄ █ ▄▀ ▄ ▀ █ ▀ ▀▀▀█▀▀ █ ▄▄▄ █
█ ███ █ █ ███▀ ██▄▄▀█▄▀ █ ███ █
█▄▄▄▄▄█ ▄ █▀█▀█▀█ █▀▄▀█▀█ █▄▄▄▄▄█
▄▄▄ ▄▄▄▄█ ▀▄▀ ██▀ ▀█▀▀ ▀▄▄ ▄
▀▀▀ ▄▀▄▀▄██▀ ▄▀▀▀█ ▄ ▄█▀▄▀▄▄▄
█ ▀▄▄█▄▀▀▀█▄▀██▀▀▀ ▀▀█▄ ▄██▀ ▄
▄ ▄▄▀█▄ █▀▀ ▀▄▀▀ ▄▀▀█▄ ▄█ ▄▄▀█
███▀ ▄ █▄█▀▄██ ▀▀▀▄▀▀ ▄▀▄██ ▄▄▀
▀ ▀▄▀█▄█▄ ███▀ ▀▀█▀▀█▀▄▀▀▀▀ ▄▀▄█▄
▀ ▀▄▄▄▀▄▄▄▄▀▀ ▀█▀ ▀█▀▀ ▄█▄█▄ ▄▄▄
▄ █▀█▀▄▄▄ ▀▀ ▄▀█ ▄▀███▀▀ ▄ ▄█▄ █
▄▀ ██▀▄▄ ▀▄█▄▀▀▀▀▄██▄ ██▄▄█▄▄▀
▄▄▄▄▄▄▄ ██ ██▄▄▀▀██▀▀ ▄█ ▄ █▀▄▄▄
█ ▄▄▄ █ █ ▀▄█▀▀██▀ ▀▄▀▀▀█▄▄▄█▄▄█▄
█ ███ █ ▄█ ▀▄ ▄ ▀▀▀███ ▄▄▄▄█▀█▄
█▄▄▄▄▄█ █▄ ▄▄█▄ ▀▀▀▀▀▀▀█ ▀█▄█ █▄

> Deshalb läuft auf meiner QNAP der QNAP-übliche Malware-Remover, der
> eigentlich ein Clamav ist. Sinn ist ein Zeitvorsprung in folgendem
> Szenario: Eine nicht erkannte Ransom-ware wird u.a. auf dem NAS
> abgelegt.

Nicht erkannt von wem? Auf dem PC, der auf das NAS schreibt? Sollte der
nicht einen On-the-Fly-Virenscanner haben, der ihm verbietet,
virenhaltige Dateien überhaupt anzufassen?

> Da sie dort nicht ausgeführt wurde, installiert sie auch nicht ihre
> "Tarnkappe". Das entspricht etwa der "Ausschaltung" von Rootkits
> durch Boot von einem frischen, geprüften Datenträger. Wenn jetzt
> später diese Ransom-ware irgendwo auffällt und deshalb Eingang in die
> Virensignaturen erhält, besteht die Chance, eine Ransom-ware zu
> erkennen, bevor diese Totalschaden anrichtet.

Totalschaden, weil irgendein Client diese Datei vom NAS liest und
unreflektiert ausführt? Je nun. Hört man in der Windowswelt öfter, daß
es eine schlechte Idee ist, einfach irgendwelche .exe zu starten.

Ja, zugegeben, es traten schon Fälle auf, wo eine "Mediendatei" (also
Dokumente bis hin zu simplen Bildern) so instrumentiert wurden, daß sie
einen Fehler im Dateibetrachter ausnutzten, um Schadcode auszuführen.

> Der Trick bei Ransom-ware ist ja, dass ein Rootkit installiert wird, über
> längere Zeit die Dateien verschlüsselt und transparent entschlüsselt
> werden.

Dazu ist kein Rootkit notwendig, außer Du verwendest eine sehr lockere
Definition. Administratorrechte ("root") benötigst Du zum Verschlüsseln
der Benutzerdateien nicht. Es reicht, die entsprechende Software im
Userkontext auszuführen.

> Ich persönlich habe auf tägliches deduplizierendes Backup ( Borg ) für
> Linux umgestellt. Da werden alle Dateien täglich komplett gelesen.

Dem Stichwort "Linux" entnehme ich, daß Du ohnehin schon die
wesentlichen Vorkehrungsmaßnahmen zu Virenabwehr getroffen hast.

Volker

[Volker Bartheld]

On Sat, 5 Nov 2022 22:44:55 +0100, Gerrit Heitsch wrote:
> On 11/5/22 22:19, Peter Heirich wrote:
>> Ich persönlich habe auf tägliches deduplizierendes Backup ( Borg ) für
>> Linux umgestellt. Da werden alle Dateien täglich komplett gelesen.

> BTW: Folgendes würde mich von BORG Abstand halten lassen:
> A chunk is considered duplicate if its id_hash value is identical.

> EXPECT THAT WE WILL BREAK COMPATIBILITY REPEATEDLY WHEN MAJOR RELEASE
> NUMBER CHANGES (like when going from 0.x.y to 1.0.0 or from 1.x.y to 2.0.0).
> Alles von: https://borgbackup.readthedocs.io/en/stable/

Ups.

> Ich bleibe für meine Backups lieber bei rsync

Halte ich genauso. Ein mächtiger Befehl, der bislang alles leisten
konnte, was ich in puncto Backup verlangte. Der Sinn am Backup ist ja
auch, daß es leicht und sicher von der Hand geht, ohne potentielle
Fallstricke, nervtötdende Softwareinstalliererei und sonstiges Gehampel.

Volker

[Gerrit Heitsch]

Ja, einmal hingesetzt und ein brauchbares Script geschrieben und schon
ist das Backup schmerzfrei. Da Backup ein Abbild des Filesystems ist ist
der Restore einfach, den mache ich im Falle eines Falles mit passenden
'cp -a' Kommandos.

Gerrit

[Gregor Szaktilla]

Am 09.11.22 um 16:55 schrieb Volker Bartheld:
> [...] Der Sinn am Backup ist ja

> auch, daß es leicht und sicher von der Hand geht, ohne potentielle
> Fallstricke, nervtötdende Softwareinstalliererei und sonstiges Gehampel.

Deshalb fahre ich mittlerweile mein „brutalstmögliches Deppen-Backup“:
Da Plattenplatz mittlerweile kein Problem mehr darstellt, kopiere ich
meine wichtigsten Daten (das komplette home-Verzeichnis) unkomprimiert
per 'cp -ar /home /media/backup'.

Gruß

Gregor



--
Sehrsehr! Vielviel!

Jaja.

[Gerrit Heitsch]

Kann man tun. Es ist aber eine gute Idee sich in rsync kurz mal
einzuarbeiten. Dann geht das Backup schneller.

BTW: Das 'r' kannst du weglassen, 'cp -a' reicht.

Gerrit

[Sieghard Schicktanz]

Hallo Volker,

Du schriebst am Wed, 9 Nov 2022 16:39:49 +0100:

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

Vergleich mal ein paar Zeitkonstanten für die Zerfallsraten.

> 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

Eben, "monate- und jahrelang", nicht jahrzehntelang. "Durchkopieren"
wie bei Bändern gibt's bei Magnetplatten schließlich nicht,

[Sieghard Schicktanz]

Hallo Volker,

Du schriebst am Wed, 9 Nov 2022 16:35:10 +0100:

> >> "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.
>
> Da soll sich bitte die Firmware der SSD selbst drum kümmern.

Tut sie ja auch - wenn Du sie läßt und genug Reserve da ist und Du
immer schön brav Dein "Trim" gemacht hast. (Sonst behält sie auch
den ältesten Müll und kann irgendwann garnichts mehr schreiben.)

[Gerrit Heitsch]

On 11/9/22 22:00, Sieghard Schicktanz wrote:
> Hallo Volker,
>
> Du schriebst am Wed, 9 Nov 2022 16:35:10 +0100:
>
>>>> "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.
>>
>> Da soll sich bitte die Firmware der SSD selbst drum kümmern.
>
> Tut sie ja auch - wenn Du sie läßt und genug Reserve da ist und Du
> immer schön brav Dein "Trim" gemacht hast. (Sonst behält sie auch
> den ältesten Müll und kann irgendwann garnichts mehr schreiben.)

TRIM braucht man nicht, underprovisioning tut es auch, also einen
Bereich der SSD bei der Partitionierung ausnehmen und nie direkt benutzen.

Gerrit

[Volker Bartheld]

On Wed, 9 Nov 2022 21:58:17 +0100, Sieghard Schicktanz wrote:
> Du schriebst am Wed, 9 Nov 2022 16:39:49 +0100:
>> 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.
> Vergleich mal ein paar Zeitkonstanten für die Zerfallsraten.

Die Zeitkonstante für "Runterfallen" liegt bei HDDs im Bereich weniger
Millisekunden. Wie ich hörte, vertragen magnetische Datenträger auch
einen Wohnungsbrand nicht so gut. Klar, das ist ein Mißbrauchsszenario
und auch durch regelmäßigen scrub nicht zu antizipieren. Ich hatte aber
durchaus schon Platten, bei denen nach ein paar Jahren des Müßiggangs
der Spindelmotor nicht mehr anlaufen wollte. Und was moderne
heliumgefüllte Exemplare machen, wenn sich das Helium mal verpißt hat,
weiß man auch nicht so genau.

https://www.nidec.com/en/technology/casestudy/helium_hdd/

Backblaze scheint bislang keine Auffälligkeiten entdeckt zu haben:

https://www.backblaze.com/blog/helium-filled-hard-drive-failure-rates/

Nur darauf verlassen, daß die vernachlässigbare Verbreiterung der
magnetischen Domänen deutlich unterhalb der Curie-Temperatur der
einzige Effekt ist, der zum Datenverlust führt, würde ich mich
jedenfalls nicht.

Auch ein nettes Video: https://www.youtube.com/watch?v=AaZ_RSt0KP8

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

> Eben, "monate- und jahrelang", nicht jahrzehntelang. "Durchkopieren"
> wie bei Bändern gibt's bei Magnetplatten schließlich nicht,

Wer magnetische Speicher nicht regelmäßig umkopiert (mit "regelmäßig"
wie in "spätestens alle paar Jahre"), sollte seine Hand für die Daten
jedenfalls nicht ins Feuer legen. YMMV.

Volker

[Sieghard Schicktanz]

Hallo Gerrit,

Du schriebst am Thu, 10 Nov 2022 07:15:03 +0100:

> TRIM braucht man nicht, underprovisioning tut es auch, also einen
> Bereich der SSD bei der Partitionierung ausnehmen und nie direkt
> benutzen.

Hmmm. Was macht der Controller dann, wenn er wirklich alle verfügbaren
Blöcke mit Daren beschrieben hat, aber für keinen die Erlaubnis zum
Überschreiben? Schön, er kann sowas teils dadurch erkennen, daß er für
dieselbe Adresse jetzt andere Daten schreiben soll. Reicht das, ist da
halt die Frage.

[Sieghard Schicktanz]

Hallo Volker,

Du schriebst am Thu, 10 Nov 2022 11:18:52 +0100:

[elektronische vs. magnetische Speicherung]

> > Vergleich mal ein paar Zeitkonstanten für die Zerfallsraten.
>
> Die Zeitkonstante für "Runterfallen" liegt bei HDDs im Bereich weniger
> Millisekunden. Wie ich hörte, vertragen magnetische Datenträger auch
> einen Wohnungsbrand nicht so gut. Klar, das ist ein Mißbrauchsszenario
> und auch durch regelmäßigen scrub nicht zu antizipieren. Ich hatte
> aber durchaus schon Platten, bei denen nach ein paar Jahren des
> Müßiggangs der Spindelmotor nicht mehr anlaufen wollte. Und was
> moderne heliumgefüllte Exemplare machen, wenn sich das Helium mal
> verpißt hat, weiß man auch nicht so genau.

Jasicher. Auch einen (N)EMP werden Magnetplatten nicht ganz schadlos
überstehen, und nach einem Vulkanausbruch mit drüberfließender Lava
dürften sie auch nicht mehr gut funktionieren.
Katastrophenszenarien sind als Vergleichsgrundlage für die Haltbarkeit
vieler Dinge meist schlecht brauchbar, wenn es sich um die Angaben bei
ordentlicher Handhabung dreht. Aber wenn immer gleich wer durchdreht,
sind halt solche Abschätzungen meist "für'd Katz'".

[Gerrit Heitsch]

On 11/10/22 22:07, Sieghard Schicktanz wrote:
> Hallo Gerrit,
>
> Du schriebst am Thu, 10 Nov 2022 07:15:03 +0100:
>
>> TRIM braucht man nicht, underprovisioning tut es auch, also einen
>> Bereich der SSD bei der Partitionierung ausnehmen und nie direkt
>> benutzen.
>
> Hmmm. Was macht der Controller dann, wenn er wirklich alle verfügbaren
> Blöcke mit Daren beschrieben hat, aber für keinen die Erlaubnis zum
> Überschreiben?

Wenn er einen neuen Block zum Beschreiben holt wird doch ein alter frei
den er bei Gelegenheit löschen und in den Pool freier Blöcke zurücklegen
kann. Das der frei ist weiss der Controller weil er ihn ja gerade durch
einen anderen ersetzt hat.

Crucial erwähnte mal irgendwo, daß ihre SSDs 'garbage collection' können.

Gerrit

[Gerrit Heitsch]

On 11/10/22 11:18, Volker Bartheld wrote:

> Und was moderne
> heliumgefüllte Exemplare machen, wenn sich das Helium mal verpißt hat,
> weiß man auch nicht so genau.

Immerhin kann man bei den HDs von WDC den 'Heliumstand' via SMART
abfragen, ist Attribut 22. Neu steht der Wert auf 100 und bei unter 25
gilt die Platte als nicht mehr sicher.

Auf reddit erwähnte jemand bei einer seiner HDs wäre der Wert inzwischen
bei 13 angekommen, aber die HD würde weiter fehlerlos laufen.

Gerrit

[Michael Schwingen]

On 2022-11-10, Gerrit Heitsch <ger...@laosinh.s.bawue.de> wrote:
> Immerhin kann man bei den HDs von WDC den 'Heliumstand' via SMART
> abfragen, ist Attribut 22. Neu steht der Wert auf 100 und bei unter 25
> gilt die Platte als nicht mehr sicher.

Wie messen die das? Ich gehe mal davon aus, da die keinen extra Sensor
dafür verbauen?

cu
Michael

[Rolf Bombach]

Michael Schwingen schrieb:

Vielleicht ein Wärmeleitsensor. Da reicht eine kleine Glühlampe
ohne Gehäuse.

https://www.researchgate.net/publication/249509685_On_the_gas_species_dependence_of_Pirani_vacuum_gauges

--
mfg Rolf Bombach

[Rolf Bombach]

Gerrit Heitsch schrieb:

>
> TRIM braucht man nicht, underprovisioning tut es auch, also einen Bereich der SSD bei der Partitionierung ausnehmen und nie direkt benutzen.

Overprovisioning?

--
mfg Rolf Bombach

[Leo Baumann]

Am 11.11.2022 um 23:14 schrieb Rolf Bombach:
> Gerrit Heitsch schrieb:
>>
>> TRIM braucht man nicht, underprovisioning tut es auch, also einen
>> Bereich der SSD bei der Partitionierung ausnehmen und nie direkt
>> benutzen.
>
> Overprovisioning?

Ich habe von meiner 500 GB Samsung 980 Pro 30% für Overprov. gespendet.

:)

[Sieghard Schicktanz]

Hallo Michael,

Du schriebst am 11 Nov 2022 19:04:43 GMT:

> > Immerhin kann man bei den HDs von WDC den 'Heliumstand' via SMART

...

> Wie messen die das? Ich gehe mal davon aus, da die keinen extra
> Sensor dafür verbauen?

Möglicherweise einfach thermisch. Helium hat eine sehr hohe
Wärmeleitfähigkeit, so daß sich ein Heizelement darin erheblich weniger
erwärmt als in Luft. Den Unterschied, der natürlich vom Einbau abhängt,
kann man dann messen und bewerten.

[Sieghard Schicktanz]

Hallo Gerrit,

Du schriebst am Thu, 10 Nov 2022 22:16:24 +0100:

> > Hmmm. Was macht der Controller dann, wenn er wirklich alle
> > verfügbaren Blöcke mit Daren beschrieben hat, aber für keinen die
> > Erlaubnis zum Überschreiben?
>
> Wenn er einen neuen Block zum Beschreiben holt wird doch ein alter
> frei den er bei Gelegenheit löschen und in den Pool freier Blöcke

Nicht unbedingt - wenn die geänderten Daten nur einen Teil der in dem
alten Block enthaltenen ersetzen, muß der alte Block solange aufgehoben
werden, bis alles darin ungültig geworden ist. Die Größe der internen
Blöcke ("Erase Units") hat mit der Größe der extern sichtbaren
Verwaltungseinheiten ("Sektoren") erstmal nichts zu tun. Allerdings
wurde wohl auch aus dem Grund die "Sektorgröße" moderner Platten auf
4KByte erhöht. Dann passt das etwas besser mit den internen Strukturen
zusammen.

> Crucial erwähnte mal irgendwo, daß ihre SSDs 'garbage collection'
> können.

Mag sein, aber dazu müssen sie halt erstmal definitiv "wissen", was
genau "garbage" ist.

[Gerrit Heitsch]

On 11/11/22 23:14, Rolf Bombach wrote:
> Gerrit Heitsch schrieb:
>>
>> TRIM braucht man nicht, underprovisioning tut es auch, also einen
>> Bereich der SSD bei der Partitionierung ausnehmen und nie direkt
>> benutzen.
>
> Overprovisioning?

Wie soll das bitte gehen?

Gerrit

[Gerrit Heitsch]

On 11/11/22 22:22, Sieghard Schicktanz wrote:
> Hallo Gerrit,
>
> Du schriebst am Thu, 10 Nov 2022 22:16:24 +0100:
>
>>> Hmmm. Was macht der Controller dann, wenn er wirklich alle
>>> verfügbaren Blöcke mit Daren beschrieben hat, aber für keinen die
>>> Erlaubnis zum Überschreiben?
>>
>> Wenn er einen neuen Block zum Beschreiben holt wird doch ein alter
>> frei den er bei Gelegenheit löschen und in den Pool freier Blöcke
>
> Nicht unbedingt - wenn die geänderten Daten nur einen Teil der in dem
> alten Block enthaltenen ersetzen, muß der alte Block solange aufgehoben
> werden, bis alles darin ungültig geworden ist.

Nicht unbedingt. Man kann auch den Rest auf neue Blocks umkopieren.
Nicht unbedingt gleich, aber der Controller kann sich das merken.

Gerrit

[Sieghard Schicktanz]

Hallo Gerrit,

Du schriebst am Sat, 12 Nov 2022 18:24:19 +0100:

> >>> Hmmm. Was macht der Controller dann, wenn er wirklich alle
> >>> verfügbaren Blöcke mit Daren beschrieben hat, aber für keinen die
> >>> Erlaubnis zum Überschreiben?

...

> > Nicht unbedingt - wenn die geänderten Daten nur einen Teil der in

...

> Nicht unbedingt. Man kann auch den Rest auf neue Blocks umkopieren.
> Nicht unbedingt gleich, aber der Controller kann sich das merken.

Ja, solange noch neue Blöcke für die ganzen Reste da sind, geht das so.

[Gerrit Heitsch]

On 11/12/22 21:36, Sieghard Schicktanz wrote:
> Hallo Gerrit,
>
> Du schriebst am Sat, 12 Nov 2022 18:24:19 +0100:
>
>>>>> Hmmm. Was macht der Controller dann, wenn er wirklich alle
>>>>> verfügbaren Blöcke mit Daren beschrieben hat, aber für keinen die
>>>>> Erlaubnis zum Überschreiben?
> ...
>>> Nicht unbedingt - wenn die geänderten Daten nur einen Teil der in
> ...
>> Nicht unbedingt. Man kann auch den Rest auf neue Blocks umkopieren.
>> Nicht unbedingt gleich, aber der Controller kann sich das merken.
>
> Ja, solange noch neue Blöcke für die ganzen Reste da sind, geht das so.

Es werden ja immer wieder welche frei.

Gerrit

[Sieghard Schicktanz]

Hallo Gerrit,

Du schriebst am Sat, 12 Nov 2022 22:15:21 +0100:

> >>> Nicht unbedingt - wenn die geänderten Daten nur einen Teil der in
> > ...
> >> Nicht unbedingt. Man kann auch den Rest auf neue Blocks umkopieren.

...

> > Ja, solange noch neue Blöcke für die ganzen Reste da sind, geht das

...

> Es werden ja immer wieder welche frei.

Jaja, Du machst das schon. Da gibt's keine Grenzen.

[Gerrit Heitsch]

On 11/13/22 20:32, Sieghard Schicktanz wrote:
> Hallo Gerrit,
>
> Du schriebst am Sat, 12 Nov 2022 22:15:21 +0100:
>
>>>>> Nicht unbedingt - wenn die geänderten Daten nur einen Teil der in
>>> ...
>>>> Nicht unbedingt. Man kann auch den Rest auf neue Blocks umkopieren.
> ...
>>> Ja, solange noch neue Blöcke für die ganzen Reste da sind, geht das
> ...
>> Es werden ja immer wieder welche frei.
>
> Jaja, Du machst das schon. Da gibt's keine Grenzen.

Wenn du mir nicht glaubst, hier beschreibt Seagate den Prozess:

SSDs work very differently. The fundamental unit of NAND flash memory is
typically a 4 kilobyte (4KB) page, and there are usually 128 pages in a
block. Writes can happen one page at a time, but only on blank (or
erased) pages. Pages cannot be directly overwritten. Rather, they must
first be erased. However, erasing a page is complicated by the fact that
entire blocks of pages must be erased at one time. When the host wants
to rewrite to an address, the SSD actually writes to a different, blank
page and then updates the logical block address (LBA) table (much like
the MFT of an HDD). Inside the LBA table, the original page is marked as
“invalid” and the new page is marked as the current location for the new
data.

Of course, SSDs must erase these invalid pages of data at some point, or
the usable space on the SSD would eventually fill up. SSDs periodically
go through a process called garbage collection to clear out invalid
pages of data. During this process, the SSD controller, or flash
controller, that manages NAND flash memory in an SSD, reads all the good
pages of a block
(skipping the invalid pages) and writes them to a new erased block. Then
the original block is erased, thus preparing it for new data.

[...]

Some SSD manufacturers provide software tools to allow for
over-provisioning of drives by the user. Actually, even without special
software, any user can set aside a portion of the SSD when first setting
it up in the system by creating a partition that does not use the
drive’s full capacity. This unclaimed space will automatically be used
by the controller as dynamic over-provisioning.

Quelle:
https://www.seagate.com/de/de/tech-insights/ssd-over-provisioning-benefits-master-ti/



Gerrit

[Michael Schwingen]

On 2022-11-13, Sieghard Schicktanz <Sieghard....@SchS.de> wrote:
>> Es werden ja immer wieder welche frei.
>
> Jaja, Du machst das schon. Da gibt's keine Grenzen.

Wieso jetzt?

Prinzipiell reicht es, wenn die SSD genau einen leeren Block in Reserve hat
- dann kann sie die Daten dahin umkopieren und den vorigen, freigewordenen
Block löschen. Da gibt es erstmal kein Limit - das geht beliebig oft, bis
halt die Schreibzyklen eines Blockes aufgebraucht sind und der ausfällt.

Alles, was darüber hinausgeht, sind Optimierungen, die ändern aber am
Prinzip erstmal nichts.

cu
Michael

[Sieghard Schicktanz]

Hallo Michael,

Du schriebst am 14 Nov 2022 19:13:45 GMT:

> >> Es werden ja immer wieder welche frei.
> >
> > Jaja, Du machst das schon. Da gibt's keine Grenzen.
>
> Wieso jetzt?
>
> Prinzipiell reicht es, wenn die SSD genau einen leeren Block in
> Reserve hat
> - dann kann sie die Daten dahin umkopieren und den vorigen,
> freigewordenen Block löschen. Da gibt es erstmal kein Limit - das
> geht beliebig oft, bis halt die Schreibzyklen eines Blockes
> aufgebraucht sind und der ausfällt.

Kann sie, solange dieser leere Block nicht mit sovielen neuen Daten
gefüllt werden muß, daß der vorher benutzte Block noch einen Rest
"aufheben" muß. Dann ist _kein_ leerer Block mehr vorhanden.

[Sieghard Schicktanz]

Hallo Gerrit,

Du schriebst am Sun, 13 Nov 2022 22:30:49 +0100:

> Wenn du mir nicht glaubst, hier beschreibt Seagate den Prozess:

...

> Of course, SSDs must erase these invalid pages of data at some point,
> or the usable space on the SSD would eventually fill up. SSDs
> periodically go through a process called garbage collection to clear
> out invalid pages of data. During this process, the SSD controller,
> or flash controller, that manages NAND flash memory in an SSD, reads
> all the good pages of a block
> (skipping the invalid pages) and writes them to a new erased block.
> Then the original block is erased, thus preparing it for new data.
...

Eben. Und _ohne_ "garbage collection", was Deine Voraussetzung war
(soweit ich mich erinnere, ist schon so lange her...), kann es halt
immer einen Überlauf geben, der durch zunehmende Fragmentierung
verursacht wird.

(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.)

[Gerrit Heitsch]

On 11/14/22 22:44, Sieghard Schicktanz wrote:
> Hallo Gerrit,
>
> Du schriebst am Sun, 13 Nov 2022 22:30:49 +0100:
>
>> Wenn du mir nicht glaubst, hier beschreibt Seagate den Prozess:
> ...
>> Of course, SSDs must erase these invalid pages of data at some point,
>> or the usable space on the SSD would eventually fill up. SSDs
>> periodically go through a process called garbage collection to clear
>> out invalid pages of data. During this process, the SSD controller,
>> or flash controller, that manages NAND flash memory in an SSD, reads
>> all the good pages of a block
>> (skipping the invalid pages) and writes them to a new erased block.
>> Then the original block is erased, thus preparing it for new data.
> ...
> Eben. Und _ohne_ "garbage collection", was Deine Voraussetzung war
> (soweit ich mich erinnere, ist schon so lange her...), 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.

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

Gerrit

[Volker Bartheld]

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.

[Volker Bartheld]

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.

[Gerrit Heitsch]

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

[Bernd Laengerich]

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

[Gerrit Heitsch]

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

[Guido Grohmann]

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

[Gerrit Heitsch]

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

[Hanno Foest]

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

[Axel Berger]

Guido Grohmann wrote:
> 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.

Wahrscheinlich wissen das hier ohnehin alle, trotzdem:

Ich habe vor einiger Zeit drei Marken-USB-Stricks (Sandisk) gekauft und
zum Verteilen in der Familie zu drei Vierteln gefüllt. Wegen Covid fiel
das Familientreffen aus. Ein Jahr später habe ich sie testgelesen mit
einem Vergleich auf Dateiinhalte. Der Test ging bei allen drei sehr
schnell. Die Fehlerrate war überall derart hoch, daß ich rasch abbrechen
konnte. Ich habe sie also alle drei neu beschrieben und die Empfänger
darauf hingewisen, sie bald auszulesen und nicht nur in die Schublade zu
legen.


--
/¯\ No | Dipl.-Ing. F. Axel Berger Tel: +49/ 221/ 7771 8067
\ / HTML | Roald-Amundsen-Straße 2a Fax: +49/ 221/ 7771 8069
 X in | D-50829 Köln-Ossendorf http://berger-odenthal.de
/ \ Mail | -- No unannounced, large, binary attachments, please! --

[Volker Bartheld]

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$.d...@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

[Volker Bartheld]

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$.d...@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

[Hanno Foest]

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.

[Ole Jansen]

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.

[Michael Schwingen]

On 2022-11-14, Sieghard Schicktanz <Sieghard....@SchS.de> wrote:
>> - dann kann sie die Daten dahin umkopieren und den vorigen,
>> freigewordenen Block löschen. Da gibt es erstmal kein Limit - das
>> geht beliebig oft, bis halt die Schreibzyklen eines Blockes
>> aufgebraucht sind und der ausfällt.
>
> Kann sie, solange dieser leere Block nicht mit sovielen neuen Daten
> gefüllt werden muß, daß der vorher benutzte Block noch einen Rest
> "aufheben" muß. Dann ist _kein_ leerer Block mehr vorhanden.

Wie soll das gehen? Jeder Sektor, den Du schreibst, gibt einen Sektor im
alten Block frei, der nicht umkopiert werden muss. Wo sollen da auf einmal
in Summe mehr Daten herkommen?

cu
Michael

[Michael Schwingen]

On 2022-11-15, Volker Bartheld <news...@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

[Rupert Haselbeck]

Michael Schwingen schrieb:

Irgendwann ist auch eine SSD mal voll, ebenso wie eine konventionelle
Festplatte irgendwann voll ist. Nach dem Beschreiben des letzten freien
Blocks ist eben Schluß.
Aber das ist natürlich keine Besonderheit einer SSD...

MfG
Rupert

[Michael Schwingen]

On 2022-11-16, Rupert Haselbeck <mein-re...@gmx.de> wrote:
>> Wie soll das gehen? Jeder Sektor, den Du schreibst, gibt einen Sektor im
>> alten Block frei, der nicht umkopiert werden muss. Wo sollen da auf einmal
>> in Summe mehr Daten herkommen?
>
> Irgendwann ist auch eine SSD mal voll, ebenso wie eine konventionelle
> Festplatte irgendwann voll ist. Nach dem Beschreiben des letzten freien
> Blocks ist eben Schluß.

Nein. Eine SSD hat immer Reserveblöcke, ich hatte für die Erklärung genau
einen mehr als die nutzbare Kapazität angegeben - dann geht das immer auf.

Wegen Wearleveling hast Du mehr als einen, und die garbage collection
optimiert das natürlich so, daß möglichst hohe Performance dabei rauskommt,
aber das Szenario "durch Überschreiben sind keine leeren/löschbaren Blöcke
mehr da" kann bei korrekter Verwaltung nicht auftreten.

Firmwarebugs sind ein getrenntes Thema ...

cu
Michael

[Sieghard Schicktanz]

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

[Rolf Bombach]

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

[Hans-Peter Diettrich]

On 11/16/22 8:30 PM, Michael Schwingen wrote:

> Jeder Sektor, den Du schreibst, gibt einen Sektor im
> alten Block frei, der nicht umkopiert werden muss. Wo sollen da auf einmal
> in Summe mehr Daten herkommen?

Der Unterschied zwischen Block (Win: Cluster) und Sektor.
Solange der alte Block noch Daten enthält, ist er nicht frei. Im
schlimmten Fall ist noch 1 Sektor pro Block belegt und alle übrigen
wurden auch schon einmal geschrieben, dann ist kein Block mehr frei (zum
Löschen).

DoDi

[Sieghard Schicktanz]

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.

[Michael Schwingen]

Dann hat die Firmware vorher schon was falsch gemacht. Wenn nur noch 1 Block
frei ist, muss man halt umkopieren, und dadurch wird der alte Block wieder
frei. Einfach nur den neuen (letzten) Block mit Daten belegen geht nicht.

SSD-Blöcke sind nochmal was anderes als Cluster - das ist aber egal, die
Firmware muss dafür sorgen, daß immer mindestens einer frei ist, damit sie
alte Daten umkopieren kann.

cu
Michael