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.
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!
:
Bearbeitet durch User
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 ...
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
Angehängte Dateien:
-
otg-usb-adapter.jpg
82 KB
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.
:
Bearbeitet durch User
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!
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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".
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
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.
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.
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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 ...
:
Bearbeitet durch User
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!
:
Bearbeitet durch User
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
Angehängte Dateien:
-
20250907_173748.jpg
74 KB
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
Beitrag "Re: Raspberry Pi langlebigere SD-Karte, wie?" Schau Dir die Spezifikationen meines GT-S6102 an und sag mir was alles nicht geht.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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!
:
Bearbeitet durch User
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)
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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 :)
:
Bearbeitet durch User
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)
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.