Discussion:
Externe SSDs als Archivmedien
(zu alt für eine Antwort)
Alfred Molon
2023-04-29 16:32:44 UTC
Permalink
Nach dem was hier steht:
https://www.anandtech.com/show/9248/the-truth-about-ssd-data-retention#:~:text=At%2040%C2%B0C%20active%20and%2030%C2%B0C%20power%20off%20temperature%2C,power%20off%20temperature%20will%20result%20in%20decreased%20retention.

https://www.partitionwizard.com/clone-disk/is-ssd-good-for-long-term-storage.html

https://superuser.com/questions/1742446/do-ssd-disks-actually-require-regular-power-lest-they-forget-their-data

liegt die Lebensdauer von Daten auf externen SSDs, je nach
Umgebungstemperatur, bei 1-2 Jahren.

D.h. wenn man SSDs bspw. 5 Jahre in der Schublade liegen lässt, sind die
Daten möglicherweise nicht mehr lesbar.

Wenn das stimmt, kommen externe SSDs als Archivmedien nicht in Frage.
--
Alfred Molon

Olympus 4/3 and micro 4/3 cameras forum at
https://groups.io/g/myolympus
https://myolympus.org/ photo sharing site
Shinji Ikari
2023-04-29 16:38:30 UTC
Permalink
Guten Tag
... wo ist die Neuigkeit fuer diese "News"group?
Post by Alfred Molon
Wenn das stimmt, kommen externe SSDs als Archivmedien nicht in Frage.
Waren sie auch nie. Und wenn das fuer Dich schon neu ist, musst Du
jetzt ganz stark werden: USB MemorySticks benutzen auch Flashspeicher
und nicht selten einer niedrigeren Qualitaetsklasse als sie bei SSD
verwendet werden.

Flashspeicher waren noch nie als Archivierungsmedium fuer eine grosse
Anzahl von Jahren gedacht oder geeignet.

Ab und zu dem Medium mal einige Zeit lang Strom geben, so dass ein
darin verbauter kontroller durch seine (hoffentlich ausreichend
geschickt programmierte ) Firmware sich der Sache annimmt, ist bei
Flashmedien keine schlechte Idee, wenn die Daten noch lesbar bleiben
sollen.
Marcel Mueller
2023-04-30 07:47:43 UTC
Permalink
Post by Shinji Ikari
Flashspeicher waren noch nie als Archivierungsmedium fuer eine grosse
Anzahl von Jahren gedacht oder geeignet.
Naja, ganz so pauschal stimmt das nicht. Das BIOS eines jeden Mainboards
oder einer Graka und diverser andere Teile liegt auch seit Jahrzehnten
ausschließlich in Flash-Speicher. Und die verlieren selten ihren Inhalt.
Flash-Alzheimer hatte ich bisher nur zweimal. Einmal bei einer Matrox
GraKa und einmal bei einem DLT-Laufwerk.

Aber bzgl. Flash-_Massenspeicher_, würde ich dir Recht geben. Da gibt es
in den üblichen Händlerregalen nicht, was für längere Zeiten gedacht ist.
Mir ist allerdings bisher auch bei älteren SSDs noch kein Datenverlust
untergekommen. Die älteste ist eine Postville G2. Ich habe allerdings es
auch nicht gezielt darauf angelegt.
Es ist allerdings anzunehmen, dass neuere Modelle diesbezüglich
kritischer sind, einfach weil die Technik jetzt viel weiter ausgereizt
ist. Genaueres wissen wir dann in 10 Jahren, wenn ausreichend
Erfahrungsberichte vorliegen.
Post by Shinji Ikari
Ab und zu dem Medium mal einige Zeit lang Strom geben, so dass ein
darin verbauter kontroller durch seine (hoffentlich ausreichend
geschickt programmierte ) Firmware sich der Sache annimmt, ist bei
Flashmedien keine schlechte Idee, wenn die Daten noch lesbar bleiben
sollen.
=> Scrubbing!

Einfach alle Blöcke einmal lesen. Dann muss der Controller Farbe
bekennen. Auf die ausreichend schlaue Firmware würde ich in der
Consumerklasse nicht hoffen.

Es gibt zwei Möglichkeiten, diese Prüfung durchzuführen.
Entweder man schmeißt einfach einen langen SMART-Test an,
oder man liest mit einem Programm alle Blöcke einmal. Sowas wie
dd if=/dev/sdX of=/dev/null bs=1M. Unter Windows macht glaube ich die
lange Dateisystemprüfung auch so etwas in der Art.


Eine Prüfung aller Dateiinhalte auf Prüfsummen ist für dieses Ziel
übrigens nicht erforderlich. Die Wahrscheinlichkeit, dass den
ECC-Prüfsummen ein Fehler durch die Lappen geht ist um Größenordnungen
geringer als das Auftreten von Fehlern. Und selbst wenn eine solche
Prüfung zuweilen Fehler zutage bringt, sind diese praktisch nie auf
Datenverluste auf Datenträgerebene zurückzuführen. Oft sind es
RAM-Fehler (manchmal auch in den Cache-RAMs der Laufwerke) oder
Softwarefehler. Kurzum, es wurden schon unbemerkt falsche Daten
geschrieben. Aus dem Grund wird für Server empfohlen, alle RAM-Ebenen
per ECC zu sichern.


Marcel
Alexander Goetzenstein
2023-04-30 08:30:36 UTC
Permalink
Hallo,
Post by Marcel Mueller
Es gibt zwei Möglichkeiten, diese Prüfung durchzuführen.
Entweder man schmeißt einfach einen langen SMART-Test an,
oder man liest mit einem Programm alle Blöcke einmal. Sowas wie
dd if=/dev/sdX of=/dev/null bs=1M.
das alleine hilft wohl nicht unbedingt: ich habe hier zwei Rechner,
ausgestattet mit SSDs, die nur alle paar Monate mal angeworfen werden.
Bei denen habe ich jedesmal genau obiges als Script zu laufen, und
mittlerweile werfen beide Platten dabei eine Menge Fehler aus. Die
Fehler werden auch bei Wiederholung nicht weniger. Vermutlich müsste ich
die Platten komplett überschreiben oder sowas in der Art, damit die
defekten Zellen ausgemustert werden. Bislang scheue ich den Aufwand noch.
--
Gruß
Alex
Marcel Mueller
2023-04-30 17:45:46 UTC
Permalink
Post by Alexander Goetzenstein
Post by Marcel Mueller
Es gibt zwei Möglichkeiten, diese Prüfung durchzuführen.
Entweder man schmeißt einfach einen langen SMART-Test an,
oder man liest mit einem Programm alle Blöcke einmal. Sowas wie
dd if=/dev/sdX of=/dev/null bs=1M.
das alleine hilft wohl nicht unbedingt: ich habe hier zwei Rechner,
ausgestattet mit SSDs, die nur alle paar Monate mal angeworfen werden.
Bei denen habe ich jedesmal genau obiges als Script zu laufen, und
mittlerweile werfen beide Platten dabei eine Menge Fehler aus.
Man kann eine Firmware natürlich auch so blöd programmieren, dass man
korrigierbare Fehler so lange ignoriert, bis sie nicht mehr korrigierbar
sind. In dem Fall hast du keine Chance. Da steht nicht zufällig Intenso
drauf?
Post by Alexander Goetzenstein
Die
Fehler werden auch bei Wiederholung nicht weniger.
Natürlich nicht. Die SSD kann sich die verlorenen Daten ja nicht aus den
Fingern saugen.
Post by Alexander Goetzenstein
Vermutlich müsste ich
die Platten komplett überschreiben oder sowas in der Art, damit die
defekten Zellen ausgemustert werden.
Korrekt. Und da ist nichts defekt. Das ist einfach der normale
Ladungsabfluss durch Tunneleffekt. Dadurch zerfallen die Informationen
mit der Zeit. Am Anfang packt das die Fehlerkorrektur noch, später nicht
mehr.
Post by Alexander Goetzenstein
Bislang scheue ich den Aufwand noch.
Es würde auch genügen, die defekten Dateien zu löschen. Durch das
nachfolgende Trim-Kommando wird der SSD mitgeteilt, dass die Daten nicht
mehr benötigt werden. Damit ist der Fehler weg. Die Daten sind ohnehin
schon tot.


