Kopieren von Dateien fehlerhaft

[zapman]

Hallo!

ich habe neulich den gesamten Inhalt ein SD Karte (ca 7gb auf 16bg Karte, FAT32, 'exrememory' von EDs shop) auf eine 2. Karte (32gb, FAT32, takeMS Karte) per Thunar kopiert (Zaxxon, HF3). Nach beenden des Kopiervorgangs hab ich noch n paar Minuten gewartet, das folgende Problem wird also nichts mit nem gecancelten Writebuffer zu tun haben.

Mir ist aufgefallen, dass mind. 3 sehr große Dateien (~500mb: die .pk3 von quake3, die .pk0 von quake2, ein CD.iso mit 700mb) auf der 32GB Karte deutlich kleiner sind als vorher: sie haben nur noch ca. 30mb. Natürlich kann man mit denen nix mehr anfangen. Ein Kopierfehler wurde mir in Thunar nicht gemeldet.

Außerdem tauchen einige Spiele nun nicht mehr im Startmenü auf, weil sie wohl ebenfalls beim kopieren korrupted wurden. Die Dateien sind aber prinzipiell da (keine Ahnung wie groß die vorher waren).


Hat jmd ähnlich Probleme? Funktioniert bei Euch das Kopieren von einem SD Slot auf den Anderen problemlos? Was ist mit großen (>700mb) Dateien?

Edit:
Battle for Wesnoth hatte mal 299MB und lief einwandfrei, nach dem rumkopieren hat es noch 193MB und das .pnd funst nicht mehr...
Habe das kaputte 193MB file nochmals von der 16GB Karte auf die 32GB Karte kopiert. Diesmal bekomme ich tatsächlich Fehlermeldungen:

Failed to read data from /media/SD_16gb/pandora/menu/wesnoth_1.8.3-1.pnd (Input/output error)

Dann werde ich gefragt, ob ich das file skippen will. Wähle ich 'retry', dann versucht ers halt nochmal, bleibt aber dann an anderer Stelle mit dem gleichen Fehler wieder hängen. Bei 5 Versuchen schafft er so zwischen 30 und 70MB bevor der IO Fehler kommt.
Karte putt? OS mit bug? Reader putt? Läuft das bei Euch alles glatt?

 

[fusion_power]

Das würde mich auch mal interessieren, ein File-Manager MUSS funktionieren, ohne Kompromisse. Wenn du die Operation am PC ohne Fehler durchführen kannst (SDs also OK sind) dann hat die Pandora offenbar massive Probleme beim kopieren, eventuell Prozessor überlastet, Buffer-Underruns...irgend was um den dreh rum. Hoffe das kann man fixen, auf kopieren MUSS verlass sein, ohne Kompromisse.

 

[docno]

Also ich habe in der Richtung noch nichts beobachtet; zugegeben kopiere ich eigentlich auch keine 100e von MBs oder gar GBs durch die Gegend.
Ich würde mal ein fsck mit der Karte vorschlagen.

Greets

 

[Anonymous]

ich habe neulich den gesamten Inhalt ein SD Karte (ca 7gb auf 16bg Karte, FAT32, 'exrememory' von EDs shop) auf eine 2. Karte (32gb, FAT32, takeMS Karte) per Thunar kopiert (Zaxxon, HF3). Nach beenden des Kopiervorgangs hab ich noch n paar Minuten gewartet, das folgende Problem wird also nichts mit nem gecancelten Writebuffer zu tun haben.

Da wäre ich mir nicht so sicher, so große Dateien können durchaus eine lange Zeit benötigen, bis sie fertig kopiert sind. Um ganz sicher zu gehen, könntest Du in einer Shell "sync" aufrufen, dann wird alles, was gecachet ist, auf die Datenträger geschrieben. Das Kommando kehrt erst zurück, wenn alles auf den Datenträgern angekommen ist.

Kann aber auch sein, dass ich Unsinn rede, weil die SD-Karten ohne Cache gemountet werden.

EDIT: vermutlich rede ich Unsinn, habe gerade erst nochmal das mit dem I/O-Error gesehen. Ein Input/Output-Error ist eine recht ernste Sache und hat nichts mit einem kaputten Dateisystem oder einer kaputten Datei zu tun. Also gibt es entweder ein Problem im Kernel oder aber ein Hardware-Problem (wohl eher die SD-Karte selbst). Vielleicht gibt "dmesg" in der Shell Dir ein paar weitere Aufschlüsse.

 

[JohnDavidson]

