Forum: PC Hard- und Software defekte SD-Karte blockiert Alles

Frank E. schrieb:
> Man möchte doch meinen, dass
> ausgerechnet solche Software mit defekten Partitionen oder Directories
> umgehen könnte
Habe ich auch gerade erst erfahren müssen. Zwei TB-Karten nicht mehr 
lesbar. Man sollte mit solcher Software doch wenigstens wieder eine 
Formatierung hin bekommen. Dazu werden die, in verschiedenen Lesegeräten 
(auch extern) nicht einmal mehr erkannt.
Also wenn da noch interessante Beiträge kommen und jemand wirklich ein 
Software kennt, die ein Format auf den Karten herstellen kann, würde ich 
mich auch drüber freuen.
Danke!

@TO
Ich wollte und will nicht deinen Beitrag kapern, aber wenn das Thema da 
ist, möchte ich mich da gerne einklinken.
Danke für dein Verständnis!

Moin,

Frank E. schrieb:
> Ernsthaft: Noch ne Idee, wie ich das Problem lösen könnte? Danke.

Wie immer, wenn irgendein Massstoragedevice schwindelig ist:
ddrescue unter einem vernuenftigen Betriebssystem laufend.
Wenns damit nicht geht, ein Image vom defekten Datentraeger zu ziehen, 
ist's erstmal Essig.

Gruss
WK

Es könnte ja auch sein, dass die beste Software nichts nützt, wenn die 
Hardware des SD-Interfaces defekt ist, evtl. sogar einen Kurzen 
verursacht.-
Gruss Jan

Man müßte erstmal testen, ob sich die Hardware überhaupt ansprechen 
läßt, erstmal im 1-Bit SPI-Mode und dann ob auch 4-Bit SPI geht.

Ich weiß nicht, ob es für PCs solche low level Diagnose gibt. Ansonsten 
muß man sich einen µC entsprechend programmieren.

Daß der Explorer am Rad dreht, wenn die Hardware defekt ist (z.B. eine 
Bitleitung hängt auf low), kann ich nachvollziehen.
Man sollte daher immer darauf achten, wenn man die SD Karte einsetzt 
oder entnimmt, daß man sich vorher am Gerät erdet, nachdem man über den 
Teppich angeschlurft kommt.

Dieses Detail hatte ich leider vergessen zu erwähnen:

Die SD-Karte wird zunächst ganz normal als Laufwerk bzw. Volume erkannt 
und angezeigt. Man kann sogar über "Eigenschaften" (Win) bzw. "Info" 
(Mac) Daten abrufen, wie Format ("ExFat") und benutzte und freie 
Kapazität (23 von 120GB).

Das Drama beginnt erst bei einem Zugriffs-Versuch ...

Frank E. schrieb:
> Die SD-Karte wird zunächst ganz normal als Laufwerk bzw. Volume erkannt

Dann sollte dd_rescue unter Linux eine kleine Chance haben da was retten 
zu können.

Hat aber den Pferdefuss das wenn es schief geht die Rechnung vom 
Datenrettungsunternehmen noch höher ausfallen kann.

Frank E. schrieb:
> Zunächst versuchte ich es ohne extra Software, einfach über das
> Dateisystem.
>
> Aber sowohl am Windows-Laptop (Win11) als auch an einem M2 Macbook

Das war schon der erste Fehler.

Frank E. schrieb:
> Und das wollen moderne Betriebssysteme sein?
...
> Nächster Versuch: Jeweils eine der vielfach angepriesenen
> Foto-Rettungssoftwares. Gleiches Ergebnis. Man möchte doch meinen, dass
> ausgerechnet solche Software mit defekten Partitionen oder Directories
> umgehen könnte - wenigstens nicht abstürzen sollte.

Wieso nimmst Du an, dass die Partitionen oder Filesysteme da drauf 
kaputt wären?
Wenn sämtliche Software und Betriebssysteme das gleiche Häng-Symptom 
zeigen, dann sollte wohl klar sein, dass dies eher ein Hardware-Problem 
sein dürfte. D.h., eine I/O-Aktion an der SD-Karten-Schnittstelle bleibt 
einfach hängen, und kommt nicht mehr zurück. Da würde nur eine Art 
Timeout helfen, sofern sowas durch die Hardwarer überhaupt unterstützt 
würde.
Es könnte natürlich auch sein, dass die Sektoren/Blöcke im Filesystem 
fälschlicherweise im Kreis verpointert sind, und somit der 
Filesystemtreiber sich beim Zusammensuchen von verketteten Dingen im 
Kreise dreht - also nie ein Ende findet. Liese sich nur entschärfen 
durch einen "Kreiskettendetektor" ;-) ...

Es sollte normal sein ,dass man auch die Bilder einer Kamera sichert. 
Das heißt im Urlaub täglich. Speicherkarte kann immer mal defekt werden. 
Da hat man Reserve dabei weil die Kosten im Vergleich zu einer Reise 
wenig.
Aber was sage ich dam weiß ja eh jeder...

Es gab mal eine Seite (iss mir entfallen wo) eine Anleitung, da wurde 
die defekte Karte in einen alten ISA-Bus Steckkontakt gesteckt und mit 
ein paar Kabeln an den Rechner angschlossen. Dabei waren Demo Routinen 
mit denen man direkt auf die Karte zugegriffen konnte. Gabs aber kein 
komplettes Programm, das musste man selber schreiben. Auf diese Weise 
konnte ich meine defekte Karte auslesen, die konnte auch von keinem 
System mehr angesprochen werden. Ausserdem als Zusatz Bonbon konnte man 
div Karten mit 1 Sektor mehr formatieren (ist z.B. der Kopierschutz der 
TomTom Navi Karten)...

Herbert Z. schrieb:
> Es sollte normal sein ,dass man auch die Bilder einer Kamera sichert.

Das wäre natürlich die sicherste und billigste Wiederherstellungsoption.
Und ich gebe offen zu, mir besonders wichtige Bilder sichere ich sogar 
auf 2 Medien (Hosenträger + Gürtel).

Jim M. schrieb:
> Frank E. schrieb:
>> Die SD-Karte wird zunächst ganz normal als Laufwerk bzw. Volume erkannt
>
> Dann sollte dd_rescue unter Linux eine kleine Chance haben da was retten
> zu können.
>
> Hat aber den Pferdefuss das wenn es schief geht die Rechnung vom
> Datenrettungsunternehmen noch höher ausfallen kann.

Speziell warum? dd liest doch nur das Block Device?

Verglichen mit den Versuchen mit Windows dürfte das Risiko minimal sein.

Jens G. schrieb:
> dann sollte wohl klar sein, dass dies eher ein Hardware-Problem sein
> dürfte.

Na und? Natürlich würde ein "vernünftiges" Betriebssystem (dessen 
fundamentale Aufgabe ist, die Vermittlung zwischen Software und Hardware 
"sicher zu stellen") auch den Fehler ordentlich auffangen und dem User 
melden. Ich selbst habe ähnliche Fälle erlebt, wo ein Scheiss USB-Stick 
den Laptop komplett lahm legte.

Wäre es denkbar, dass die verkettete Liste der Cluster fehlerhaft einen 
Ring oder eine Rekursion ergibt, so dass das Lesen des 
Inhaltsverzeichnisses endlos lang dauert?

Ein entsprechendes Kommando (dir) im Terminalfenster hilft vielleicht.

Nemopuk schrieb:
> Wäre es denkbar, dass die verkettete Liste der Cluster fehlerhaft einen
> Ring oder eine Rekursion ergibt, so dass das Lesen des
> Inhaltsverzeichnisses endlos lang dauert?

Sowas sollte ein nicht allzudämlich programmiertes Betriebssystem 
abfangen.