Marcel
Alexander Goetzenstein
2023-05-04 11:46:17 UTC
Permalink
Hallo,
Post by Marcel Mueller
Post by Alexander Goetzenstein
Die
Fehler werden auch bei Wiederholung nicht weniger.
Natürlich nicht. Die SSD kann sich die verlorenen Daten ja nicht aus den
Fingern saugen.
das nicht, aber die betroffenen Zellen könnten als defekt markiert und
übersprungen werden. Dachte ich. Bislang zeigen sich keine weiteren
Folgen im Betrieb, vielleicht sind die Zellen auch gar nicht mit Daten
gefüllt.
Post by Marcel Mueller
Man kann eine Firmware natürlich auch so blöd programmieren, dass man
korrigierbare Fehler so lange ignoriert, bis sie nicht mehr korrigierbar
sind. In dem Fall hast du keine Chance. Da steht nicht zufällig Intenso
drauf?
in /dev/disk/by-id/ ist sie als FORESEE aufgeführt.
Post by Marcel Mueller
Post by Alexander Goetzenstein
Vermutlich müsste ich
die Platten komplett überschreiben oder sowas in der Art, damit die
defekten Zellen ausgemustert werden.
<seufz> Ich hab's befürchtet. Sie beherbergt nichts weiter als das
Betriebssystem und etwas Konfig, daher gibt es kein Backup. Das bedeutet
Arbeit...
Post by Marcel Mueller
Es würde auch genügen, die defekten Dateien zu löschen. Durch das
nachfolgende Trim-Kommando wird der SSD mitgeteilt, dass die Daten nicht
mehr benötigt werden. Damit ist der Fehler weg. Die Daten sind ohnehin
schon tot.
Wenn ich wüsste, was da zu löschen wäre...
--
Gruß
Alex
Shinji Ikari
2023-05-04 12:10:22 UTC
Permalink
Guten Tag
Post by Alexander Goetzenstein
Post by Marcel Mueller
Post by Alexander Goetzenstein
Die
Fehler werden auch bei Wiederholung nicht weniger.
Natürlich nicht. Die SSD kann sich die verlorenen Daten ja nicht aus den
Fingern saugen.
das nicht, aber die betroffenen Zellen könnten als defekt markiert und
übersprungen werden. Dachte ich.
Vielleicht habe ich hier den faden verloren. geht es nicht mehr um
Flashspeicherzellen, die nur ihren Inhalt im Laufe extrem langer
Unbenutzung vergessen haben?
Wenn die Zellen den Inhalt (hier ging es doch um Archivierung?)
vergessen haben sind sie noch nicht defekt.
Di eRegelanwendung von SSD mit Flashzellen ist eben, dass sie
gelegentlich unter Strom gehalten werden, so dass der Kontroller das
regelmaessig pruefen und bei guet Firmware auch gegensteuern kann.
In die Ecke gelegt ohne Strom verlieren Flashzellen in der Relen ab
und zu ein paar Elektronen.
Post by Alexander Goetzenstein
Post by Marcel Mueller
Post by Alexander Goetzenstein
Vermutlich müsste ich
die Platten komplett überschreiben oder sowas in der Art, damit die
defekten Zellen ausgemustert werden.
Wenn es wirklich defekte Zellen sind: ja, die werden durch
Lesen/Beschreiben gefunden und gekennzeichnet.
Post by Alexander Goetzenstein
Post by Marcel Mueller
Es würde auch genügen, die defekten Dateien zu löschen. Durch das
nachfolgende Trim-Kommando wird der SSD mitgeteilt, dass die Daten nicht
mehr benötigt werden. Damit ist der Fehler weg. Die Daten sind ohnehin
schon tot.
Wenn ich wüsste, was da zu löschen wäre...
Unter Windows hatte die CT vor kurzem das alte Tool Diskrefresh (oder
so) mal wieder erwaehnt. Damit kann man Datentraeger dazu anweisen den
Inhalt einzulesen und neu zu schgreiben. dauert etwas aber kann auch
helfen 'eingeschlafene' SSDs wieder auf die Beine zu helfen.
Alexander Goetzenstein
2023-05-05 11:56:28 UTC
Permalink
Hallo,
Post by Shinji Ikari
Vielleicht habe ich hier den faden verloren. geht es nicht mehr um
Flashspeicherzellen, die nur ihren Inhalt im Laufe extrem langer
Unbenutzung vergessen haben?
Dochdoch, das ist wohl das Problem.
Post by Shinji Ikari
Wenn die Zellen den Inhalt (hier ging es doch um Archivierung?)
vergessen haben sind sie noch nicht defekt.
Achso. Ich dachte, der Controller merkt das und blendet sie aus.
Post by Shinji Ikari
Di eRegelanwendung von SSD mit Flashzellen ist eben, dass sie
gelegentlich unter Strom gehalten werden, so dass der Kontroller das
regelmaessig pruefen und bei guet Firmware auch gegensteuern kann.
In die Ecke gelegt ohne Strom verlieren Flashzellen in der Relen ab
und zu ein paar Elektronen.
Das wird es wohl sein. Diese Rechner hier werden nur alle Vierteljahre
gebraucht, für die Steuer, sonst nicht. Das scheint wohl schon zu lange
zu sein.
Post by Shinji Ikari
Unter Windows hatte die CT vor kurzem das alte Tool Diskrefresh (oder
so) mal wieder erwaehnt. Damit kann man Datentraeger dazu anweisen den
Inhalt einzulesen und neu zu schgreiben. dauert etwas aber kann auch
helfen 'eingeschlafene' SSDs wieder auf die Beine zu helfen.
Das wird unter Linux wohl nicht laufen. und ein

dd if=/dev/sda of=/dev/sda

wird wohl auch nicht funktionieren. Gibt es dafür auch eine Lösung?
--
Gruß
Alex
Shinji Ikari
2023-05-05 13:16:24 UTC
Permalink
Guten Tag
Post by Alexander Goetzenstein
Post by Shinji Ikari
Vielleicht habe ich hier den faden verloren. geht es nicht mehr um
Flashspeicherzellen, die nur ihren Inhalt im Laufe extrem langer
Unbenutzung vergessen haben?
Dochdoch, das ist wohl das Problem.
Post by Shinji Ikari
Wenn die Zellen den Inhalt (hier ging es doch um Archivierung?)
vergessen haben sind sie noch nicht defekt.
Achso. Ich dachte, der Controller merkt das und blendet sie aus.
bei stromloser Archivierung/lagerung des Flashspeichers?
Kann er gar nicht. Ohne Energie merkt er nicht, wenn etwa flutsch ist.
Wenn er spaeter dann in einem betrieb merkt ist es ggf. zu spaet. Dann
kann er zwar feststellen, dass Daten verloren sind, aber die jeweils
betreffende Zelle ist ja dennoch nicht defekt, nur weil man sie nicht
innerhalb der Specs gehalten hat.
Die Dasten sind nur weg, weil man das Ding eben zu lange stromlos hat
liegen lassen.

Stell es Dir wie Eis im Eisfach (in unseren Breitengraden) vor.
Wenn der Strom weg ist, schmilzt es nach einiger Zeit, wenn die
Umgebungsbedingungen eben nicht "eisfreundlich" sind.
Dennoch ist die Kuehltruhe/Eisfach nicht zwingend defekt. Strom dran,
neues Eis rein und schon ist wieder alles so, wie gewollt.
Post by Alexander Goetzenstein
Post by Shinji Ikari
Unter Windows hatte die CT vor kurzem das alte Tool Diskrefresh (oder
so) mal wieder erwaehnt. Damit kann man Datentraeger dazu anweisen den
Inhalt einzulesen und neu zu schgreiben. dauert etwas aber kann auch
helfen 'eingeschlafene' SSDs wieder auf die Beine zu helfen.
Das wird unter Linux wohl nicht laufen. und ein
dd if=/dev/sda of=/dev/sda
wird wohl auch nicht funktionieren. Gibt es dafür auch eine Lösung?
Manuell angestossenes Umkopieren.
Alfred Molon
2023-05-05 16:11:47 UTC
Permalink
Die Daten sind nur weg, weil man das Ding eben zu lange stromlos hat
liegen lassen.
D.h. wenn man einen PC mit SSD bspw. ein Jahr lang nicht mehr benutzt
hat, ist möglicherweise alles weg?
--
Alfred Molon

Olympus 4/3 and micro 4/3 cameras forum at
https://groups.io/g/myolympus
https://myolympus.org/ photo sharing site
Shinji Ikari
2023-05-05 21:09:25 UTC
Permalink
Guten Tag
Post by Alfred Molon
Die Daten sind nur weg, weil man das Ding eben zu lange stromlos hat
liegen lassen.
D.h. wenn man einen PC mit SSD bspw. ein Jahr lang nicht mehr benutzt
hat, ist möglicherweise alles weg?
Die Zeit haengt von Qualitaet, Kapazitaet und Bauart des
Flashspeichers ab, aber irgendwann ist alles weg.

Nach einem Jahr sind aber eigentlich eher einige Elektronen weg.

Wieviele Elektronen pro Bit vorhanden sein muessen um beispielsweise
als diese oder jenes Bit (oder bei QLC jenes oder jenes oder jenes....
Bit) noch korrekt erkannt und ausgelesen sein koennen haengt leider
von vielen Faktoren an.
Dass einzelne Bits von den viiiiielen Gigabits dann schon falsch sein
koennen ist wahrscheinlich.
Wenn aber noch nicht genug Bits an den unguenstigten Stellen sich
veraendert haben merkt man davon noch gar nichts, weil die eingebaute
Fehlerkorrektur schon beim Auslesen greift und on the fly korrigiert.

Irgendwann sind aber zuviele Elektronen an den unguenstigsten Stellen
verloren gegangen.

Stark vereinfacht zur Erklarung (Flashstechnik in SSDs ist erheblich
komplizierter):
Bei einfachstem Flashspeicher entspricht ein Bit einer Flashzelle.
Sagen wir mal eine voll geladene Flashzelle kann genug Elektronen
halten um beim Auslesen 4V zu haben.
Also definiert man: wenn die Zelle mehr als 2V hat ist das Bit darin
logisch "1". Wenn die Zelle weniger als 2V hat ist das Bit darin
logisch "0".
(Um eine eindeutigere Unterscheidung zwischen "0" und "1" zu
ermoeglichen hat man in der Realitaet zwischen den definierten Grenzen
etwas Abstand gelassen.)