Ich weiß nicht ob es daran liegt, aber ich hab zB bemerkt, dass beim löschen von der SD Karte, alle gelöschten Dateien auf den NAND gespeichert werden, damit diese im Papierkorb liegen. Ist unsinnig aber das ist anscheinend nen Bug. SO meine Idee wäre jetzt folgende, beim kopieren von SD-A nach SD-B schreibt er erstmal Dateien in den NAND und dann auf die SD-B. Eventuell ist dann der NAND zu klein für manche Dateien und so ergeben sich Fehler.

Aber wie gesagt, dass ist nur eine Vermutung

 

[dingens]

Andere haben das auch schon beobachtet:
http://www.gp32x.com/board/index.php?/topic/55077-looks-like-the-is-a-readtiming-problem-with-sd-reading-when-high-cpu/page__p__888079__fromsearch__1&#entry888079

 

[Anonymous]

Ich weiß nicht ob es daran liegt, aber ich hab zB bemerkt, dass beim löschen von der SD Karte, alle gelöschten Dateien auf den NAND gespeichert werden, damit diese im Papierkorb liegen.

Sicher, dass da nicht nur Verweise angelegt werden? Wenn die Dateien da wirklich kopiert werden, wäre das 1. hirntot und 2. schlecht fürs NAND...

 

[JohnDavidson]

Ich weiß nicht ob es daran liegt, aber ich hab zB bemerkt, dass beim löschen von der SD Karte, alle gelöschten Dateien auf den NAND gespeichert werden, damit diese im Papierkorb liegen.

Sicher, dass da nicht nur Verweise angelegt werden? Wenn die Dateien da wirklich kopiert werden, wäre das 1. hirntot und 2. schlecht fürs NAND...

Joa es gab halt ne Warnung das der Speicher voll sei und der deswegen nicht mehr löschen kann. Als ich dann ein wenig nachgeforscht habe, hab ich gesehen, dass der die Dateien in den NAND schreibt. Und ich hab mich auch zu Anfang so gewundert, warum das löschen so lange gedauert hat

 

[fusion_power]

Interessant. Das "richtige" löschen geht wohl immer noch nicht auf der Pandora, bzw nicht ohne Terminal Eingaben?
Und allgemein fehlts wohl auchan ner richtigen Auslagerungsdatei auf SD Karte? ?? Das Thema gabs glaub schon mal und wenn ich mich recht erinnere hat die Pandora leider keine "echte" Auslagerungsdatei, NAND ist ungünstig und SD geht wohl nicht so leicht. Vielleicht gibts diesbezüglich ja noch Entwicklungen. Für größere Daten währ das schon praktisch, wenn der RAM nicht ausreicht und keine Auslagerungs-Datei da ist, wirds natürlich kritisch.

 

[Christoph.Krn]

Ich weiß nicht ob es daran liegt, aber ich hab zB bemerkt, dass beim löschen von der SD Karte, alle gelöschten Dateien auf den NAND gespeichert werden, damit diese im Papierkorb liegen.

Sicher, dass da nicht nur Verweise angelegt werden? Wenn die Dateien da wirklich kopiert werden, wäre das 1. hirntot und 2. schlecht fürs NAND...

Ein NAND-Speicher ist nicht so schnell ausgenudelt wie viele Leute annehmen.

Realtiv sinnfrei ist das mit dem Verschieben trotzdem.

Interessant. Das "richtige" löschen geht wohl immer noch nicht auf der Pandora, bzw nicht ohne Terminal Eingaben?

Üblicherweise kann man per [Shift]+[Entf] eine markierte Datei endgültig löschen. Vielleicht ist das ja auf der Pandora über die virtuelle Tastatur möglich.

 

[fusion_power]

Üblicherweise kann man per [Shift]+[Entf] eine markierte Datei endgültig löschen. Vielleicht ist das ja auf der Pandora über die virtuelle Tastatur möglich.

Ich hab gelesen, das Shift leider recht komisch belegt ist daher erreicht man mit mit Shift+Entf nix auf der Pandora. Und hat die Pandora überhaupt ne virtuelle Tastatur?
Ich will später keine Verrenkungen machen müssen, um Sachen ordentlich zu löschen, vielleicht fällt ED noch was elegantes ein und kann es später in einen Hotfix packen.

 

[EvilDragon]

Man kann sich Shift (welches gerade mit Fenster verschieben belegt ist) auch wieder freigeben.
Ist eine Einstellung in den XFCE4-Settings (sind im Settings-Menu) und kann dann auch wieder Shift + Entf nutzen.

 

[Christoph.Krn]

Man kann sich Shift (welches gerade mit Fenster verschieben belegt ist) auch wieder freigeben.
Ist eine Einstellung in den XFCE4-Settings (sind im Settings-Menu) und kann dann auch wieder Shift + Entf nutzen.