Hier wird das Problem aber in einem Defekt der Karte selbst liegen, die 
dem Kartenleser bei Lesezugriffen Unmach bereitet, und da die ganze 
Devicetreiberei, die zwischen diesem Kartenleser und dem Dateisystem 
liegt, auch etliche Lesewiederholungsversuche enthält, wird die ganze 
Chose träge.

Mit einem die Karte direkt ansteuernden µC könnte man sich Gewissheit 
verschaffen, sofern man den Code dafür nicht einfach nur irgendwo aus 
dem Internet kopiert hat, sondern dort insbesondere die 
Fehlererkennungs- und Behandlungsroutinen kennt und beeinflussen kann.

Dann könnte man prüfen, ob sich die Sektoren alle problemlos lesen 
lassen.


Wird nur 'ne Weile dauern, die Karte ist 128 GB groß ...

Probiere mal damit. Eins von beiden war in der Lage kaputte SD Karten zu 
lesen, weiß nur nicht mehr welches.

https://www.mediafire.com/file/iwqzuo0z3q0ro05

https://www.mediafire.com/file/p8sc6iw7mm8tdh3

Hallo,
ich hatte Erfolg mit Recuva v1.51.1063,
unbeding diese Version nicht updaten.
MfG

Frank E. schrieb:
> Aber sowohl am Windows-Laptop (Win11) als auch an einem M2 Macbook
> (Sequoia) bringt es das Scheissding tatsächlich fertig, den Explorer
> hier und den Finder dort quasi zu 100% zu "freezen". Rotierender blauer
> Kringel unter Windows, Beachball am Mac. Und zwar dauerhaft, es hilft
> nur, den jeweiligen Prozess "abzuschiessen".

So eine verreckte Karte versucht man auch nicht mit irgend einem 
Dateimanager zu öffnen, denn der bleibt i.d.R bei den Schadstellen erst 
mal hängen und versucht die Stelle trotzdem zu lesen. Da er das bei 
jeder Fehlerstelle erneut versucht, hat man den Eindruck, daß der Prozeß 
eingefroren ist - ist er aber oftmals nicht, man muß ihm nur ausreichend 
Zeit geben und hier reden wir unter Umständen von Stunden.

Bevor man hier irgend eine Aktion macht, versucht man erst mal eine 
Kopie des defekten Datenträgers zu erstellen. Das macht man am Besten 
mit (GNU) ddrescue. Das allseits beliebte dd versagt hier oftmals, weil 
es bei Lesefehlern abbricht und dann unbrauchbare Images erzeugt.
Danach versucht man mit einem geeigneten Tool die Datenrettung vom 
Orginaldatenträger. Bei mir hat sich da PhotoRec bewährt. Damit konnte 
ich schon einige verloren geglaubte Photos und auch andere Dateien 
wieder herstellen.
Die eigentliche Arbeit bei diesem Tool beginnt, wenn die Dateien 
wiederhergestellt sind. Man muß halt alle Dateien sichten, weil das Tool 
nur NUmmern als Dateinamen vergibt. Bei Bildern geht es mit einem 
Imageviewer relativ fix, bei anderen Dateien z.B. Word, Excel etc. ist 
es etwas zeitaufwändiger.

Hans schrieb:
> Man muß halt alle Dateien sichten, weil das Tool
> nur NUmmern als Dateinamen vergibt.

Zumindest stehen die Originalnamen (bei Kameras oft mit angehängtem 
Zeitstempel) auch im Image (als Referenz)
Und in den geretteten Bildern sind EXIF Informationen mit Zeitstempel.

GetDataBack, bietet bei Fehlern an Ignorieren und alle Ignorieren. Zun 
Test ob die SW was findet braucht man keine Lizenz.

Norbert schrieb:
> Zumindest stehen die Originalnamen (bei Kameras oft mit angehängtem
> Zeitstempel) auch im Image (als Referenz)
> Und in den geretteten Bildern sind EXIF Informationen mit Zeitstempel.
Ja das ist wohl so, aber um an diese Daten zu kommen muß man sich halt 
die Dateien anschauen. Da Fotos oftmals mehr oder weniger einmalig sind, 
ist das aber gut investierte Zeit.
Die Betrachtung mit einem geeigneten Imageviewer vorab macht aber 
durchaus Sinn, weil PhotoRec manche Dateien auch doppelt wieder 
herstellt.

Frank E. schrieb:
> Dass solche
> Leseversuche ihre Grenzen haben, ist mir auch klar, aber sich einfach
> "aufhängen"?
>
> Wo sind wir nur hingeraten :-)

du weißt was SD bedeutet? Secure Digital
es soll sicher sein im Fehlerfall,
dazu könnte Ausleseschutz nützlich sein!
Flashspeicher haben nun mal eine begrenzte Schreibanzahl.

Frank O. schrieb:
> Also wenn da noch interessante Beiträge kommen und jemand wirklich ein
> Software kennt, die ein Format auf den Karten herstellen kann

wenn die Karte kaputtgeschrieben ist?
Das wäre ein Wunder.

Hans schrieb:
> Ja das ist wohl so, aber um an diese Daten zu kommen muß man sich halt
> die Dateien anschauen. Da Fotos oftmals mehr oder weniger einmalig sind,
> ist das aber gut investierte Zeit.

Wenn man das "deutlich unterlegene" Betriebssystem nimmt ;-), kann man 
das ganze Geraffel in einem Bash Script automatisiert laufen lassen.
strings, awk, exiftool, exiv2, …

Lohnt sich aber nicht für zwanzig Bilder. Für zweitausend wohl schon.

Joachim B. schrieb:
> du weißt was SD bedeutet? Secure Digital
> es soll sicher sein im Fehlerfall,

Tja, dass möchtest du bestimmt noch einmal überdenken. ;-)

Stichwort DRM. Die Sicherheit der Daten geht denen am Ar... vorbei.

Joachim B. schrieb:
> wenn die Karte kaputtgeschrieben ist?
> Das wäre ein Wunder.

Ich habe es auch mittlerweile aufgegeben.
Die sind definitiv kaputt.

Norbert schrieb:
> Stichwort DRM. Die Sicherheit der Daten geht denen am Ar... vorbei.

ach welche Sicherheit welche Daten werden wohl mit DRM gemeint sein 
deine jedenfalls nicht, die SD Karte von meinem Navi kann nicht kopiert 
werden.

Joachim B. schrieb:
> Norbert schrieb:
>> Stichwort DRM. Die Sicherheit der Daten geht denen am Ar... vorbei.
>
> ach welche Sicherheit welche Daten werden wohl mit DRM gemeint sein
> deine jedenfalls nicht, die SD Karte von meinem Navi kann nicht kopiert
> werden.

Aber genau das ist es doch was ich schrieb.
Deine zuvor getätigte Aussage suggerierte, dass SD irgend etwas mit der 
Sicherheit der Nutzerdaten zu tun hätte.

Frank O. schrieb:
> Ich habe es auch mittlerweile aufgegeben.
> Die sind definitiv kaputt.

1. Hatte ich auch schon mehrfach. Da hilft vorher öfter sichern per 
Adapter. Eine SD, die nicht mehr erkannt wird, ist meist tot.
Ein Kollege hatte ähnlichen Datenverlust bei der Hochzeitsreise. Seitdem 
steht die Frage, wann er für Ersatz-Fotos die nächste Hochzeitsreise 
macht :-)

2. Joachim B. schrieb:
> die SD Karte von meinem Navi kann nicht kopiert werden.
Das geht nicht mit jeder beliebigen SD. Es wird was geprüft. Frage ist, 
ob sie lesbar ist od. die Kopie nicht läuft, weil andere SD erkannt 
wird.

Hallo Frank E.,

Frank E. schrieb:

> Gleiches Ergebnis. Man möchte doch meinen, dass
> ausgerechnet solche Software mit defekten Partitionen oder Directories
> umgehen könnte - wenigstens nicht abstürzen sollte. Dass solche
> Leseversuche ihre Grenzen haben, ist mir auch klar, aber sich einfach
> "aufhängen"?