Eine solche Zelle kann also raeumlich viel Platz haben und darin viele
Elektronen lagern. Vereinzelt abgewanderte Elektronen stoeren da
nicht, weil schon sehr viele abfliesen muesen um von einer logischen
"1" zu einer "0" zu werden. Die laesst sich auch ueber Jahre noch gut
auslesen (vor allem, weil noch weitere Zellen fuer Fehlerkorrekturbits
vorhanden sind).

Da Speicherplatz aber teuer ist und alles in Summe wieder billiger und
kleiner werden soll hat man eben irgendwann weitergeforscht und
festgelegt diese Zelle kann auch mehr als 1 Bit lagern.
Also hat man 2Bit pro Zelle unter gebracht. Somit kann die Flashzelle
beim Auslesen also den Zugstand logisch "00" oder "01" oder "10" oder
"11" haben. Wenn man das auf die 4V aufteilt koennte man sagen:
Alles ueber 3V = "11"
Alles ueber 2V und unter 3V = "10"
Alles ueber 1V und unter 2V = "01"
Alles unter 1V = "00"
(und auch hier wird zwischen den Grenzen in der Realitaet
Sicherheitsabstand noch eingeplant).
Schon hat man nur noch (weniger als) 1/4 der ursprueglichen Elektronen
pro Flashzelle um den Zustand der 2 Bits in der einen Zelle korrekt zu
erkennen

Und dann hat man irgendwann gedacht, das kann man auch mit 3 Bits pro
Zelle machen: also hat man 000 001 010 011 100 101 110
111.
Schon muss man die urspruenglichen angenommenen 4V in 8 Zustaende
zerteilen (und dann noch etwas Sicherheitsabstand dazwischen).
Bei gleicher Flashzellengroesse hat man also nun nur noch weniger als
1/8 der urspruenglichen Elektronen pro Bit...

Und dann wurden es QLC Speicher = 4 Bits pro Zelle...

Du siehst, selbst wenn man die weitere Miniaturisierung und Umbau auf
Stapelspeicher und schwankende Fertigungsqualitaeten, mal aussen vor
laesst sind immer weniger Elektronen in der Zelle um den Bitzustand
der enthaltenen Bits noch erkennen zu koennen.
Wenn davon dann einge Elektronen im Laufe der Zeit abwandern
(Flashzellen werden bei jedem Schreibvorgang 'angekratzt' und werden
dadurch immer 'undichter') wird es immer schwieriger die urspruenglich
eingeschriebene und notwendige Spannung auch wieder auszulesen und
somit die Bits korrekt festzustellen.

Und irgendwann wird eine eingeschriebene "1111" auf einmal nur noch
als "1110" erkannt, weil der Unterschied von einigen Millivolt eben
nicht mehr aufrecht gehalten werden konnte.

Wie gesagt: extrem vereinfacht und schematisiert.
Alexander Goetzenstein
2023-05-06 08:30:43 UTC
Permalink
Hallo,
Post by Shinji Ikari
Guten Tag
Post by Alexander Goetzenstein
Post by Shinji Ikari
Vielleicht habe ich hier den faden verloren. geht es nicht mehr um
Flashspeicherzellen, die nur ihren Inhalt im Laufe extrem langer
Unbenutzung vergessen haben?
Dochdoch, das ist wohl das Problem.
Post by Shinji Ikari
Wenn die Zellen den Inhalt (hier ging es doch um Archivierung?)
vergessen haben sind sie noch nicht defekt.
Achso. Ich dachte, der Controller merkt das und blendet sie aus.
bei stromloser Archivierung/lagerung des Flashspeichers?
nicht doch: in dem Moment, wo er den Fehler auswirft, hat er ihn wohl
bemerkt und könnte ihn entsprechend behandeln. Dann sollte er beim
nächsten Lauf nicht mehr auftreten, wenn die betreffende Zelle
übersprungen wird. Das war so mein Gedanke.
Post by Shinji Ikari
Post by Alexander Goetzenstein
Post by Shinji Ikari
Unter Windows hatte die CT vor kurzem das alte Tool Diskrefresh (oder
so) mal wieder erwaehnt. Damit kann man Datentraeger dazu anweisen den
Inhalt einzulesen und neu zu schgreiben. dauert etwas aber kann auch
helfen 'eingeschlafene' SSDs wieder auf die Beine zu helfen.
Das wird unter Linux wohl nicht laufen. und ein
dd if=/dev/sda of=/dev/sda
wird wohl auch nicht funktionieren. Gibt es dafür auch eine Lösung?
Manuell angestossenes Umkopieren.
Könnte also ein

dd if=/dev/sda of=/dev/sdb
dd if=/dev/sdb of=/dev/sda

helfen, oder wäre zu erwarten, dass der Fehler mitwandert?
--
Gruß
Alex
Ulli Horlacher
2023-05-06 09:10:02 UTC
Permalink
Post by Alexander Goetzenstein
Könnte also ein
dd if=/dev/sda of=/dev/sdb
dd if=/dev/sdb of=/dev/sda
helfen, oder wäre zu erwarten, dass der Fehler mitwandert?
Wenn beim Lesen bereits ein Fehler (falsches byte) auftritt, kopierst du
den natuerlich mit.
Schreiben auf ein raw device ist unsinnig. Wenn, dann mach:

dd status=progress bs=1M if=/dev/sda of=/wo/es/genug/platz/gibt/sda.dd
dd status=progress bs=1M if=/wo/es/genug/platz/gibt/sda.dd of=/dev/sda

Ob das ueberhaupt technisch Sinn macht kann dir nur der SSD Hersteller
sagen.
--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: ***@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: https://www.tik.uni-stuttgart.de/
Marcel Mueller
2023-05-06 10:14:58 UTC
Permalink
Post by Alexander Goetzenstein
Post by Shinji Ikari
Post by Alexander Goetzenstein
dd if=/dev/sda of=/dev/sda
wird wohl auch nicht funktionieren. Gibt es dafür auch eine Lösung?
Das würde auch schon gehen. Natürlich darf das Dateisystem dabei nicht
in Benutzung sein, dann dann ist der Inhalt ja zeitlich nicht konstant.

Schlimmer ist allerdings, dass das reines SSD-Aging ist, und den Fehler
ggf. erst herbeiführt. Die Lebenserwartung der Daten sinkt nämlich mit
jedem zusätzlichen Schreibvorgang. Sprich, abgenutzte SSDs halten die
Daten kürzer.
Post by Alexander Goetzenstein
Post by Shinji Ikari
Manuell angestossenes Umkopieren.
Könnte also ein
dd if=/dev/sda of=/dev/sdb
dd if=/dev/sdb of=/dev/sda
helfen, oder wäre zu erwarten, dass der Fehler mitwandert?
Wenn es bereits einen nicht korrigierbaren Fehler (= Datenverlust) gibt,
bricht jedes dieser Kommandos unverrichteter Dinge ab.
Andernfalls gibt es keinen Fehler, der wandern könnte.

Aber aus obigem Grund kann aber nur die Firmware entscheiden, wann es
die richtige Zeit für einen Refresh ist. Und nur diese kann auch
nachprogrammieren. Für den Refresh ist nämlich _kein_ vorheriger
Löschvorgang erforderlich, da ja dieselbe Information wieder rein
geschrieben wird. Und nur die Löschvorgänge degradieren die Lebensdauer
der Flash-Zellen. Das Schreiben der Daten ist gar nicht so schlimm.

Kurzum, man kann nur auf die Firmware vertrauen. Eine andere, sinnvolle
Möglichkeit hat man nicht. Falls die SSD häufig stromlos ist, kann man
die Sache durch einen gelegentlichen, langen SMART-Selbsttest
unterstützen. Der gibt der Firmware auch die Gelegenheit, angeschlagene
Zellen zu refreshen. Ob sie das tut, weiß nur der Hersteller.

Naja, und last but not least: Daten, von denen es kein Backup gibt,
brauch man sowieso nicht. Die könnte man auch gleich löschen, dann gibt
es auch keine bösen Überraschungen. ;-)


Marcel
Shinji Ikari
2023-05-06 13:19:11 UTC
Permalink
Guten Tag
Post by Alexander Goetzenstein
Post by Shinji Ikari
Post by Alexander Goetzenstein
Post by Shinji Ikari
Vielleicht habe ich hier den faden verloren. geht es nicht mehr um
Flashspeicherzellen, die nur ihren Inhalt im Laufe extrem langer
Unbenutzung vergessen haben?
Dochdoch, das ist wohl das Problem.
Post by Shinji Ikari
Wenn die Zellen den Inhalt (hier ging es doch um Archivierung?)
vergessen haben sind sie noch nicht defekt.
Achso. Ich dachte, der Controller merkt das und blendet sie aus.
bei stromloser Archivierung/lagerung des Flashspeichers?
nicht doch: in dem Moment, wo er den Fehler auswirft, hat er ihn wohl
bemerkt und könnte ihn entsprechend behandeln.
Wir haben in dem Falle der stromlosen Archivierung ueber lange Zeit:
Eine vollkommen intakte Speicherzelle, die aufgrund jahrelangem
stromlosen liegenlassen im Schrank Elektronen aus der Zelle verloren
hat und beim Auslesen dann nicht mehr den urspreunglichen
Spannungslevel = Bitkombination melden kann.
(und es gibt davon sogar mehrere/viele Zellen, weil SSDs eben nicht
fuer stromloses liegenlassen gedacht sind.)

