Ein Bekannter gab mir eine nicht mehr lesbare SD-Karte aus einer Digitalkamera mit der Bitte, die Bilder zu retten.
Zunächst versuchte ich es ohne extra Software, einfach über das Dateisystem.
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".
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. Dass solche Leseversuche ihre Grenzen haben, ist mir auch klar, aber sich einfach "aufhängen"?
Wo sind wir nur hingeraten :-)
Ernsthaft: Noch ne Idee, wie ich das Problem lösen könnte? Danke.
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!
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.
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 ...
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)...
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).
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.
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ß ...
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.
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.
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.
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.
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.
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.
Ich habe es auch mittlerweile aufgegeben.
Die sind definitiv kaputt.
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 :-)
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.
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.
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.
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?
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.
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.
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.
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.
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.
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:
[...
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.
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".
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.
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.
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.
[...
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.
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".
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.
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.
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 %
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!
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.
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.
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)
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.
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.
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.
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.
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?
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.
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.
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:
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.
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 ...
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.
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.
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. ;-)
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? :)
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?
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.
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.
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!
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)
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.
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.
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 :)
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.
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.
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!
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)
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.
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.
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.
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
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?