> Ernsthaft: Noch ne Idee, wie ich das Problem lösen könnte? Danke.

Fast alle Datenrettungssoftware setzt auf Lesbarkeit des Datenträgers.
Der Umgang mit Datenträgern, der unlesbare Sektoren/Blöcke enthält, ist 
ein gesondertes Problem, dass die Nutzung gesonderter Software 
erfordert.

Die Nutzung eines physisch vorgeschädigten Datenträgers sollte mit der 
Erstellung eines Duplikats beginnen - aufgrund des invasiven Verhaltens 
von Windows-Software sinnvollerweise unter Linux.
GNU Ddrescue ist eine gute Wahl, weil es über Algorithmen verfügt, die 
mutmaßliche Schadstellen auf dem Daten überspringen um das Ausbremsen 
der Duplikatserstellung zu minimieren.

Danach kann man alle Datenrettungssoftware der Welt, die typischerweise 
nur Daten liest (Ausnahme TestDisk) auf das Duplikat loslassen.

Frank O. schrieb:
> Habe ich auch gerade erst erfahren müssen. Zwei TB-Karten nicht mehr
> lesbar. Man sollte mit solcher Software doch wenigstens wieder eine
> Formatierung hin bekommen. Dazu werden die, in verschiedenen Lesegeräten

Formatieren vernichtet eventuell wiederherstellbare Daten.
Formatieren ist ein Synonym für Löschen, nicht für Datenrettung.

Jim M. schrieb:
> Dann sollte dd_rescue unter Linux eine kleine Chance haben da was retten
> zu können.

Jim M., dd_rescue von Kurt Garloff und GNU ddrescue sind zwei 
unterschiedliche Software-Produkte, die zwar das gleiche wollen, aber 
unterschiedliche Autoren haben. GNU ddrescue ist - glaube ich - weiter 
verbreitet.

Frank O. schrieb:
> Also wenn da noch interessante Beiträge kommen und jemand wirklich ein
> Software kennt, die ein Format auf den Karten herstellen kann, würde ich
> mich auch drüber freuen.

Frank O.,

sobald der Inhalt bestmöglich gesichert ist (siehe oben), kannst Du sie 
mit  Deinem Betriebssystem formatieren. Schlägt das fehl, ist der 
Datenträger ein Fall für die Mülltonne oder den Schraubstock in der 
Garage.

Selbst wenn Du mit Spezialsoftware die Karte wieder nutzbar machst, 
trägst Du ein erhöhtes Risiko eines Folgeschadens.
Ist es das wert?

Cartman E. schrieb:
> Das war schon der erste Fehler.

Ohne Erklärung ist diese wahre Aussage für Dritte wenig hilfreich.

Jens G. schrieb:
> Es könnte natürlich auch sein, dass die Sektoren/Blöcke im Filesystem
> fälschlicherweise im Kreis verpointert sind, und somit der
> Filesystemtreiber sich beim Zusammensuchen von verketteten Dingen im
> Kreise dreht - also nie ein Ende findet. Liese sich nur entschärfen
> durch einen "Kreiskettendetektor" ;-) ...

Ein "Kreiskettendetektor" ist bei den Speicherkarten-typischen 
Dateisystemen Fat32 und ExFat überflüssig, weil Clusternummern absolut 
adressiert werden. Bei NTFS jedoch gibt es auch eine relative 
Adressierung, die auch negative Offsets zulässt.

Wenn es so wäre, würde ein Kopieren den Zieldatenträger komplett 
befüllen.
Die Entschärfung erfolgt dann durch einfache Löschung auf dem 
Quelldatenträger.

Bauform B. schrieb:
> Speziell warum? dd liest doch nur das Block Device?
>
> Verglichen mit den Versuchen mit Windows dürfte das Risiko minimal sein.

Bei vorgeschädigten rotierenden Speichermedien birgt der Einsatz von 
Sektorkopierern die Gefahr von Folgeschäden - bei Flash-Speichern eher 
weniger.

Harald K. schrieb:
> Sowas sollte ein nicht allzudämlich programmiertes Betriebssystem
> abfangen.

Der CHKDSK-Befehl bei Microsoft-Betriebssystemen bricht Clusterkreise 
auf. Das Abfangen wäre im Normalbetrieb viel zu aufwendig. Beim Einlesen 
bräuchte es einen Cluster-Pufferstruktur oder eine Cluster-Bitmap, mit 
der die Wiederholung einer Cluster-Nr. an einer anderen Stelle der Datei 
detektiert werden kann erforderlich.

Hans schrieb:
> Die Betrachtung mit einem geeigneten Imageviewer vorab macht aber
> durchaus Sinn, weil PhotoRec manche Dateien auch doppelt wieder
> herstellt.

In einer JPEG-Datei eingebettete Vorschau-Bilder werden auch 
wiederhergestellt. Das ist sinnvoll, weil die Gesamtdatei eventuell 
aufgrund von Fragmentierung falsch hergestellt wird und zur zum Teil 
oder gar nicht lesbar ist.


> Hans schrieb:
>> Man muß halt alle Dateien sichten, weil das Tool
>> nur NUmmern als Dateinamen vergibt.

Nein, Hans, bitte lies das Handbuch. Da wo das betroffene Dateiformat 
dokumentiert ist, ist die Chance groß, dass Christophe Grenier in 
PhotoRec weitere Metadaten bei der Datenrettung auswertet und bei der 
Datenrettung verwendet.

Rüdiger B. schrieb:
> GetDataBack, bietet bei Fehlern an Ignorieren und alle Ignorieren. Zun
> Test ob die SW was findet braucht man keine Lizenz.

Der Verzicht auf die Erstellung eines Klons des betroffenen Datenträgers 
ist riskant, Erklärung siehe oben.

Peter M. schrieb:
> Formatieren vernichtet eventuell wiederherstellbare Daten.

KI Kacke

Peter M. schrieb:
> Frank O.,
>
> sobald der Inhalt bestmöglich gesichert ist (siehe oben), kannst Du sie
> mit  Deinem Betriebssystem formatieren. Schlägt das fehl, ist der
> Datenträger ein Fall für die Mülltonne oder den Schraubstock in der
> Garage.

Das waren Karten (gleicher Einkauf) die in meinem Mobiltelefon waren. 
Zunächst verschwanden immer wieder irgendwelche Bilder und dann waren 
die überhaupt nicht mehr lesbar.
Die waren ziemlich günstig, um nicht billig sagen zu müssen. Da mir die 
Bilder nicht wichtig sind, die anderen Daten eh auf dem Telefon sind, 
ist der einzige Verlust die Karten selbst, die Zeit und die zusätzlich 
gekauften Lesegeräte.
Hätte ich auch gleich bessere Karten kaufen können.

Hallo Alexander,

Alexander schrieb:
> Peter M. schrieb:
>> Formatieren vernichtet eventuell wiederherstellbare Daten.
>
> KI Kacke

Probier's doch einmal selber mit Testdaten aus!

Nicht jeder Text, der NICHT in einem von Rechtschreibfehlern 
durchsetzten Primitivsprech geschrieben ist, muss von einer KI verfasst 
sein.

Dieser Text ist mein Werk, verfasst mit meinem Hirn ohne Zuhilfenahme 
von irgendwelchem Large-Language-Model-Ejakulat!

Spätestens meine Textstelle zum Thema Aufbruch von Clusterringen kriegt 
die KI mangels Kalibrationsvorlagen gar nicht hin.

Aber trotzdem vielen Dank für Dein Lob!

Peter M. schrieb:
> Probier's doch einmal selber mit Testdaten aus!

Was soll ich ausprobieren, formatieren?