Wie soll der Kontroller die behandeln?
Vorausgesetzt er erkennt wegen der Checksummenpruefung, dass da eine
Zelle falsche Daten hat. Wenn er die ausvblendet und als unbenutzbar
markiert ist die SSD ruckzuck nur noch einen Bruchteil so gross, wie
sie eigentlich sein sollte (vor allem, wenn mehr Zellen zu viele
Elektronen verloren haben, als die SSD fuer Overprovisioning
zurueckgehalten hat).
Und das ganze nur, weil die komplett intakte und problemlos arbeitende
Zelle eben wegen falscher Behandlung falsche Daten meldete und somit
als defekt gebrandmarkt wurde.
Post by Alexander Goetzenstein
Dann sollte er beim
nächsten Lauf nicht mehr auftreten, wenn die betreffende Zelle
übersprungen wird. Das war so mein Gedanke.
Welcher naechste Lauf? Wieder mit Daten beschreiben, wieder Jahre
stromlos in die Ecke legen udn wieder beim auslesen feststellen,d ass
Daten nicht mehr rekonstruiert werden koennen?
Waer eausdrucken auf Papier und direkt danach in den Schredder stecken
nicht sinnvoller?
SSD sind keine Speicher die fuer langfristige Archivierung vorgesehen
sind. Wenn man das beachtet udn die vielleicht regelmaessig alle 1/4
oder 1/2 Jahr ein paar Stunden im PC am Strom nuckeln laesst, sollten
gute Firmware/Kontrollerkombinationen das selbststaendig handhaben.
bei unguenstigen Kontroller/Firmwarekombinationen vielleicht einfach
mal alle Daten einmal einlesen und ggf. neu schreiben.

Das geht bei SSDs ja in ertraeglicher Zeit.
Post by Alexander Goetzenstein
Post by Shinji Ikari
Post by Alexander Goetzenstein
Post by Shinji Ikari
Unter Windows hatte die CT vor kurzem das alte Tool Diskrefresh (oder
so) mal wieder erwaehnt. Damit kann man Datentraeger dazu anweisen den
Inhalt einzulesen und neu zu schgreiben. dauert etwas aber kann auch
helfen 'eingeschlafene' SSDs wieder auf die Beine zu helfen.
Das wird unter Linux wohl nicht laufen. und ein
dd if=/dev/sda of=/dev/sda
wird wohl auch nicht funktionieren. Gibt es dafür auch eine Lösung?
Manuell angestossenes Umkopieren.
Könnte also ein
dd if=/dev/sda of=/dev/sdb
dd if=/dev/sdb of=/dev/sda
helfen, oder wäre zu erwarten, dass der Fehler mitwandert?
Ich kann zu Linux Befehlen nichts sagen, da ich da noch zu frisch und
noch nicht weit genug eingestiegen bin.
Alexander Goetzenstein
2023-05-06 19:58:59 UTC
Permalink
Hallo,
Post by Shinji Ikari
SSD sind keine Speicher die fuer langfristige Archivierung vorgesehen
sind. Wenn man das beachtet udn die vielleicht regelmaessig alle 1/4
oder 1/2 Jahr ein paar Stunden im PC am Strom nuckeln laesst, sollten
gute Firmware/Kontrollerkombinationen das selbststaendig handhaben.
es sind ja regelmäßig knapp 3 Monate Nichtbenutzung, kein jahrelanges
Liegenlassen. Reicht offenbar auch schon. Das hatte ich nicht erwartet.
--
Gruß
Alex
Shinji Ikari
2023-05-06 20:20:28 UTC
Permalink
Guten Tag
Post by Alexander Goetzenstein
Post by Shinji Ikari
SSD sind keine Speicher die fuer langfristige Archivierung vorgesehen
sind.
es sind ja regelmäßig knapp 3 Monate Nichtbenutzung, kein jahrelanges
Liegenlassen. Reicht offenbar auch schon. Das hatte ich nicht erwartet.
Just for the Records: Welche Marke/Modell/Version war es denn?
Alexander Goetzenstein
2023-05-08 06:25:02 UTC
Permalink
Hallo,
Post by Shinji Ikari
Just for the Records: Welche Marke/Modell/Version war es denn?
die SSD meldet sich als FORESEE. Im Netz finde ich kaum etwas darüber.
--
Gruß
Alex
Shinji Ikari
2023-05-08 07:39:35 UTC
Permalink
Guten Tag
Post by Alexander Goetzenstein
Post by Shinji Ikari
Just for the Records: Welche Marke/Modell/Version war es denn?
die SSD meldet sich als FORESEE. Im Netz finde ich kaum etwas darüber.
Hm.. ich vermute, daß es dann ein Modell ist, welches wohl eher
weniger zu einem Markenhersteller gehoert,
Ich kenne dieses Modell/marke auch nicht.
Vielleicht ist es sogar eines der Modelle, welche von Anfang an nicht
korrekt designt wurde (gefaelschte/Kapazitaetsfalsche USB Sticks sind
ja schin bekannt. bei SSD scheint sowas auch schon um sich zu
greifen).
Hattest Du die SSD Anfangs mal komplett durchgetestet?
Alexander Goetzenstein
2023-05-08 12:52:51 UTC
Permalink
Hallo,
Post by Shinji Ikari
Guten Tag
Post by Alexander Goetzenstein
Post by Shinji Ikari
Just for the Records: Welche Marke/Modell/Version war es denn?
die SSD meldet sich als FORESEE. Im Netz finde ich kaum etwas darüber.
Hm.. ich vermute, daß es dann ein Modell ist, welches wohl eher
weniger zu einem Markenhersteller gehoert,
Ich kenne dieses Modell/marke auch nicht.
Vielleicht ist es sogar eines der Modelle, welche von Anfang an nicht
korrekt designt wurde (gefaelschte/Kapazitaetsfalsche USB Sticks sind
ja schin bekannt. bei SSD scheint sowas auch schon um sich zu
greifen).
Hattest Du die SSD Anfangs mal komplett durchgetestet?
wenn Du meinst, ob ich einen dd-Lauf durchgeführt habe: ja habe ich,
ohne Auffälligkeiten. Ist aber schon länger her, ganz zu Anfang. Bei
einer Nennkapazität von 128GB braucht man auch nicht viel zu fälschen...
--
Gruß
Alex
Shinji Ikari
2023-05-08 16:10:27 UTC
Permalink
Guten Tag
Post by Alexander Goetzenstein
Post by Shinji Ikari
Hattest Du die SSD Anfangs mal komplett durchgetestet?
wenn Du meinst, ob ich einen dd-Lauf durchgeführt habe: ja habe ich,
Ich kann mit Linuxbefehlen nichts anfangen. EInmal komplett voll
schreiben und dann einmal komplett lesen und pruefen ob die SSD auch
wirklich die korrekte Kapazitaet und nicht irgendweche
offensichtlichen Lese- oder Schreibfehler zeigt.
Alexander Goetzenstein
2023-05-09 09:18:47 UTC
Permalink
Hallo,
Post by Shinji Ikari
Guten Tag
Post by Alexander Goetzenstein
Post by Shinji Ikari
Hattest Du die SSD Anfangs mal komplett durchgetestet?
wenn Du meinst, ob ich einen dd-Lauf durchgeführt habe: ja habe ich,
Ich kann mit Linuxbefehlen nichts anfangen. EInmal komplett voll
schreiben und dann einmal komplett lesen und pruefen ob die SSD auch
wirklich die korrekte Kapazitaet und nicht irgendweche
offensichtlichen Lese- oder Schreibfehler zeigt.
ja, das tut der dd-Befehl (dd steht für Disk Dump), indem er den Inhalt
einer Disk bitweise liest bzw. schreibt. Anfangs war also alles in Ordnung.
--
Gruß
Alex
Shinji Ikari
2023-05-09 13:01:10 UTC
Permalink
Guten Tag
Post by Alexander Goetzenstein
Post by Shinji Ikari
Post by Alexander Goetzenstein
wenn Du meinst, ob ich einen dd-Lauf durchgeführt habe: ja habe ich,
Ich kann mit Linuxbefehlen nichts anfangen. EInmal komplett voll
schreiben und dann einmal komplett lesen und pruefen ob die SSD auch
wirklich die korrekte Kapazitaet und nicht irgendweche
offensichtlichen Lese- oder Schreibfehler zeigt.
ja, das tut der dd-Befehl (dd steht für Disk Dump), indem er den Inhalt
einer Disk bitweise liest bzw. schreibt. Anfangs war also alles in Ordnung.
Du hattest erwaehnt:
dd if=/dev/sda of=/dev/sda