Heißt das, das ist somit kein Bug und wird keiner Korrektur unterzogen? Das fände ich persönlich aber doof, wenn es im graphischen Dateimanager dann keine alternative Möglichkeit zur direkten Löschung gäbe. :/

 

[zapman]

direktes Löschen von Dateien ohne Umwege über den Papierkorb funktioniert auch über Thunar, also mit der GUI:

Datei rechtsklicken, linke Schultertaste gedrückt halten und dann erst auf "Delete" klicken. So werden files direkt gelöscht.

ED, könntest Du noch was zum eigentlichen Thema sagen? Und wie schauts bei Euch anderen denn jetzt aus? Könnt ihr ohne Probleme 700mb von einer SD Karte auf die Andere kopieren?

-- Fr Jul 30, 2010 11:33 --

Andere haben das auch schon beobachtet:
http://www.gp32x.com/board/index.php?/topic/55077-looks-like-the-is-a-readtiming-problem-with-sd-reading-when-high-cpu/page__p__888079__fromsearch__1&#entry888079

ah, danke für den Link! Werde das Problem dort weiter mit verfolgen.

 

[kkaracho]

Und wie schauts bei Euch anderen denn jetzt aus? Könnt ihr ohne Probleme 700mb von einer SD Karte auf die Andere kopieren?

hab zwar keine großen files kopiert und auch nicht von SD zu SD sondern von USB zu SD
aber letztens hab ich von einem freund ca 2gb mp3 kopiert und das lief einwandfrei, wenn auch etwas lang, die dateien funktionieren aber problemlos
das war noch vor HF3

bis dann
Käptn

 

[zapman]

ja, der IO Fehler tritt wohl nur bei ausreichend großen Dateien auf. Alles unter ~20MB ist bei mir auch kein Problem und scheint zu funktionieren.

Versuchs doch mal mit ner größeren Datei, die wesnoth.pnd z.b.

 

[Anonymous]

ja, der IO Fehler tritt wohl nur bei ausreichend großen Dateien auf. Alles unter ~20MB ist bei mir auch kein Problem und scheint zu funktionieren.

Probier doch mal folgendes in einer Shell: dd if=/dev/zero of=/Pfad zur SD-Karte/bla

Das sollte den gesamten freien Platz der Karte mit einer Datei namens "bla" füllen (bzw. bei Karten >4GB mit einer einer Datei maximaler FAT32-Größe = 4GB, dann kannst Du den Befehl auch mit unterschiedlichen Namen mehrfach ausführen). Eventuell sind nur Teile der Karte defekt und werden erst bei größeren Dateien "erwischt". Ich schätze, dass ab einem bestimmten Füllstand nur noch Fehler kommen und sich auch kleine Dateien nicht mehr hinzufügen lassen. Das wäre ein starker Hinweis auf einen Defekt der Karte.

 

[zapman]

danke für den hinweis grond!

ich habe in englischen Thread ein paar Experimentergebnisse gepostet. Siehe http://www.gp32x.com/board/index.php?/topic/55077-looks-like-the-is-a-readtiming-problem-with-sd-reading-when-high-cpu/page__st__30__gopid__898919&#entry898919

bei mir scheint der Fehler nur aufzutauchen, wenn ich von Slot 1 auf Slot 2 kopiere, unabhängig von der Karte selber..

 

[Anonymous]

bei mir scheint der Fehler nur aufzutauchen, wenn ich von Slot 1 auf Slot 2 kopiere, unabhängig von der Karte selber..

Interessante Ergebnisse! Mach vielleicht trotzdem noch den obengenannten Test. Damit könnte man mal prüfen, ob auch Fehler kommen, wenn nur ein Slot aktiv ist und hinsichtlich seiner Schreibgeschwindigkeit über eine Weile hinweg ausgereizt wird. Insgesamt klingt mir das dann aber stark nach einer Race Condition im Zusammenspiel von Kerneltreiber und spezieller SD-Karte/Cardreader-Kombination. So etwas ähnliches habe ich mal in einem kaputten Festplattentreiber debuggt. Da kam es auch nur bei größerer Auslastung und vor allem gleichzeitigen Schreib- und Lesezugriffen zu Problemen.

 

[zapman]

Probier doch mal folgendes in einer Shell: dd if=/dev/zero of=/Pfad zur SD-Karte/bla

also sowohl für slot 1 (16GB) als auch für slot 2 (32GB) funktioniert das problemlos. Selbst wenn ich beide dds gleichzeitig laufen lasse, bekomm ich keinen Fehler (jeweils ca. 500MB geschrieben). Die Schreibgeschwindigkeit sackt nur sehr stark ab, aber das wird normal sein.