Peter M. schrieb:
> Nein, Hans, bitte lies das Handbuch. Da wo das betroffene Dateiformat
> dokumentiert ist, ist die Chance groß, dass Christophe Grenier in
> PhotoRec weitere Metadaten bei der Datenrettung auswertet und bei der
> Datenrettung verwendet.
Der Dateiname wurde bei meinen Datenrettungen definitiv nicht wieder 
hergestellt. PhotoRec kann dies auch gar nicht, weil der Dateinahme 
weder Bestandteil der Metadaten noch des restlichen Dateiinhaltes ist. 
Der Dateiname wird im Dateisystem selbst gespeichert und hat mit der 
eigentlichen Datei erst einmal nichts zu tun. Er dient lediglich dazu 
die Datei im System wieder zu finden. Selbst die Extention wie z.B. 
.png, .jpg etc. etc. wird eigentlich nicht benötigt, da die Dateien von 
den Programmen an Hand der Dateisignatur erkannt werden. Kann man leicht 
selbst überprüfen (einfach mal die Extention entfernen und dann die 
Datei (beim Mac) mal auf die Vorschau ziehen, die Datei wird korrekt 
geöffnet). PNG Bilder z.B. beginnen immer mit 0x89 50 4E 47 0D 0A 1A 0A. 
Für die korrekte Erkennung und Behandlung der Datei sind diese 8 Byte 
völlig ausreichend.
Bei einem fehlerhaften/zerstörten Dateisystem sind in aller Regel Teile 
der Dateizuordnungstabellen kaputt. Ein Auslesen der Dateinamen ist 
somit meist nicht mehr möglich. Die Zuordnung des ursprünglich 
vergebenen Dateinamens ist somit nicht mehr möglich. Genau aus diesem 
Grund vergibt PhotoRec den wieder herstellten Dateien einen Namen nach 
dem Schema fxxxxxx.EXT. Die x sind beliebige Ziffern. Die Extention .EXT 
gewinnt es aus den Magicbytes. Ist keine Zuordnung des Dateityps 
möglich, dann wird meines Wissens, wenn ich mich recht entsinne, .file 
als Extention vergeben.

Hallo Hans!

Hans schrieb:
> Peter M. schrieb:
>> Nein, Hans, bitte lies das Handbuch. Da wo das betroffene Dateiformat
>> dokumentiert ist, ist die Chance groß, dass Christophe Grenier in
>> PhotoRec weitere Metadaten bei der Datenrettung auswertet und bei der
>> Datenrettung verwendet.

> Der Dateiname wurde bei meinen Datenrettungen definitiv nicht wieder
> hergestellt.

Vorher schriebst Du:
> weil das Tool nur NUmmern als Dateinamen vergibt.

Das ist nicht richtig. Bitte mache Dir doch die Mühe und lese:

https://www.cgsecurity.org/testdisk_doc/photorec.html#photorec-file-name-and-date

Zitat:

[...
Using metadata information embedded in the recovered file, the file may 
be renamed to include the documentation title (example, Microsoft Office 
doc/xls/ppt or Acrobate pdf files) like recup_dir.1/
f0016741_Prudent_Engineering_Practice_for_Cryptographic_Protocols.pdf.
...]

Jetzt aber sprichst Du davon, dass nie Dateinamen wiederhergestellt 
werden.
Ich habe Deine Aussage "nur Nummern als Dateinamen" kommentiert!