Wie gesagt ist Linux nicht meine Welt, aber das klingt mir, als wenn
er die Bits nimmt und direkt wieder schreibt (also nicht einmal das
medium beschreibt und dann spaeter einmal komplett liest).
So kann man die Flashzellen nur 'begrenzt' testen, weil da ggf. ein
vorhandener Cache zwischen greift.
Wenn man einmal da Medium voll schreibt und keien Fehler erkannt
werden (wenn das Programm Fehler ueberhaupt meldet) weiss man, daß die
Schrfeibbefehle abgesetzt wurden.
Danach einmal das ganze Medium lesen.
Ich nutze gerne HDtunePro (Windows)

Und wenn man es ganz sicher machen will schreibt man vorher
wiedererkennbare aber nicht identisceh Daten und prüft später ob die
Daten sogar korrekt gelesen weredn können und nicht der Kontroller da
etwas vorgaukelt.
Heise hat da h2testw entwickelt (Windows).
Alexander Schreiber
2023-05-28 20:17:59 UTC
Permalink
Post by Alexander Goetzenstein
Hallo,
Post by Shinji Ikari
Guten Tag
Post by Alexander Goetzenstein
Post by Shinji Ikari
Hattest Du die SSD Anfangs mal komplett durchgetestet?
wenn Du meinst, ob ich einen dd-Lauf durchgeführt habe: ja habe ich,
Ich kann mit Linuxbefehlen nichts anfangen. EInmal komplett voll
schreiben und dann einmal komplett lesen und pruefen ob die SSD auch
wirklich die korrekte Kapazitaet und nicht irgendweche
offensichtlichen Lese- oder Schreibfehler zeigt.
ja, das tut der dd-Befehl (dd steht für Disk Dump),
Alternativ auch für: Data Destroyer. Warum, bleibt der Vorstellung des
geneigten Lesers überlassen. ;-)

SCNR,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison
Ulli Horlacher
2023-05-28 21:49:49 UTC
Permalink
Post by Alexander Goetzenstein
ja, das tut der dd-Befehl (dd steht für Disk Dump)
Nein, "data definition".
Dessen Syntax ist auch voellig kontraer zu allen anderen UNIX Kommandos,
weil dd von OS/370 JCL abstammt.
Post by Alexander Goetzenstein
indem er den Inhalt einer Disk bitweise liest bzw. schreibt.
Nein, blockweise. Bitweise kann man keinen Datentraeger lesen.
--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: ***@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: https://www.tik.uni-stuttgart.de/
Alexander Goetzenstein
2023-05-29 12:14:26 UTC
Permalink
Hallo,
Post by Ulli Horlacher
Post by Alexander Goetzenstein
ja, das tut der dd-Befehl (dd steht für Disk Dump)
Nein, "data definition".
Dessen Syntax ist auch voellig kontraer zu allen anderen UNIX Kommandos,
weil dd von OS/370 JCL abstammt.
Post by Alexander Goetzenstein
indem er den Inhalt einer Disk bitweise liest bzw. schreibt.
Nein, blockweise. Bitweise kann man keinen Datentraeger lesen.
mal so rein aus akademischer Neugier ohne praktischen Wert: könnte man
die blocksize auch auf 1 Byte (1 Bit geht wohl nicht) setzen und damit
auch byteweise lesen/schreiben?
--
Gruß
Alex
Ulli Horlacher
2023-05-29 12:18:45 UTC
Permalink
Post by Alexander Goetzenstein
Hallo,
Post by Ulli Horlacher
Post by Alexander Goetzenstein
ja, das tut der dd-Befehl (dd steht für Disk Dump)
Nein, "data definition".
Dessen Syntax ist auch voellig kontraer zu allen anderen UNIX Kommandos,
weil dd von OS/370 JCL abstammt.
Post by Alexander Goetzenstein
indem er den Inhalt einer Disk bitweise liest bzw. schreibt.
Nein, blockweise. Bitweise kann man keinen Datentraeger lesen.
mal so rein aus akademischer Neugier ohne praktischen Wert: könnte man
die blocksize auch auf 1 Byte (1 Bit geht wohl nicht) setzen und damit
auch byteweise lesen/schreiben?
Ich kenne keinen Datentraeger, der byteweise lesen erlaubt. Das kleinste
sind 512 Byte Bloecke. Oft aber ein vielfaches davon.
Du kannst zwar dd anweisen byteweise zu lesen, aber das liest nicht direkt
vom Datentraeger sondern vom page cache.
--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: ***@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: https://www.tik.uni-stuttgart.de/
Alexander Goetzenstein
2023-05-29 12:24:37 UTC
Permalink
Hallo,
Post by Ulli Horlacher
Post by Alexander Goetzenstein
Hallo,
Post by Ulli Horlacher
Post by Alexander Goetzenstein
ja, das tut der dd-Befehl (dd steht für Disk Dump)
Nein, "data definition".
Dessen Syntax ist auch voellig kontraer zu allen anderen UNIX Kommandos,
weil dd von OS/370 JCL abstammt.
Post by Alexander Goetzenstein
indem er den Inhalt einer Disk bitweise liest bzw. schreibt.
Nein, blockweise. Bitweise kann man keinen Datentraeger lesen.
mal so rein aus akademischer Neugier ohne praktischen Wert: könnte man
die blocksize auch auf 1 Byte (1 Bit geht wohl nicht) setzen und damit
auch byteweise lesen/schreiben?
Ich kenne keinen Datentraeger, der byteweise lesen erlaubt. Das kleinste
sind 512 Byte Bloecke. Oft aber ein vielfaches davon.
Du kannst zwar dd anweisen byteweise zu lesen, aber das liest nicht direkt
vom Datentraeger sondern vom page cache.
Und wie wäre das beim Schreiben: funktioniert das (meinetwegen über den
Cache) byteweise?
--
Gruß
Alex
Ulli Horlacher
2023-05-29 17:49:24 UTC
Permalink
Post by Alexander Goetzenstein
Post by Ulli Horlacher
Ich kenne keinen Datentraeger, der byteweise lesen erlaubt. Das kleinste
sind 512 Byte Bloecke. Oft aber ein vielfaches davon.
Du kannst zwar dd anweisen byteweise zu lesen, aber das liest nicht direkt
vom Datentraeger sondern vom page cache.
Und wie wäre das beim Schreiben: funktioniert das (meinetwegen über den
Cache) byteweise?
IMMER nur blockweise.
Der page cache regelt das dann fuer dich im Hintergrund.
--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: ***@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: https://www.tik.uni-stuttgart.de/
Jörg Tewes
2023-05-08 20:06:33 UTC
Permalink
Post by Alexander Goetzenstein
Hallo,
Post by Shinji Ikari
Just for the Records: Welche Marke/Modell/Version war es denn?
die SSD meldet sich als FORESEE. Im Netz finde ich kaum etwas darüber.
Hmm nutzt du eine Suchmaschine die weniger anzeigt als Google?

"Ungefähr 394.000 Ergebnisse"

Klar da sind haufenweise Kaufangebote dabei, aber z.B. auch eine Seite
vom "Hersteller"

<https://www.longsys.com/product/solid-state-drive/>
--
Bye Jörg


Religionskriege sind Konflikte zwischen erwachsenen Menschen, bei
denen es darum geht, wer den cooleren, imaginären Freund hat. Wenn
Jesus gevierteilt worden wäre, hätten wir heute dann Mobiles über der
Tür hängen?
Alexander Goetzenstein
2023-05-09 09:23:33 UTC
Permalink
Hallo,
Post by Jörg Tewes
Post by Alexander Goetzenstein
Hallo,
Post by Shinji Ikari
Just for the Records: Welche Marke/Modell/Version war es denn?
die SSD meldet sich als FORESEE. Im Netz finde ich kaum etwas darüber.
Hmm nutzt du eine Suchmaschine die weniger anzeigt als Google?
Vielleicht anders sortiert?
Post by Jörg Tewes
"Ungefähr 394.000 Ergebnisse"
Ja, das könnte gefühlt hinkommen. Jedoch waren so etwa die ersten zwei
Seiten hauptsächlich von Online-Übersetzern gefüllt, bis der erste
Treffer zur FORESEE SSD kam, und der war nicht besonders aussagekräftig.
Da habe ich dann irgendwann nicht mehr weiter gelesen...
Post by Jörg Tewes
Klar da sind haufenweise Kaufangebote dabei, aber z.B. auch eine Seite
vom "Hersteller"
<https://www.longsys.com/product/solid-state-drive/>
Danke.
--
Gruß
Alex
Thomas Niering
2023-05-07 07:20:00 UTC
Permalink
Hallo Alexander,
Post by Alexander Goetzenstein
es sind ja regelmäßig knapp 3 Monate Nichtbenutzung, kein jahrelanges
Liegenlassen. Reicht offenbar auch schon. Das hatte ich nicht erwartet.
Radio Eriwan, kommt drauf an.

Wenn man eine Consumer-SSD lagerst, kommt es darauf an, wie warm sie im
Betrieb und beim Ausschalten war. Je nachdem wie diese Kombination ist,
hält die SSD länger/kürzer ohne Strom durch...

Wenn du es genau wissen willst:
https://pcper.com/wp-content/uploads/2014/03/1036-alvin-cox-compatibility-mode-0.pdf
https://www.anandtech.com/print/9248/the-truth-about-ssd-data-retention

