Gnome, Nautilus copie des fichiers sur USB s'arrête à 100% ou près

J'ai eu des problèmes similaires auparavant, mais je ne me souviens pas comment je les ai résolus.

Lorsque j'essaie de copier quelque chose sur une clé USB, avec FAT, cela s'arrête vers la fin, parfois à 100%. Et bien sûr, lorsque je transfère la clé USB ailleurs, elle ne contient pas de fichier complet. (le fichier est un film!)

J'ai essayé de monter le périphérique avec le montage -o flush, mais j'obtiens le même problème.

De plus, j'ai formaté la clé USB avec la nouvelle partition FAT ...

Une idée du froid que je fais?

ps Je crois que ce n'est pas lié au système d'exploitation, qui est Debian, et je crois que la copie à partir du lecteur SSD ne le rend pas bloqué.

Quelque part, j'ai rencontré l'explication de la question suivante. Dans le cas où la copie a été effectuée via la mémoire de fonctionnement, et l'idicator montre le processus de lecture des données du lecteur. Mais le processus de correction est beaucoup plus long, en particulier sur la clé USB (il peut être 100 fois plus lent: comme la compression de 2 Mo / s contre 200 Mo / sec de lecture par exemple) et plus si vous utilisez des systèmes de fichiers non natifs comme FAT ou NTFS sous Linux . Essayez donc d'attendre la fin de la transaction même si elle est arrêtée à 100% mais ne fermez pas (ce qui devrait indiquer la fin).

— Costas

je me demande juste s'il est possible de vérifier les progrès dans cette situation ???

essayez de formater la clé USB avec l'option écraser les données de sortie avec des zéros Cela fonctionne sur ma clé USB Trancend 8 Go

— Akshay Daundkar

Pour toute personne rencontrant ce problème, formatez simplement votre disque en NTFS.

— Ricky Boyce

Réponses:

La raison pour laquelle cela se produit de cette façon est que le programme dit "écrire ces données" et que le noyau Linux les copie dans un tampon de mémoire qui est mis en file d'attente pour aller sur le disque, puis dit "ok, c'est fait". Le programme pense donc qu'il a tout copié. Ensuite, le programme ferme le fichier, mais soudainement, le noyau le fait attendre pendant que ce tampon est poussé vers le disque.

Donc, malheureusement, le programme ne peut pas vous dire combien de temps il faudra pour vider le tampon car il ne sait pas.

Si vous voulez essayer quelques astuces pour les utilisateurs avancés, vous pouvez réduire la taille du tampon utilisé par Linux en définissant le paramètre du noyau vm.dirty_bytesà quelque chose comme 15000000(15 Mo). Cela signifie que l'application ne peut pas obtenir plus de 15 Mo avant sa progression réelle. (Vous pouvez modifier les paramètres du noyau à la volée, sudo sysctl vm.dirty_bytes=15000000mais les faire rester pendant un redémarrage nécessite de changer un fichier de configuration comme celui /etc/sysctl.confqui pourrait être spécifique à votre distribution.)

Un effet secondaire est que votre ordinateur peut avoir un débit d'écriture de données inférieur avec ce paramètre, mais dans l'ensemble, je trouve utile de voir qu'un programme s'exécute longtemps alors qu'il écrit beaucoup de données par rapport à la confusion d'avoir un Le programme semble avoir terminé son travail, mais le système est à la traîne car le noyau fait le travail réel. La définition dirty_bytesd'une valeur raisonnablement petite peut également empêcher votre système de ne plus répondre lorsque vous manquez de mémoire et d'exécuter un programme qui écrit soudainement beaucoup de données.

Mais ne le mettez pas trop petit! J'utilise 15 Mo comme estimation approximative du fait que le noyau peut vider le tampon sur un disque dur normal en 1/4 de seconde ou moins. Cela empêche mon système de se sentir "en retard".

— sans données
source

Je cherchais une solution à ce problème depuis un an ou plus, je pensais que c'était juste un bug dans Linux. Merci beaucoup.

— Sidahmed

Linux noob ici, quelqu'un pourrait-il poster comment modifier les valeurs <dirty_bytes>?

— Brofessor

@Brofessor Oh, désolé, j'aurais dû le décrire par le nom officiel au lieu des détails / proc. La réponse est mise à jour.

— données le

Ceci est similaire à unix.stackexchange.com/questions/107703/… --- aurait dû être corrigé, mais croyez-moi, ce n'est pas le cas. J'ai dû l'ajouter à Ubuntu 18.04 pour arrêter de

— me

Fonctionne également sur Fedora 30. Je suis surpris de voir un comportement aussi stupide même dans les distributions Linux modernes.

— sziraqui

Vieille question, mais il semble que le problème persiste. La définition du tampon à 15 Mo comme suggéré ici n'a pas fonctionné sur Ubuntu 19.04, et a mis mon système à l'arrêt.

J'essayais de copier un fichier de 1,5 Go sur un lecteur FAT32 16 Go vide (nouvellement formaté). Je l'ai laissé fonctionner pendant environ 10 minutes juste pour voir s'il finirait, sans chance.

Le reformatage en NTFS a laissé l'opération se terminer en moins de 10 secondes. Je ne sais pas pourquoi cela importerait car FAT32 devrait autoriser tout ce qui est inférieur à 2 Go, mais cela semblait fonctionner très bien. Pas une solution idéale pour les disques que vous souhaitez utiliser avec MacOS, mais une solution de contournement facile pour tous les autres cas d'utilisation. J'imagine qu'exFAT aurait fonctionné de la même manière, mais je ne l'ai pas testé.

— Jacob Jones
source