> die Datei im System wieder zu finden. Selbst die Extention wie z.B.
> .png, .jpg etc. etc. wird eigentlich nicht benötigt, da die Dateien von
> den Programmen an Hand der Dateisignatur erkannt werden. Kann man leicht
> selbst überprüfen (einfach mal die Extention entfernen und dann die
> Datei (beim Mac) mal auf die Vorschau ziehen, die Datei wird korrekt

Nein. Das von Dir erlebte Verhalten ist Mac-spezifisch. Bei 
Microsoft-Betriebssystemen bestimmt die Dateinamenserweiterung, welcher 
Software die Datei übergeben wird.

Beispiel:

Schreib' unter Windows "Hans" in eine Textdatei. Speicher die als 
"test.txt"
Ein Doppelklick darauf öffnet die Datei test.txt mit einem Editor.

Benenne die Datei um in "text.exe".
Ein Doppelklick auf die Datei verursacht nun ein Fehlermeldung von 
Windows.

Frank E. schrieb:

 bringt es das Scheissding tatsächlich fertig, den Explorer
> hier und den Finder dort quasi zu 100% zu "freezen". Rotierender blauer
> Kringel unter Windows, Beachball am Mac. Und zwar dauerhaft, es hilft
> nur, den jeweiligen Prozess "abzuschiessen".
>
> Und das wollen moderne Betriebssysteme sein?

Nö, das sind Filebrowser, kein Betriebssystem.

Peter M. schrieb:
> Das ist nicht richtig. Bitte mache Dir doch die Mühe und lese:
>
> 
https://www.cgsecurity.org/testdisk_doc/photorec.html#photorec-file-name-and-date

Das ist also schon richtig, mit der seltenen Ausnahme von Dateien, in 
denen entsprechende Metadaten drinstehen wie Office- oder PDF-Dateien.

Hier geht es aber um SD-Karten, auf denen man sehr oft nur Bilddateien 
vorfindet, die eine Kamera erzeugt hat. Und deren Dateinamen sind nicht 
aus den Metadaten rekonstruierbar.

Lass' die Nebelkerze stecken, solche Beiträge sind hier nicht hilfreich, 
auch Dein (im übrigen falscher) Exkurs über Dateinamenerweiterungen.

Bevor man einen Dateinamen erkennen kann, sollte der Datenträger LESBAR 
sein. Im oben beschriebenen Fall der unlesbaren SD-Karte kommt man schon 
gar nicht bis zum Speicher. Ein totes Pferd kann man nicht reiten.

Peter M. schrieb:
> Nein. Das von Dir erlebte Verhalten ist Mac-spezifisch. Bei
> Microsoft-Betriebssystemen bestimmt die Dateinamenserweiterung, welcher
> Software die Datei übergeben wird.

Linux erkennt den Dateityp auch an der file ›magic‹
BSD soweit ich erinnere auch.
Und das dazu gehörige (primäre) Programm wird über MIME-type ermittelt.

Man sollte wohl eher sagen, das mehrere/viele BS es so machen, jedoch 
nicht Windows. Die machen das seit den Achtzigern einzig an der Endung 
fest und dabei bleibt's wohl auch.

Blöd, dass man sich bei Windows auch das Startmenü und die Taskleiste 
abschießt, wenn man den Explorer killt.

Peter M. schrieb:
> Nein. Das von Dir erlebte Verhalten ist Mac-spezifisch. Bei
> Microsoft-Betriebssystemen bestimmt die Dateinamenserweiterung, welcher
> Software die Datei übergeben wird.
Das ist definitiv nicht Mac spezifisch. Bilddateien, zumindest png und 
jpg speichern keinen Dateinamen. Sie tun das auch nicht wenn sie sich 
auf einem Windowsrechner befinden. Ob Mac bei der Dateierkennung besser 
als Windows ist vermag ich nicht zu beurteilen. Das auf dem Mac 
standardmäßig vorinstallierte Vorschauprogramm ist in dieser Hinsicht 
allerdings sehr gut und öffnet alles was es irgendwie lesen kann.

Peter M. schrieb:
> Zitat:
>
> [...
> Using metadata information embedded in the recovered file, the file may
> be renamed to include the documentation title (example, Microsoft Office
> doc/xls/ppt or Acrobate pdf files) like recup_dir.1/
> f0016741_Prudent_Engineering_Practice_for_Cryptographic_Protocols.pdf.
> ...]
Dein Zitat bezieht sich auf die typischen Officedateien. Dort mag das 
durchaus anders sein - das habe ich auch nie bestritten. Officedateien 
sind ja mittlerweile auch keine reinen Binärdateien mehr sondern es sind 
eigentlich gepackte Archive, ich meine sogar im ZIP format - ich mußte 
mich mit dem Dateiformat eine zeitlang intensiver auseinandersetzen, ist 
aber auch schon wieder eine Weile her.

Peter M. schrieb:
> Nein. Das von Dir erlebte Verhalten ist Mac-spezifisch. Bei
> Microsoft-Betriebssystemen bestimmt die Dateinamenserweiterung, welcher
> Software die Datei übergeben wird.
Ja aber nur dann wenn Du diese mit einem Doppelklick im Explorer öffnen 
willst - ist in anderen System auch so. Wenn man die Datei dem dafür 
vorgesehenen Programm direkt übergibt wird die Extention nicht benötigt.
Mache selber den von Dir beschriebenen Test und öffne die Datei im 
Texteditor mit "Datei öffnen".

Nemopuk schrieb:
> Blöd, dass man sich bei Windows auch das Startmenü und die Taskleiste
> abschießt, wenn man den Explorer killt.

Der "Task Manager" bietet dafür die Möglichkeit, einen neuen Explorer 
aufzurufen.
"Datei->Neuen Task ausführen" und da einfach "explorer" angeben.

Norbert schrieb:
> Linux erkennt den Dateityp auch an der file ›magic‹

Harald K. schrieb:
> Der "Task Manager" bietet dafür die Möglichkeit, einen neuen Explorer
> aufzurufen.

Niedlich. Ich dachte über Grundlagen sind wir hinaus.

Alexander schrieb:
> Ich dachte über Grundlagen sind wir hinaus.

Du nicht, wie Du erfolgreich an schon verschiedenen Stellen im Forum 
anfänglich sehr lautstark bewiesen hast. Ich sag' nur "acht".

Harald K. schrieb:
> Ich sag' nur "acht".

Damit kann keiner etwas anfangen außer Dir.

Das glaubst Du.

Wie viele Bits braucht man, um von 0 bis 8 zu zählen?

Eben.

acht Kästen?

Acht Kästen Bier sind vielleicht etwas viel, um sich den nötigen 
Gemütszustand anzusaufen, aber definitiv gründlich.

Frank O. schrieb:
> Das waren Karten (gleicher Einkauf) die in meinem Mobiltelefon waren.
> Zunächst verschwanden immer wieder irgendwelche Bilder und dann waren
> die überhaupt nicht mehr lesbar.
> Die waren ziemlich günstig, um nicht billig sagen zu müssen. Da mir die
> Bilder nicht wichtig sind, die anderen Daten eh auf dem Telefon sind,
> ist der einzige Verlust die Karten selbst, die Zeit und die zusätzlich
> gekauften Lesegeräte.
> Hätte ich auch gleich bessere Karten kaufen können.

Ich hab die Erfahrung gemacht dass sich sowas immer rächt.
Wenn schon billig dann sollte man zumindest prüfen ob sie bei Start 
überhaupt in der Lage sind zu funktionieren.
Zwei Notfälle die bei mir auf den Tisch kamen waren schlichtweg 
Fälschungen und gaukelten die Speicherkapazität nur vor.

Daher als Empfehlung:
Karten/Sticks immer bei Inbetriebnahme prüfen.

Empfehlenswert ist für einen schnellen Test validrive.
https://www.grc.com/validrive.htm

Oder natürlich heise's H2testw

Die funktionierten die erste Zeit problemlos.

Frank O. schrieb:
> Die funktionierten die erste Zeit problemlos.

Klar, bis sie voll waren, danach wird irgendwo hingeschrieben. 
1TB-Karten sind nicht billig und wen  sie doch billig sind, steht zwar 
1TB drauf aber drinnen ist irgendwas kldineres.

Waren 2TB und unter 18%.

Eine qualitative SD hat Over-Provisioning von Faktor 1.3x bis 2x an 
physischem Speicher für Wear-Leveling und Bad-Block-Management. Billige 
Karten oft nur 1-3 %

Alexander schrieb:
> Eine qualitative SD hat Over-Provisioning von Faktor 1.3x bis 2x an
> physischem Speicher für Wear-Leveling und Bad-Block-Management.

Ich wäre sehr an einer mit 2× Over-Provisioning interessiert.
Wärst du so freundlich eine zu nennen? Nur eine. Eine einzige.

Für mobile MicroSD reicht Industrial Grade, Enterprise-SSDs gibt es 
meines Wissens nicht als MicroSD.

Frank O. schrieb:
> Waren 2TB und unter 18%.

2-TB-SDXC-Karte vom Billigheimer?

Bedenkt man, daß hier 
(https://preisvergleich.heise.de/?cat=sm_sdhc&sort=p&promode=true&xf=298_SDXC) 
gerade mal eine einzige SDXC-Karte dieser Kapazität gelistet ist, ist 
eine gewisse Argwohn gerechtfertigt.

Was hat denn Deine Karte beim Billigheimer gekostet?

Alexander schrieb:
> Für mobile MicroSD reicht Industrial Grade

Nein, nein, du erwähntest explizit SD mit 2× Overprovisioning.
Und speziell daran wäre ich interessiert. Egal ob normal, mini oder 
micro.

Also zB. eine 1GB Karte, welche ein weiteres, zusätzliches, unsichtbares 
Gigabyte nur für interne Zwecke verwendet.

Hersteller und Typ würden mir reichen. Danke.

Norbert schrieb:
> zB. eine 1GB Karte

Norbert, diese Kartengröße GB war im letzten Jahrtausend aktuell und 
teuer. Heute würde ich trotzdem teure große TB-SD möglichst vermeiden, 
denn kein kluger Bauer legt alle Eier in EINEN Korb!

Lu schrieb:
> diese Kartengröße GB war im letzten Jahrtausend aktuell und
> teuer. Heute würde ich trotzdem teure große TB-SD möglichst vermeiden,
> denn kein kluger Bauer legt alle Eier in EINEN Korb!

Ähhhh, ja. Danke. Bin auch schon ein paar Monde im IT Business.

Ich habe mich ganz gewiss schlecht ausgedrückt.

Ich hätte gerne gewusst, welche Firma eine SD Karte mit 
2×Overprovisioning unter welcher Typenbezeichnung anbietet.
Alexander hatte eine solche ja beschrieben.

Harald K. schrieb:
> Was hat denn Deine Karte beim Billigheimer gekostet?

Weiß ich nicht mehr.

Norbert schrieb:
> Ich hätte gerne gewusst, welche Firma eine SD Karte mit
> 2×Overprovisioning unter welcher Typenbezeichnung anbietet.
> Alexander hatte eine solche ja beschrieben.

Hmm, wie komm ich da jetzt wieder raus. Dateisysteme. ext4 kennt die 
NAND-Geometrie nicht und schreibt "Hello World" in einen 4 KiB Block. 
Der FTL muss sich kümmern und schreibt eine ganze Page atomar. Die 
Pagegröße ist 8 KiB + 436 Byte OOB. Du hast also mit 4376 Bytes (4096 
Datenblock + 256 Inode + 24 Directory-Entry) schon 8628 Bytes im 
NAND-Flash belegt, das entspricht Faktor 1.97 OP.

Alexander schrieb:
> Hmm, wie komm ich da jetzt wieder raus.

Da kommst du gar nicht raus! ;-)

Keine mir bekannte Firma auf diesem Planeten würde freiwillig die 
DOPPELTE Menge an Flash hineinstecken, nur für Overprovisioning.

Der ganze Rest den du beschreibst, ist in diesem Zusammenhang völlig 
uninteressant, da wir über Block-Layer und nicht zwei Etagen darüber 
sprechen.

War ein Versuch. Ich bin mir aber so vom Gefühl her sicher dass im 
Automotive oder Raumfahrtbereich Speicher mit 100% OP eingesetzt werden 
wird (außer bei Tesla)

https://embeddedartistry.com/fieldatlas/case-study-teslas-misapplication-of-wear-leveling

Alexander schrieb:
> War ein Versuch. Ich bin mir aber so vom Gefühl her sicher dass im
> Automotive oder Raumfahrtbereich Speicher mit 100% OP eingesetzt werden
> wird (außer bei Tesla)

Das muss der Speicher nicht können. Das richtet man selbst ein.
Wenn man auf einem 2GB Medium die Nutzung nur auf einen 1GB Bereich 
beschränkt (zB. mittels Partitionierung), dann hat man das Gleiche 
bewerkstelligt. Nämlich immer und zu jeder Zeit 1GB frei verfüg- und 
beschreibbaren Speicher (oftmals in Erase-Blocks à 2MiB unterteilt).
Selbst wenn die 1GB Partition zu 99% gefüllt ist. Für nahezu perfektes 
Wear-Leveling.
Je nach extremer Schreiblast kann man das auch noch beliebig weiter 
treiben.

Michael L. schrieb:
>> Die funktionierten die erste Zeit problemlos.
> Klar, bis sie voll waren, danach wird irgendwo hingeschrieben.
> 1TB-Karten sind nicht billig und wen  sie doch billig sind, steht zwar
> 1TB drauf aber drinnen ist irgendwas kldineres.

Es gibt noch Dinge außerhalb Deines Horizontes!

Ich hatte ein paar deutlich kleinere SD von Pollin, die tatsächlich 
hatten was draufsteht. Es hat nur eine überschaubare Menge Schreibzyklen 
gedauert, bis die defekt waren.

Also keine gefakte Kapazität, sondern Speicher aus dem Mülleimer 
irgendeines Speicherpfuschers verbaut.

Frank O. schrieb:
>> Was hat denn Deine Karte beim Billigheimer gekostet?
> Weiß ich nicht mehr.

Gemeinsam mit 2TB riecht das heftig nach verwirrter Erinnerung.

Norbert schrieb:
> Nämlich immer und zu jeder Zeit 1GB frei verfüg- und
> beschreibbaren Speicher (oftmals in Erase-Blocks à 2MiB unterteilt).
> Selbst wenn die 1GB Partition zu 99% gefüllt ist. Für nahezu perfektes
> Wear-Leveling.

Es wird bezweifelt, dass alle Karten ein vernünftiges Wear-Leveling 
betreiben, ebenso wie es auch bei SSD-Controllern Untreschiede gibt.

Manfred P. schrieb:
> Wear-Leveling

Das Wear-Leveling bzw. die Verschleiß-Nivellierung ist eine anerkannte 
Technik. Wenn sie jedoch nicht funktionieren sollte, sind die Daten 
trotzdem weg. Es wäre dann nur zu klären, ob der Controller oder der 
Speicher fehlerhaft war. Irgendwo wird ja auch gespeichert, wie oft 
ein Speicher benutzt wurde. Ob das schon der wunde Punkt ist? Ein Brett 
bricht meist an der dünnsten Stelle.

Alexander schrieb:
> Hmm, wie komm ich da jetzt wieder raus. Dateisysteme. ext4 kennt die
> NAND-Geometrie nicht und schreibt "Hello World" in einen 4 KiB Block.
> Der FTL muss sich kümmern und schreibt eine ganze Page atomar. Die
> Pagegröße ist 8 KiB + 436 Byte OOB. Du hast also mit 4376 Bytes (4096
> Datenblock + 256 Inode + 24 Directory-Entry) schon 8628 Bytes im
> NAND-Flash belegt, das entspricht Faktor 1.97 OP.

Was hat der Speicherbedarf eines Dateisystems mit Overprovisioning zu 
tun?

Peter M. schrieb:
> Was hat der Speicherbedarf eines Dateisystems mit Overprovisioning zu
> tun?

WENN z.B. nur ein Zeichen geändert wird, wird der ganze Block neu 
geschrieben. Das heißt, es werden mehr Speicherzellen benutzt als 
eigentlich nötig. Üblicherweise fällt das nicht auf bei gutem und 
ausreichend viel freiem Speicher.

Peter M. schrieb:
> Was hat der Speicherbedarf eines Dateisystems mit Overprovisioning zu
> tun?

acht

Lu schrieb:
> Peter M. schrieb:
>> Was hat der Speicherbedarf eines Dateisystems mit Overprovisioning zu
>> tun?
>
> WENN z.B. nur ein Zeichen geändert wird, wird der ganze Block neu
> geschrieben. Das heißt, es werden mehr Speicherzellen benutzt als
> eigentlich nötig. Üblicherweise fällt das nicht auf bei gutem und
> ausreichend viel freiem Speicher.

Wenn man – völlig ohne Dateisystem — ein einzelnes Bit in einem 
beliebigen Block ändert, dann wird dieser Block ebenfalls neu 
geschrieben.

Overprovisioning ist völlig unabhängig davon. Es garantiert, dass immer 
und zu jederzeit eine hinreichend große Menge an freien Erase-Blöcken 
verfüg- und einsetzbar ist, so dass ein Wear-Leveling Mechanismus 
vernünftig damit arbeiten kann.

Hallo Alexander,

Alexander schrieb:
> Eine qualitative SD hat Over-Provisioning von Faktor 1.3x bis 2x an
> physischem Speicher für Wear-Leveling und Bad-Block-Management. Billige
> Karten oft nur 1-3 %

mich interessiert auch, welche "qualitative SD" so viele Reservesektoren 
dabei hat.
Fallst Du keine finden kannst, dann nenne doch die Quelle für Deine 
Aussage.

Ich frage deshalb, weil ein solches Produkt komplett überflüssig ist, 
weil sich das dasselbe Ergebnis (Over-Provisioning mit Faktor 2) auch 
auf simpelste Weise selbst herstellbar ist, siehe:

Norbert schrieb:
> Das muss der Speicher nicht können. Das richtet man selbst ein.
> Wenn man auf einem 2GB Medium die Nutzung nur auf einen 1GB Bereich
> beschränkt (zB. mittels Partitionierung), dann hat man das Gleiche
> bewerkstelligt.

Die Quelle bin ich. Du darfst mich gern referenzieren.

https://www.mikrocontroller.net/topic/goto_post/7934106

Ich will nochmal betonen, wes mich so geärgert hat.

Dass ein defekter Datenträger nicht gelesen werden kann ist zwar 
ärgerlich, aber kommt halt vor.

Was mich aber regelrecht wütent macht, ist die Tatsache, dass die 
Programmierer es nicht fertig gebracht haben, einfach eine Meldung 
auszugeben: "Datei (oder Datenträger) defekt, kann nicht gelesen 
werden." und gut ist ...

Nein, sondern dass sich die Tools oder Prozesse auf erbärmliche Weise 
festfressen. Ich bin mir ziemlich sicher das ginge auch anders, wenn man 
es nur wollte.

Ich hatte übrigens vor mehreren Jahren mal ein freies Windows-Tool 
gefunden, leider den Namen vergessen, dass genau das konnte: Dateien 
kopieren, ohne sich an Defketen aufzuhängen. Braucht man nur zu selten 
...

Norbert schrieb:
> Für nahezu perfektes Wear-Leveling.

Deswegen wird vielfach geraten, die Speicher von SSD, USB Sticks und 
Smartphones nur bis maximal 75% zu befüllen.

Nemopuk schrieb:
> nur bis maximal 75% zu befüllen.

Irgend jemand oder irgend etwas muss sich ständig und vor allem 
sorgfältig darum kümmern. So etwas funktioniert ja besonders gut bei 
wenig bis gar nicht technik-affinen Menschen.

Wohingegen Overprovisioning so aussieht:
Einmal vorher nachdenken und einrichten.
Eine »Datenträger voll« (oder fast voll) Nachricht versteht wirklich 
jeder.
Gut, Datenträger vielleicht nicht, aber »voll«…
Und Wear-Leveling funktioniert dann natürlich immer noch perfekt.

Nemopuk schrieb:
> Norbert schrieb:
>> Für nahezu perfektes Wear-Leveling.
>
> Deswegen wird vielfach geraten, die Speicher von SSD, USB Sticks und
> Smartphones nur bis maximal 75% zu befüllen.

als wenn SD Karten dieses machen, sie werden einfach totgeschrieben, im 
Raspi bei swap!

Swap auf einer SD ist an sich ja schon Nonsens. Dass ein Raspberry eine 
SD Karte schrotten soll ist mir nicht zu Ohren gekommen, kurze Suche 
bestätigt aber meine Meinung das waren einfach billige SD Karten.

https://www.reddit.com/r/RASPBERRY_PI_PROJECTS/comments/13vl024/raspberry_pi_destroying_micro_sd_card

Joachim B. schrieb:
> als wenn SD Karten dieses machen, sie werden einfach totgeschrieben, im
> Raspi bei swap!

Alexander schrieb:
> Swap auf einer SD ist an sich ja schon Nonsens.

Interessant! Das wusste ich nicht!

Diese 8GB SD (kurz nach Beginn der Kreidezeit mit dem RaspberryPi 1B 
gekauft und für gut ein Jahrzehnt im Dauereinsatz) wusste das übrigens 
auch nicht. Sonst hätte sie sich bestimmt daran gehalten.

Partitionierung:
* 256MB für das Raspi Boot
* 6GB für /
* Rest für swap

Na da haben wir beide ja noch einmal Glück gehabt.
Oder es lag daran, dass irgend ein ungenannt bleibender Künstler gleich 
bei der Einrichtung das swap Verhalten genau passend konfiguriert hat.
Das soll bei Linux wohl völlig problemlos machbar sein.

Wer weiß das schon, man steckt halt nicht drin. ;-)