Ciao Thomas
Alexander Goetzenstein
2023-05-08 06:37:14 UTC
Permalink
Hallo,
Post by Thomas Niering
Hallo Alexander,
Post by Alexander Goetzenstein
es sind ja regelmäßig knapp 3 Monate Nichtbenutzung, kein jahrelanges
Liegenlassen. Reicht offenbar auch schon. Das hatte ich nicht erwartet.
Radio Eriwan, kommt drauf an.
Wenn man eine Consumer-SSD lagerst, kommt es darauf an, wie warm sie im
Betrieb und beim Ausschalten war. Je nachdem wie diese Kombination ist,
hält die SSD länger/kürzer ohne Strom durch...
das Ganze kann man wohl im Labor ermitteln; ich könnte die Temperatur
unter Normalbedingungen im Betrieb nicht ermitteln. Ich könnte sie aber
auch nicht ändern, da die Rechner nicht anderswo untergebracht werden
können als im Büro.
Ehrlich gesagt verstehe ich davon nur Bruchstücke.
--
Gruß
Alex
Thomas Niering
2023-05-09 04:30:00 UTC
Permalink
Hallo Alexander,
Post by Alexander Goetzenstein
das Ganze kann man wohl im Labor ermitteln;
Das kann man auch als Anwender/Admin. Lohnt nur nicht.
Post by Alexander Goetzenstein
Ehrlich gesagt verstehe ich davon nur Bruchstücke.
Der zweite Link erklärt die JEDEC-Spezifikation und stellt ein paar
Mythen zu diesem Thema ins richtige Licht.

Lange Rede, kurzer Sinn, eine in einem normalen Rechner verbaute
Consumer-SSD wird ihre Daten deswegen nicht innerhalb eines Jahres
verlieren.

Ciao Thomas
Thomas Niering
2023-05-07 06:54:00 UTC
Permalink
Hallo Alexander,
Post by Alexander Goetzenstein
Könnte also ein
dd if=/dev/sda of=/dev/sdb
dd if=/dev/sdb of=/dev/sda
helfen, oder wäre zu erwarten, dass der Fehler mitwandert?
Nein, das würde bei Festplatten helfen, aber nicht bei SSDs.
Bei SSDs wäre das sogar kontraproduktiv...

Flashspeicher hat nur eine begrenzte Anzahl an Schreibvorgängen, danach
kann der Speicher nur noch ausgelesen werden. Hinzu kommt, dass man
Flashzellen in kleinen Portionen beschreiben aber nur in viel größeren
Portionen wieder löschen (=langsam!) kann.

Die Firmware eines Flashspeichers sorgt ständig dafür, dass die Zellen
möglichst gleichmäßig benutzt werden und dass immer Zellen für das
Schreiben von Daten zur Verfügung stehen. Dazu verschiebt sie im
Hintergrund beständig Daten und löscht nicht mehr benötigte Zellen...

Ciao Thomas
Shinji Ikari
2023-04-30 11:55:20 UTC
Permalink
Guten Tag
Post by Marcel Mueller
Post by Shinji Ikari
Flashspeicher waren noch nie als Archivierungsmedium fuer eine grosse
Anzahl von Jahren gedacht oder geeignet.
Naja, ganz so pauschal stimmt das nicht. Das BIOS eines jeden Mainboards
... liegt nicht stromlos rum, sondern wird durch eine energiequelle
gespeist (durch die Stuetzbatterie sogar fast durchgehend).
Post by Marcel Mueller
oder einer Graka
Hast Du das mals ausprobiert und eine halbwegs aktuelle Grafikkarte
mit flashbarem BIOS eine grosse Anzahl von Jahren stromlos in die Ecke
gelegt und dann versucht in Betrieb zu nehmen?
Post by Marcel Mueller
und diverser andere Teile liegt auch seit Jahrzehnten
ausschließlich in Flash-Speicher.
Zu Archivierungszwecken durchgehend stromlos?
Beispiele?
Post by Marcel Mueller
Mir ist allerdings bisher auch bei älteren SSDs noch kein Datenverlust
untergekommen. Die älteste ist eine Postville G2. Ich habe allerdings es
auch nicht gezielt darauf angelegt.
Und die hast Du mit Daten zu Archivierungszwecken jahrelang stromlos
in die Ecke gelegt und danach überprueft ob alle Bits wirklich noch
korrekt waren?
Marcel Mueller
2023-04-30 18:03:16 UTC
Permalink
Post by Shinji Ikari
Guten Tag
Post by Marcel Mueller
Post by Shinji Ikari
Flashspeicher waren noch nie als Archivierungsmedium fuer eine grosse
Anzahl von Jahren gedacht oder geeignet.
Naja, ganz so pauschal stimmt das nicht. Das BIOS eines jeden Mainboards
... liegt nicht stromlos rum, sondern wird durch eine energiequelle
gespeist (durch die Stuetzbatterie sogar fast durchgehend).
Falsch. Der Flash-Chip hat keine Batterieversorgung. Der Verbrauch wäre
viel zu hoch. Lediglich die RTC (Uhr) hat eine Batterieversorgung.
Und früher hatte dieser Chip noch insgesamt 256 Bytes gepuffertes RAM
(abzüglich der Zellen für die Uhr), um sich die BIOS-Einstellungen zu
merken. Das reicht heute nirgendwo mehr hin. Üblicherweise werden die
Daten heute in einem seriellen EEPROM gespeichert - ebenfalls
Flash-Memory, nur dass sich darin die Speicherzellen einzeln löschen lassen.
Post by Shinji Ikari
Post by Marcel Mueller
oder einer Graka
Hast Du das mals ausprobiert und eine halbwegs aktuelle Grafikkarte
mit flashbarem BIOS eine grosse Anzahl von Jahren stromlos in die Ecke
gelegt und dann versucht in Betrieb zu nehmen?
Nein, _aktuelle_ GraKas jahrelang in die Ecke legen ist doof. ;-)
Aber ich habe alte Rechner, die jahrelang in der Ecke gestanden haben,
und die gehen eigentlich immer wieder an. Meist ist allenfalls die
BIOS-Batterie leer.
Ich hatte wie gesagt nur ein einziges mal einen Fall, wo eine GraKa
nachweislich mit BIOS-Alzheimer ausgefallen ist. Nachweislich deshalb,
weil sie nach dem Nachflashen des BIOS wieder funktioniert hat.
Post by Shinji Ikari
Post by Marcel Mueller
und diverser andere Teile liegt auch seit Jahrzehnten
ausschließlich in Flash-Speicher.
Zu Archivierungszwecken durchgehend stromlos?
Beispiele?
Archivierung würde ich das Speichern der Firmware nicht nennen. Aber es
geht dabei ebenfalls um Zeiträume >10 Jahre. Insofern ist es in Grenzen
vergleichbar.
Post by Shinji Ikari
Post by Marcel Mueller
Mir ist allerdings bisher auch bei älteren SSDs noch kein Datenverlust
untergekommen. Die älteste ist eine Postville G2. Ich habe allerdings es
auch nicht gezielt darauf angelegt.
Und die hast Du mit Daten zu Archivierungszwecken jahrelang stromlos
in die Ecke gelegt und danach überprueft ob alle Bits wirklich noch
korrekt waren?
Natürlich nicht. Aber die eine oder andere war durchaus mal ein Jahr
stromlos. Und wenn der Rechner danach problemlos läuft, und ein
Smart-Test fehlerfrei durch läuft, dann hat sie noch keine Daten verloren.


