Pourquoi lors de la copie sur un lecteur externe la fenêtre de progression n'est pas correcte
N'hésitez pas à éditer le titre pour mieux expliquer ce que je vais écrire ici.
Lorsque je copie des fichiers volumineux sur une clé USB, par exemple, la fenêtre de progression affiche une estimation indiquant que la plupart du temps ne manque pas d'indiquer le temps réel et le pourcentage d'achèvement, mais qu'il existe des cas où il est indiqué que tout est terminé et que la fenêtre de progression se ferme. Je vais extraire le stylo lecteur et il dit qu'il est toujours en cours d'utilisation. Après avoir vérifié la clé USB, je constate qu’il copie toujours les fichiers, mais aucune fenêtre de progression ne l’a montré.
Cela ne se produit pas seulement avec les gros fichiers, mais aussi avec beaucoup de petits fichiers. Si je les copie, la barre de progression peut indiquer 15 secondes, par exemple, et se terminer dans ce délai, mais la durée réelle peut être de 1 minute. Pour les 45 prochaines secondes, je dois regarder la lumière de la clé USB pour voir s’il y a lieu. est une activité réelle sur elle.
Je ne veux pas savoir comment le réparer, car j'ai lu à quel point un correctif pour ce problème pourrait aller. Ce que je veux savoir, c'est pourquoi la fenêtre de progression affiche une estimation qui ne correspond pas au processus de copie.
Est-ce que cela dépend du cache dans l'unité externe?
La taille du fichier et la quantité d’influence du fichier sur l’estimation correcte. Par exemple, 1 fichier de 4 Go ou 1000 fichiers de 4 Mo.
Existe-t-il des options de configuration pouvant modifier le comportement?.
Il y a d'autres questions similaires à celle-ci, telle que la copie de fichiers sur une clé USB n'est jamais terminée , mais je me concentre davantage sur les mécanismes qui expliquent pourquoi cela se comporterait de la sorte.
Je suppose que vous utilisez Nautilus en tant que gestionnaire de fichiers et que, dans ce cas, il existe des bogues de longue date à ce sujet. Trop numineux pour parler de Mint, Fedora, Red Hat, etc. Ubuntu n’est pas sans ce même problème.
Certains suggèrent que désactiver l'affichage des miniatures aide. D'autres misent sur le "nouveau noyau", mais celui-ci existe toujours.
Le problème = commence rapidement, puis ralentit C'est parce que lorsqu'il est monté en mode asynchrone, il écrit dans le cache. Lorsque le cache est plein, vous voyez la vitesse d'écriture "réelle".
Le travail semble être Sudo cp /filetobecopied /dev/nameofdevice
un autre posté ici dit que "copier en morceaux" fonctionne. Non confirmé de ma part.
C'est aussi une bonne réponse avec une solution: https://unix.stackexchange.com/a/181236 On dit:
Cela se produit parce que le programme dit "écris ces données" et que le noyau Linux les copie dans une mémoire tampon mise en file d'attente pour aller sur le disque, puis indique "ok, c'est fait". Donc, le programme pense qu'il a tout copié. Ensuite, le programme ferme le fichier, mais soudain le noyau le fait attendre pendant que ce tampon est déplacé sur le disque.
Donc, malheureusement, le programme ne peut pas vous dire combien de temps il faudra pour vider le tampon car il ne le sait pas.
Si vous voulez essayer quelques astuces d'utilisateurs expérimentés, vous pouvez réduire la taille de la mémoire tampon utilisée par Linux en définissant/proc/sys/vm/dirty_bytes à quelque chose comme 15728640 (15 Mo). Cela signifie que l'application ne peut pas avoir plus de 15 Mo d'avance sur ses progrès réels.
Un effet secondaire est que votre ordinateur a peut-être un débit d’écriture de données plus faible avec ce paramètre, mais dans l’ensemble, j’estime utile de voir qu’un programme s'exécute longtemps tout en écrivant beaucoup de données, alors Il semble que le programme soit terminé avec son travail, mais le système est en retard par rapport au noyau. Définir dirty_bytes sur une valeur raisonnablement petite peut également aider votre système à ne pas cesser de répondre lorsque vous manquez de mémoire et que vous exécutez un programme qui écrit soudainement beaucoup de données.
Mais ne le définissez pas trop petit! J'utilise 15 Mo comme une estimation approximative que le noyau peut vider la mémoire tampon sur un disque dur normal en 1/4 de seconde ou moins. Cela empêche mon système de se sentir "en retard".