Norbert schrieb:
> Interessant! Das wusste ich nicht!

Tröste dich, damit bist du nicht alleine. Dafür weißt du vermutlich von 
/proc/sys/vm/swappiness und davon, dass „swap vorhanden“ nicht bedeutet 
dass ohne Not überhaupt drauf geschrieben wird. Das zu wissen, ist ja 
auch schon was, nicht wahr? :)

Jack V. schrieb:
> Norbert schrieb:
>> Interessant! Das wusste ich nicht!
>
> Tröste dich, damit bist du nicht alleine. Dafür weißt du vermutlich von
> /proc/sys/vm/swappiness und davon, dass „swap vorhanden“ nicht bedeutet
> dass ohne Not überhaupt drauf geschrieben wird. Das zu wissen, ist ja
> auch schon was, nicht wahr? :)

Du kannst doch jetzt nicht einfach alle Geheimnisse verraten!

Da bleibt doch gar kein Spielraum mehr für die vielen unbewiesenen 
Theorien, welche sich im Laufe des Lebens angesammelt haben.
In die konnte man sich immer so schön komfortabel einwickeln, wie in 
eine warme Decke.

Wie schnell schreibt ein Raspberry Pi ins RAM? Wie schnell ist Deine 
SanDisk Extreme SDHC UHS-I Class 10 U1 A1?

