Gnome, Nautilus-Dateien auf USB kopieren stoppt bei 100% oder in der Nähe


29

Ich hatte vorher ähnliche Probleme, aber ich erinnere mich nicht, wie ich es gelöst habe.

Wenn ich versuche, etwas mit FAT auf einen USB-Stick zu kopieren, stoppt es gegen Ende, manchmal bei 100%. Und wenn ich den Memory Stick an einen anderen Ort übertrage, enthält er natürlich keine vollständige Datei. (Datei ist ein Film!)

Ich habe versucht, das Gerät mit mount -o flush zu mounten, aber ich bekomme das gleiche Problem.

Außerdem habe ich den USB-Stick mit einer neuen FAT-Partition formatiert ...

Irgendeine Idee, was ich für eine Erkältung tue?

ps Ich glaube, es hat nichts mit dem Betriebssystem zu tun, das Debian ist, und ich glaube, dass das Kopieren vom SSD-Laufwerk nicht zum Stillstand führt.


3
Irgendwo habe ich folgende Sachverhaltserklärung getroffen. In dem Fall, dass das Kopieren über den Betriebsspeicher erfolgt ist, zeigt der Identifikator den Vorgang des Lesens von Daten vom Laufwerk an. Der Wrighting-Prozess ist jedoch viel länger, insbesondere für USB-Sticks (er kann 100-mal langsamer sein, z. B. 2 MB / Sek. Wrighting gegen 200 MB / Sek. Lesen) und mehr, wenn Sie keine nativen Dateisysteme wie FAT oder NTFS unter Linux verwenden . Versuchen Sie also, auf das Ende der Transaktion zu warten, auch wenn die Transaktion zu 100% gestoppt, aber nicht geschlossen wurde (dies sollte das Ende anzeigen).
Costas

frage mich nur, ob es überhaupt möglich ist, den Fortschritt in dieser Situation zu überprüfen ???

versuchen, Format USB - Stick mit der Option Überschreiben von Daten mit Nullen Verlassen Sie auf My Trancend 8GB USB - Stick funktionieren
Akshay Daundkar

Wenn Sie auf dieses Problem stoßen, formatieren Sie Ihr Laufwerk einfach auf NTFS.
Ricky Boyce

Antworten:


37

Der Grund dafür ist, dass das Programm "Write this data" (Diese Daten schreiben) sagt und der Linux-Kernel sie in einen Speicherpuffer kopiert, der sich in der Warteschlange befindet, um auf die Festplatte zu gelangen, und dann "ok, done" sagt. Das Programm glaubt also, alles kopiert zu haben. Dann schließt das Programm die Datei, aber plötzlich lässt der Kernel sie warten, während dieser Puffer auf die Festplatte verschoben wird.

Leider kann das Programm Ihnen nicht sagen, wie lange es dauern wird, den Puffer zu leeren, da es nicht weiß.

Wenn Sie einige Power-User-Tricks ausprobieren möchten, können Sie die Größe des Puffers, den Linux verwendet, verringern, indem Sie den Kernel-Parameter vm.dirty_bytesauf etwa 15000000(15 MB) setzen. Dies bedeutet, dass die Anwendung nicht mehr als 15 MB vor ihrem eigentlichen Fortschritt haben kann. (Sie können die Kernel-Parameter im laufenden Betrieb ändern. sudo sysctl vm.dirty_bytes=15000000Damit sie jedoch über einen Neustart hinweg erhalten bleiben, müssen Sie eine Konfigurationsdatei ändern, /etc/sysctl.confdie möglicherweise für Ihre Distribution spezifisch ist.)

Ein Nebeneffekt ist, dass Ihr Computer mit dieser Einstellung möglicherweise einen geringeren Datendurchsatz beim Schreiben hat. Im Großen und Ganzen finde ich es jedoch hilfreich, zu sehen, dass ein Programm lange ausgeführt wird, während es viele Daten schreibt, im Vergleich zu der Verwirrung, dass es eine hat Das Programm scheint mit seiner Arbeit fertig zu sein, aber das System bleibt schlecht zurück, da der Kernel die eigentliche Arbeit erledigt. Wenn Sie dirty_byteseinen relativ kleinen Wert festlegen , kann dies auch dazu beitragen, dass Ihr System nicht mehr reagiert, wenn der verfügbare Speicher knapp wird und Sie ein Programm ausführen, das plötzlich viele Daten schreibt.

Aber nicht zu klein einstellen! Ich verwende 15 MB als grobe Schätzung, dass der Kernel den Puffer in 1/4 Sekunde oder weniger auf eine normale Festplatte leeren kann. Es verhindert, dass sich mein System "nachlässig" anfühlt.


Ich habe ein Jahr oder länger nach einer Lösung für dieses Problem gesucht und dachte, es sei nur ein Fehler unter Linux. Vielen Dank.
Sidahmed

1
Linux noob hier, könnte jemand posten, wie man die <dirty_bytes> -Werte ändert?
Brofessor

@Brofessor Oh, sorry, ich hätte es mit dem offiziellen Namen anstelle von / proc beschreiben sollen. Antwort wird aktualisiert.
Datum

1
Dies ähnelt unix.stackexchange.com/questions/107703/… --- hätte behoben werden sollen, aber glauben Sie mir, das ist es nicht. Ich musste es zu Ubuntu 18.04 hinzufügen, um mich nicht mehr lustig zu benehmen ...
Rmano

Funktioniert auch mit Fedora 30. Ich bin überrascht, solch ein dummes Verhalten auch in modernen Linux-Distributionen zu sehen.
Sziraqui

0

Alte Frage, aber es scheint, als ob das Problem immer noch auftaucht. Das Einstellen des Puffers auf 15 MB, wie hier vorgeschlagen , funktionierte unter Ubuntu 19.04 nicht und brachte mein System zum Erliegen.

Ich habe versucht, eine 1,5-GB-Datei auf ein leeres (neu formatiertes) FAT32-16-GB-Laufwerk zu kopieren. Ich ließ es ungefähr 10 Minuten lang laufen, nur um zu sehen, ob es enden würde, ohne Glück.

Durch die Neuformatierung auf NTFS wird der Vorgang in weniger als 10 Sekunden beendet. Ich weiß nicht, warum das wichtig ist, weil FAT32 alles unter 2 GB zulassen sollte, aber es schien gut zu funktionieren. Keine ideale Lösung für Laufwerke, die Sie mit MacOS verwenden möchten, sondern eine einfache Umgehung für alle anderen Anwendungsfälle. Ich stelle mir vor, dass exFAT ähnlich funktioniert hätte, aber ich habe es nicht getestet.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.