Marcel
Shinji Ikari
2023-04-30 18:19:47 UTC
Permalink
Guten Tag
Post by Marcel Mueller
Post by Shinji Ikari
Post by Marcel Mueller
Post by Shinji Ikari
Flashspeicher waren noch nie als Archivierungsmedium fuer eine grosse
Anzahl von Jahren gedacht oder geeignet.
Naja, ganz so pauschal stimmt das nicht. Das BIOS eines jeden Mainboards
... liegt nicht stromlos rum, sondern wird durch eine energiequelle
gespeist (durch die Stuetzbatterie sogar fast durchgehend).
Falsch. Der Flash-Chip hat keine Batterieversorgung.
Dennoch liegen Motherboards nicht jahrelang ungenutzt bei Kunden rum.
Post by Marcel Mueller
Post by Shinji Ikari
Post by Marcel Mueller
und diverser andere Teile liegt auch seit Jahrzehnten
ausschließlich in Flash-Speicher.
Zu Archivierungszwecken durchgehend stromlos?
Beispiele?
Archivierung würde ich das Speichern der Firmware nicht nennen.
Also keine Beispiele, da es ja um Archivierung ging?
Post by Marcel Mueller
Post by Shinji Ikari
Post by Marcel Mueller
Mir ist allerdings bisher auch bei älteren SSDs noch kein Datenverlust
untergekommen. Die älteste ist eine Postville G2. Ich habe allerdings es
auch nicht gezielt darauf angelegt.
Und die hast Du mit Daten zu Archivierungszwecken jahrelang stromlos
in die Ecke gelegt und danach überprueft ob alle Bits wirklich noch
korrekt waren?
Natürlich nicht.
Also auch nicht zutreffend.
Post by Marcel Mueller
Aber die eine oder andere war durchaus mal ein Jahr
stromlos. Und wenn der Rechner danach problemlos läuft, und ein
Smart-Test fehlerfrei durch läuft, dann hat sie noch keine Daten verloren.
Ich nutze mit Absicht zusaetzliche Checksummen fuer mir relevante
Daten.
Auf einen simplen Smarttest verlasse ich mich nicht.
Marcel Mueller
2023-05-02 20:33:55 UTC
Permalink
Post by Shinji Ikari
Dennoch liegen Motherboards nicht jahrelang ungenutzt bei Kunden rum.
Bei mir schon. Ich habe etliche historische Rechnerkomponenten, die ich
beispielsweise für Instandsetzungen alter Rechner oder auch mal zur
Ansteuerung von spezieller Althardware verwende. Bis zu 30 Jahre würde
ich sagen. Vorher war Flash auch eher unüblich.
Post by Shinji Ikari
Post by Marcel Mueller
Post by Shinji Ikari
Post by Marcel Mueller
und diverser andere Teile liegt auch seit Jahrzehnten
ausschließlich in Flash-Speicher.
Zu Archivierungszwecken durchgehend stromlos?
Beispiele?
Archivierung würde ich das Speichern der Firmware nicht nennen.
Also keine Beispiele, da es ja um Archivierung ging?
Nein, aber Dimension >10 Jahre schon.
Post by Shinji Ikari
Post by Marcel Mueller
Aber die eine oder andere war durchaus mal ein Jahr
stromlos. Und wenn der Rechner danach problemlos läuft, und ein
Smart-Test fehlerfrei durch läuft, dann hat sie noch keine Daten verloren.
Ich nutze mit Absicht zusaetzliche Checksummen fuer mir relevante
Daten.
Das kann man machen, und es gibt auch einige gute Gründe für so etwas,
aber bei _diesem_ Fehler hilft es nicht.
Post by Shinji Ikari
Auf einen simplen Smarttest verlasse ich mich nicht.
Wenn man _nur_ den Zustand der SSD haben will, ist der aber schon das
Mittel der Wahl.


Marcel
Alexander Schreiber
2023-05-28 20:15:15 UTC
Permalink
Post by Marcel Mueller
Post by Shinji Ikari
Flashspeicher waren noch nie als Archivierungsmedium fuer eine grosse
Anzahl von Jahren gedacht oder geeignet.
Naja, ganz so pauschal stimmt das nicht. Das BIOS eines jeden Mainboards
oder einer Graka und diverser andere Teile liegt auch seit Jahrzehnten
ausschließlich in Flash-Speicher. Und die verlieren selten ihren Inhalt.
Flash-Alzheimer hatte ich bisher nur zweimal. Einmal bei einer Matrox
GraKa und einmal bei einem DLT-Laufwerk.
Das ist praktisch eine komplett andere Baustelle. EEPROMs haben niedrige
Kapazität (KB bis MB), sind üblicherweise SLC (single level cell) mit
relativ grossen Strukturgrössen. Typisch sind 1e6 Schreibzyklen und
10 Jahre Datenerhalt garantiert.

Flashspeicher via (µ)SD-Karten sind mittlerweile fast alle MLC (multi
level cell), kleine Strukturgrössen. Dazu kommt, dass die Hersteller
_jeden_ Chip verkaufen müssen um brauchbare Gewinne zu machen - das
heisst halt auch defekte Chips. Wenn ein 16 GB Chip beim Test mit
14 GB defekt rausfällt, dann wird er halt als 2 GB Chip verkauft.
Und wie gesagt: MLC. Das heisst, die speichern mehrere Bits als
verschiedene analoge Spannungswerte (bei QLC (quad level cells)
sind das 4 bit = 16 Spannungswerte). Und je kleiner die Strukturen,
desto mehr "tröpfeln" Elektronen aus den Zellen mit der Zeit.
Und dann gibt es da noch so nette Effekte wie read disturb (Lesen
einer Zelle ändert Spannungswerte in benachbarten Zellen). Dem
wirkt man teilweise mit Spreizcodes (DSSS) entgegen, wo jedes Bit
über mehrere Zellen "gestreckt" wird.

Mittlerweile ist praktisch alle aktuelle höchst integrierte Elektronik
allenfalls in der Logiksimulation digital. Auf der Chip-Ebene (also da,
wo letztlich Elektronen rumgeschubst werden), ist von digital nichts mehr
zu sehen, alles höchst analog. Mit viel Aufwand, sowohl technisch als
auch mathematisch, wird "nach oben" digitales Verhalten simuliert.
Post by Marcel Mueller
Es ist allerdings anzunehmen, dass neuere Modelle diesbezüglich
kritischer sind, einfach weil die Technik jetzt viel weiter ausgereizt
ist. Genaueres wissen wir dann in 10 Jahren, wenn ausreichend
Erfahrungsberichte vorliegen.
Siehe oben. Das Wunder mit dem ganzen Kram ist nicht, dass nach ein
paar Jahren im Schrank die Daten weg sind, sondern das es _überhaupt_
einigermassen funktioniert.

Man liest sich,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison
Alfred Molon
2023-04-30 09:10:13 UTC
Permalink
Post by Shinji Ikari
... wo ist die Neuigkeit fuer diese "News"group?
Nichts neues. Ich mache mir nur Sorgen, da HDDs zunehmend vom Markt
verdrängt werden.
So eine HDD kann man in einer Schublade "vergessen" und 10 Jahre später
die Daten noch lesen.
--
Alfred Molon

Olympus 4/3 and micro 4/3 cameras forum at
https://groups.io/g/myolympus
https://myolympus.org/ photo sharing site
Shinji Ikari
2023-04-30 12:00:31 UTC
Permalink
Guten Tag
Post by Alfred Molon
Post by Shinji Ikari
... wo ist die Neuigkeit fuer diese "News"group?
Nichts neues. Ich mache mir nur Sorgen, da HDDs zunehmend vom Markt
verdrängt werden.
Nun musst Du wieder ganz stark sein, auch aktuelle Festplatten sind
nicht mehr als stromloses Archivierungsmedium gedacht und geeignet.
Einige wenige Jahre sollten noch klappen, aber die Magnetbereiche, die
das Bit speichern sind so eng geworden, dass es schon nicht mehr so
einfach ist die Bits zu erkennen. Und wenn man dann noch Helumplatten
nimmt, bei denen es noch keien Langzeiterfahrung aus dem Massenmarkt
gibt, wann das Helium zu weit raus ist....

Wenn man archivieren will: mehrere Kopien speichern, alle mit Pruef-
und Wiederherstellungsinformationen versehen, getrennt lagern und
regelmaesst auf fehlerfreiheit ueberpruefen und ggf. nachsteuern.
Und wenn die ersten grossen Probleme auftreten: neue Kopie (fehlerfrei
rekonstruiert) auf neues Medium dazugesellen.
Post by Alfred Molon
So eine HDD kann man in einer Schublade "vergessen" und 10 Jahre später
die Daten noch lesen.
Das war mal...
Alfred Molon
2023-04-30 22:22:38 UTC
Permalink
Post by Shinji Ikari
Und wenn man dann noch Helumplatten
nimmt, bei denen es noch keien Langzeiterfahrung aus dem Massenmarkt
gibt, wann das Helium zu weit raus ist....
Ich hab da ein bisschen recherchiert:

Hier ist die Rede von 100 Jahren:
https://blog.westerndigital.com/race-to-seal-helium/
Post by Shinji Ikari
After hundreds of testing hours, Stipe could prove a reliable,
low-cost, and form factor-abiding way to seal helium in HDDs for 100 years.

Toshiba gibt für die 18TB HDD eine MTBF von 2 500 000 h an:

https://toshiba.semicon-storage.com/ap-en/storage/product/data-center-enterprise/cloud-scale-capacity/articles/mg09-series.html#:~:text=The%20MG09%20Series%20features%20Toshiba%E2%80%99s%20third-generation%2C%209-disk%20Helium-sealed,and%20storage%2C%20and%20File%20and%20Object%20storage%20solutions.

2,5 Mio Std sind 285 Jahre.

Auf dieser Website (kuert-datenrettung.de)
https://www.kuert-datenrettung.de/de/blog/helium-festplatten-infos-ausfallrate-defekt-praxis
Post by Shinji Ikari
Das auffallendste Merkmal dieser Statistik ist die Erkenntnis, dass
es nur wenige Differenzen hinsichtlich der jährlichen Ausfallrate (AFR)
zwischen Helium- und Luft-befüllten Hard-Disks gibt. Backblaze vermutet
hierbei, dass Helium die Lebensdauer im Gegensatz zu Luft-befüllten
Platten nicht beeinträchtigt.
--
Alfred Molon

Olympus 4/3 and micro 4/3 cameras forum at
https://groups.io/g/myolympus
https://myolympus.org/ photo sharing site
Shinji Ikari
2023-04-30 22:30:52 UTC
Permalink
Guten Tag
Post by Alfred Molon
Post by Shinji Ikari
Und wenn man dann noch Helumplatten
nimmt, bei denen es noch keien Langzeiterfahrung aus dem Massenmarkt
gibt, wann das Helium zu weit raus ist....
Es ist auffaellig, dass es Aussagen, aber keine solchen Garantien der
Hersteller gibt.
'Werbung' ist immer etwas uebertrieben.