Alexander schrieb:
> Wie schnell schreibt ein Raspberry Pi ins RAM? Wie schnell ist Deine
> SanDisk Extreme SDHC UHS-I Class 10 U1 A1?

Das ist aus folgendem Grund nicht relevant: Solange RAM verfügbar ist, 
wird der genutzt, und bei entsprechend eingestellter Swappiness wird 
Swap nicht einmal angerührt. Es macht daher in dem Fall überhaupt keinen 
Unterschied, ob und wieviel Swap vorhanden ist.

Erst, wenn der RAM voll ist, und je nach eingestellter Swappiness meint 
„voll“ auch „nix mehr verfügbar“, wird ausgelagert. Das ist der Zustand, 
in dem ein Pi ohne Swap erstmal eine Weile völlig unbedienbar wäre, bis 
der OOM-Killer sich bequemt, einen mehr oder weniger beliebigen Prozess 
abzuschießen – oft genug nach Minuten, und dann oft genug nicht den, der 
sinnvollerweise abgeschossen werden sollte. Ein Pi mit Swap wird hier 
durch die geringere Geschwindigkeit einer SD-Karte im Vergleich zu RAM 
lediglich langsamer, bliebe aber bedienbar. Der Pi ohne Swap hingegen 
nicht.

Und zur Sicherheit nochmal: Im normalen Betrieb sind beide, der Pi mit 
Swap und der ohne Swap, absolut gleichschnell.

Ich sag ja: Nonsens. besser ZRAM

Achso … sorry, ich ging nun davon aus, dass du genügend Grundkenntnisse 
besäßest, um hier folgen zu können. Tut mir leid, dass du nun dumm 
dastehst :(

Ich kenne den Nonsens zu Genüge, habe das zu Gingerbread Zeiten selbst 
fabriziert.

Alexander schrieb:
> Ich sag ja: Nonsens. besser ZRAM

Du hast aber schon gelesen, dass es um einen Rpi 1B ging?
Oder meinst du vielleicht zram? Oder gar zswap?
Mit ¼GiB RAM. Und einem einzigen Kern.
Und da willst du mit RAM-compression arbeiten?

Und schon bin ich wieder gespannt wie ein Flitzebogen.

Beitrag "Re: Raspberry Pi langlebigere SD-Karte, wie?"

Schau Dir die Spezifikationen meines GT-S6102 an und sag mir was alles 
nicht geht.

Du bootest das alte Telephon von SD und/oder bindest Swap von dort ein? 
Erzähl’ bitte mehr!

Abgesehen davon mutet es etwas fragwürdig an, wenn du dich bei einer 
Diskussion bezüglich der Konfiguration eines Pi, den eher wenige Leute 
mit Android betreiben, mit deinen vermeintlichen Android-Kenntnissen 
profilieren willst.

Es ging hier nur um einen Schwanzvergleich. Das Telefon hat 290MB RAM 
also erzähl mir warum ZRAM auf dem 1B nicht funktionieren soll. Swap auf 
SD ist einfach mal nur dämlich!

Alexander schrieb:
> erzähl mir warum ZRAM auf dem 1B nicht funktionieren soll.

Ich hab nicht gesagt, dass es nicht funktionieren würde. Es hat nur mit 
der Diskussion um Swap rein überhaupt nichts zu tun, weil’s etwas völlig 
Anderes ist.

Es würde zudem wenig bringen, stattdessen würde es den einzigen 
Prozessorkern so auslasten, dass neben größeren Speicherzugriffszeiten 
auch rein auf der CPU ablaufende Sachen ausgebremst werden.

Es ist eine Alternative, und zwar die bessere! Anleitungen für ZRAM auf 
dem Raspberry Pi findest Du genug. Lies eine, in jeder steht der Bezug 
zur Diskussion (swap auf SD = wear-out)

Alexander schrieb:
> Das Telefon hat 290MB RAM
> also erzähl mir warum ZRAM auf dem 1B nicht funktionieren soll.

Eigentlich ist das zwar mittlerweile fürchterlich langweilig, aber:

Android/Java funktioniert ANDERS. Apps werden bei Speichermangel 
weggeschmissen und nur die momentanen Daten im RAM gehalten.
Dann startet die nächste App und das gleiche Spiel passiert. Bei Wechsel 
dann wieder zurück.
Der RAM Bedarf ist so deutlich niedriger, auf Kosten einer immens 
ansteigenden Lade- und Startzeit.
Was bei einem von einem Menschen bedienten Schmartfone völlig egal ist.

Auf einen Linux System hingegen laufen Prozesse wie Webserver, SSH 
Server, usw. im preemptive Multitasking. Die kann man nicht 200× pro 
Sekunde wegschmeissen und neu starten.

Der LMK/lmkd ist etwas aggressiver als OOM. Android ist ja auch kein 
Linux. Die wear-out Problematik ist die gleiche. Bei deiner Anwendung 
reichen vermutlich statt 1.2GB swap schon 48MB ZRAM.

Alexander schrieb:
> Bei deiner Anwendung reichen
> vermutlich statt 1.2GB swap schon 48MB ZRAM.

Ich bin dir weit über alle Grenzen menschlichen Vorstellungsvermögens 
hinaus dankbar, dass du dir die Zeit nimmst, den RAM Bedarf meiner dir 
unbekannten Anwendungen aus der Ferne zu analysieren und mir zudem auch 
noch all diese wertvollen Empfehlungen zur Systemkonfiguration gibst.

Da war noch etwas … ach ja: Plonk!

Alexander schrieb:
> Es ist eine Alternative, und zwar die bessere

Entschuldige, aber nein – nicht im Ansatz. Allerdings hast du bereits 
dargelegt, dass du der Argumentation nicht zu folgen vermagst – siehe 
z.B. deine wiederholte, unzutreffende Behauptung, dass Swap allein durch 
seine Existenz per se den Datenträger abnutzen würde. Unzutreffend, 
weil, wie dargelegt, im Regelbetrieb bei entsprechender Konfiguration 
gar nicht drauf geschrieben wird.

Und da dir der Sinn und die Funktionsweise von Swap auch gar nicht so 
richtig klar zu sein scheinen (du scheinst zu glauben, dass es schlicht 
den RAM erweitert, oder so?) sollten wir’s vielleicht auch dabei 
belassen.

Vorhin schrieb ich noch, dass es mir leid täte, dass du nun dumm 
dastehen würdest – das meinte ich zu dem Zeitpunkt auch so. Aber 
mittlerweile denke ich: Wer sich mit Gewalt öffentlich so darstellen 
möchte, der soll’s halt tun :)