Und nur um solcge Aussagen mal ein bisschen mit anderen Aussagen zu
vergleichen:
Wie lange sollten CDs nochmal halten?
Und wie war das mit W10?
Und da gab es auch mal groessenwahnsinnige Ideen von sogar einem
1000jaehrigen Reich.
Post by Alfred Molon
Post by Shinji Ikari
Das auffallendste Merkmal dieser Statistik ist die Erkenntnis, dass
es nur wenige Differenzen hinsichtlich der jährlichen Ausfallrate (AFR)
zwischen Helium- und Luft-befüllten Hard-Disks gibt. Backblaze vermutet
hierbei, dass Helium die Lebensdauer im Gegensatz zu Luft-befüllten
Platten nicht beeinträchtigt.
Helium ist im breiten Markt noch nicht lang genug vertreten um
wirklich Aussagen zur Langzeitarchivierung machen zu koennen.
In 5 oder 10 Jahren wird es sich zeigen.
Und wer laesst heute schon eine hochkapazitive Helium-Festplatte
wirklich als Archiv mehrere Jahre in der Schublade liegen?

Aber dann ist die Garantie sowieso futsch. Die muessen aus hersteller
Kostensicht am besten nur knapp 5 Jahre halten, danach sind die aus
deren Verantwortung raus und der Kunde kauft neu.
Alfred Molon
2023-05-01 07:46:34 UTC
Permalink
Also, man kann diese Diskussion lange fortsetzen, und ich bin auch kein
HDD Experte.
Aber wenn ich mir diese Zahlen der Hersteller anschaue (100 Jahre, 2,5
Mio Std.) gibt es nun mal keine Hinweise darauf, dass HDDs mit Helium
innerhalb weniger Jahre aus Heliummangel sterben. Vielleicht eher aus
mechanischen Gründen.
--
Alfred Molon

Olympus 4/3 and micro 4/3 cameras forum at
https://groups.io/g/myolympus
https://myolympus.org/ photo sharing site
Arno Welzel
2023-05-01 13:44:58 UTC
Permalink
Post by Shinji Ikari
Guten Tag
Post by Shinji Ikari
Und wenn man dann noch Helumplatten
nimmt, bei denen es noch keien Langzeiterfahrung aus dem Massenmarkt
gibt, wann das Helium zu weit raus ist....
[...]
Post by Shinji Ikari
Und nur um solcge Aussagen mal ein bisschen mit anderen Aussagen zu
Wie lange sollten CDs nochmal halten?
10-25 Jahre - aber nur bei entsprechenden Lagerungsbedingungen.

Ich habe hier einige gepresste CDs, die älter sind (teilweise noch aus
den frühen 1990er Jahren) und problemlos gelesen werden können. Die
ältesten gebrannten Medien in meinem Archiv sind von 1997 und damit
aktuell auch schon fast 26 Jahre alt - und ja, die sind auch noch
fehlerfrei lesbar.

Nur weil es *auch* Exemplare gibt, die aufgrund der Lagerungsbedingungen
oder mangelhafter Fertigung nicht so lange halten, bedeutet nicht, dass
die Aussage zur Haltbarkeit von CDs pauschal falsch ist.
Post by Shinji Ikari
Und wie war das mit W10?
Ja, was dar damit? Eine offizielle Aussage von Microsoft, dass Windows
10 die letzte Windows-Version sein wird, gab es nie. Dieser Mythos geht
zurück auf Bemerkung Jerry Nixon auf der Microsoft Ignite-Konferenz 2015.

Siehe auch:
<https://itwelt.at/knowhow/warum-gibt-es-windows-11-wenn-windows-10-das-letzte-windows-ist/>
--
Arno Welzel
https://arnowelzel.de
Alexander Schreiber
2023-05-28 20:25:11 UTC
Permalink
Post by Arno Welzel
Post by Shinji Ikari
Guten Tag
Post by Shinji Ikari
Und wenn man dann noch Helumplatten
nimmt, bei denen es noch keien Langzeiterfahrung aus dem Massenmarkt
gibt, wann das Helium zu weit raus ist....
[...]
Post by Shinji Ikari
Und nur um solcge Aussagen mal ein bisschen mit anderen Aussagen zu
Wie lange sollten CDs nochmal halten?
10-25 Jahre - aber nur bei entsprechenden Lagerungsbedingungen.
Ich habe hier einige gepresste CDs, die älter sind (teilweise noch aus
den frühen 1990er Jahren) und problemlos gelesen werden können. Die
ältesten gebrannten Medien in meinem Archiv sind von 1997 und damit
aktuell auch schon fast 26 Jahre alt - und ja, die sind auch noch
fehlerfrei lesbar.
Nur weil es *auch* Exemplare gibt, die aufgrund der Lagerungsbedingungen
oder mangelhafter Fertigung nicht so lange halten, bedeutet nicht, dass
die Aussage zur Haltbarkeit von CDs pauschal falsch ist.
Tendenziell würde ich davon ausgehen, dass die ältern CD-RW Medien
eine bessere Haltbarkeit haben als die neueren. Einfach weil man noch
nicht so viel Erfahrung hatte und erst später die Fertigungskosten
optimieren konnte (z.B. Reflexschicht am Anfang war typischweise eine
(hauchdünne) Lage Gold, später dann Aluminium).

Man liest sich,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison
Başar Alabay
2023-05-29 09:13:59 UTC
Permalink
Post by Arno Welzel
Post by Shinji Ikari
Guten Tag
Post by Shinji Ikari
Und wenn man dann noch Helumplatten
nimmt, bei denen es noch keien Langzeiterfahrung aus dem Massenmarkt
gibt, wann das Helium zu weit raus ist....
[...]
Post by Shinji Ikari
Und nur um solcge Aussagen mal ein bisschen mit anderen Aussagen zu
Wie lange sollten CDs nochmal halten?
10-25 Jahre - aber nur bei entsprechenden Lagerungsbedingungen.
Ich habe hier einige gepresste CDs, die älter sind (teilweise noch aus
den frühen 1990er Jahren) und problemlos gelesen werden können. Die
ältesten gebrannten Medien in meinem Archiv sind von 1997 und damit
aktuell auch schon fast 26 Jahre alt - und ja, die sind auch noch
fehlerfrei lesbar.
Ich finde diese ganzen »oh, bald Schrott«-Aussagen merkwürdig! Tapes …
ich habe Audiocassetten aus den mitteleren Siebzigern, die hervorragend
erhalten sind. Aus den frühen und späten achtzigern ebenfalls, sogar mit
Dolby (wobei da eine Trim-Funktion Gold wert ist). Ich habe vereinzelt
CDs aus den früher achtzigern, die problemlos spielen. Ich habe sehr
viele (eher lowlevel goldene) selbstgebrannte CDs aus der zweiten Hälfte
der neunziger, die problemlos abspielbar sind.

Interessant ist, daß ich auch einige der »berühmten« ab-Werk MPO-CDs
habe, die für ihr »disk rot« bekannt sind. Selbst die spielen zumeist
noch. Ich glaube, eine hatte es tatsächlich zerlegt.

Ja, ich bin gespannt, ob meine achtiger Jahre Cartridges und Karten noch
lesbar sein werden, wenn ich irgendwann meine alten Yamaha, Technics und
Ensoniq Kisten aus der Zeit anschmeiße, aber zumindest vor acht bis fünf
Jahren funktionierten sie noch. Ich meine Synthesizer.

Also, was sind 25 Jahre? Viele meiner »kritischen« Medien sind älter und
funktionieren tadellos. Ach ja, Tonbänder auch noch, erstaunlicherweise.
Also, sie funktionierten (fast alle) vor circa zehn Jahren, als ich sie
digitalisierte. Endfünfziger, Mitte sechziger und Anfang siebziger
Bänder. Am wenigsten funktionierte das neueste Band von Mitte der
neunziger, das wir damals als Backingsoundtape für die Bühne gekauft
hatten. Verrückt.

B. Alabay
Arno Welzel
2023-06-12 10:34:23 UTC
Permalink
Başar Alabay, 2023-05-29 11:13:

[...]
Post by Başar Alabay
Also, was sind 25 Jahre? Viele meiner »kritischen« Medien sind älter und
Eine lange Zeit.
Post by Başar Alabay
funktionieren tadellos. Ach ja, Tonbänder auch noch, erstaunlicherweise.
Also, sie funktionierten (fast alle) vor circa zehn Jahren, als ich sie
digitalisierte. Endfünfziger, Mitte sechziger und Anfang siebziger
Bänder. Am wenigsten funktionierte das neueste Band von Mitte der
neunziger, das wir damals als Backingsoundtape für die Bühne gekauft
hatten. Verrückt.
Irgendwann treten chemische Veränderungen ein, die Bänder wie auch CDs
unlesbar machen können. Nur weil es 25 Jahre gut ging, bedeutet nicht,
dass es auch in weiteren 10-20 Jahren so bleibt.
--
Arno Welzel
https://arnowelzel.de
Lesen Sie weiter auf narkive:
Loading...