Ja. Lass gut sein.

Jack V. schrieb:
> Und da dir der Sinn und die Funktionsweise von Swap auch gar nicht so
> richtig klar zu sein scheinen (du scheinst zu glauben, dass es schlicht
> den RAM erweitert, oder so?) sollten wir’s vielleicht auch dabei
> belassen.

Ich glaube mittlerweile, dass wenn man mit einem Betriebssystem 
sozialisiert wurde welches ohne ein Pagefile in der Größe des Great Bear 
Lake sich sofort kotzend in den Orkus verabschiedet, dann kommt man auf 
solche Ideen.

Norbert schrieb:
> Ich bin dir weit über alle Grenzen menschlichen Vorstellungsvermögens
> hinaus dankbar, dass du dir die Zeit nimmst, den RAM Bedarf meiner dir
> unbekannten Anwendungen aus der Ferne zu analysieren

Der RAM Bedarf ist zumindest so niedrig dass Du keinen swap Bedarf hast.

Norbert schrieb:
> Jack V. schrieb:
>> Tröste dich, damit bist du nicht alleine. Dafür weißt du vermutlich von
>> /proc/sys/vm/swappiness und davon, dass „swap vorhanden“ nicht bedeutet
>> dass ohne Not überhaupt drauf geschrieben wird.
>
> Du kannst doch jetzt nicht einfach alle Geheimnisse verraten!

Norbert schrieb:
> Feste Blöcke. Pro Di,Do,Sa jeweils von 30-50 Geräten á16MiB (12MiB
> Nutzdaten + 4MiB FEC mit Reed-Solomon codes für Paranoide und
> Prüfsummen)
> Also 1440MiB … 2400MiB pro Woche (oder ~~ jeden Monat einmal komplett
> beschreiben)

Norbert schrieb:
> Du hast aber schon gelesen, dass es um einen Rpi 1B ging?

nicht nur bis Raspi 2 und 3 mit OSMC und alle nutzen die geschaute 
Mediendatenbank und schreiben rein was schon geschaut wurde bis Kodi 17.
Kaputt geschrieben wurden Samsung (µ)SD, die Transcend die in meiner Cam 
NIE Probleme machten konnten mit RASPBMC/KODI/OSMC nie zum arbeiten 
bewegt werden.

Komischerweise, ist die eine Samsung µSD am PI2 wieder aufgewacht, 
irgendwie hat sie sich wieder berappelt. Ich habe immer noch den Plan 
die Mediadatenbank aufs NAS auszulagern, aber ist mir bis jetzt zu viel 
Aufwand, NAS einrichten VNC einrichten OSMC Kodi einrichten mit der 
alten Bedienoberfläche inclusive REMOTE, solange es funktioniert, kein 
Bock.

Hans schrieb:

> Peter M. schrieb:
>> Nein. Das von Dir erlebte Verhalten ist Mac-spezifisch. Bei
>> Microsoft-Betriebssystemen bestimmt die Dateinamenserweiterung, welcher
>> Software die Datei übergeben wird.
> Ja aber nur dann wenn Du diese mit einem Doppelklick im Explorer öffnen
> willst - ist in anderen System auch so. Wenn man die Datei dem dafür
> vorgesehenen Programm direkt übergibt wird die Extention nicht benötigt.
> Mache selber den von Dir beschriebenen Test und öffne die Datei im
> Texteditor mit "Datei öffnen".

Was soll das zeigen?
Das hängt doch ganz vom verwendeten Editor ab.

Jens B. schrieb:
> Was soll das zeigen?
Das soll zeigen, das der Peter mit seinem Statement zu den Extensionen 
daneben liegt.

Die Programme brauchen die Extensionen nicht. Einzig und allein das OS 
oder besser dessen Dateimanagement benötigt diese, um die Datei Dateien 
den zugehörigen Programmen zuordnen zu können ohne die Datei erst öffnen 
zu müssen und rein zu schauen.

Ansonsten kannst Du die Enxtentions auch beliebig verknüpfen. Wenn Du 
der Meinung bist alle Dateien sollen mit unter Windows mit Notepad 
geöffnet werden, dann machst Du halt eine Verknüpfung zwischen der 
jeweiligen Extention und Notpad und schon öffnet Notpad die Datei bei 
einem Doppelklick im Explorer. Ob man dann was Vernünftiges sieht ist 
eine andere Frage, aber prinzipiell geht das.
Unter Linux geht das ganz genauso. Da kannst Du in der grafischen 
Oberfläche jeden Dateityp mit einem Editor Deiner Wahl verknüpfen. Wie 
gesagt die Sinnhaftigkeit dieses Tund ist eine andere Frage.

Jens B. schrieb:
> Das hängt doch ganz vom verwendeten Editor ab.
Nö, dem Editor ist es völlig egal welche Datei er öffnet.

Ich hab jetzt nicht den ganzen thread gelesen, kenne aber das (oder ein 
ähnliches) Problem und eine Lösung (zumindest für meins):
wenn ich eine SD-Karte mit mehreren Linux-Partitionen (vom raspi zB) in 
den internen leser meines Laptops packe, spackt windows. Die 
Datenträgerverwaltung läd nicht und blockiert komplett, bis ich die 
Karte wieder raus ziehe.

Mit einem externen USB-SD-Karten-Leser ists kein Problem

Hans schrieb:

> Bevor man hier irgend eine Aktion macht, versucht man erst mal eine
> Kopie des defekten Datenträgers zu erstellen. Das macht man am Besten
> mit (GNU) ddrescue. Das allseits beliebte dd versagt hier oftmals, weil
> es bei Lesefehlern abbricht und dann unbrauchbare Images erzeugt.

Ja.

> Danach versucht man mit einem geeigneten Tool die Datenrettung vom
> Orginaldatenträger.

Nein.

Warum isoliert man dann mittels einer ddrescue-Kopie alle Lesefehler, um 
dann mit erneuten Zugriff auf den Defektdatenträger diesen noch weiter 
zu ruinieren und sich trotz nun vorhandener physikalisch! intakter Kopie 
nochmals der Zeitverzögerung durch unlesbare Sektoren auszusetzen, wenn 
man doch eine lesefehlerfreie Kopie hat?

Oh, weh.