Pourquoi lors de la copie sur un disque externe, la fenêtre de progression n'est pas correcte

N'hésitez pas à modifier 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 montre une estimation que la plupart du temps ne manque pas d'afficher le temps réel et le pourcentage à terminer, mais il y a des cas où il est dit que tout est terminé et la fenêtre de progression se ferme. Je vais extraire la clé USB et il indique qu'elle est toujours utilisée. Après avoir vérifié la clé USB, je vois qu'il copie toujours les fichiers mais il n'y a pas de fenêtre de progression qui le montre.

Cela ne se produit pas seulement avec de gros fichiers, mais aussi avec de nombreux petits fichiers. Si je les copie, la barre de progression peut dire 15 secondes par exemple et se terminer dans ce temps, mais le temps réel peut être 1 minute et pour les 45 secondes suivantes, j'ai besoin de regarder la lumière dans la clé USB pour voir s'il y a est une véritable activité là-dessus.

Je ne veux pas savoir comment le réparer car j'ai lu à quel point un correctif pourrait aller en profondeur. Ce que je veux savoir, c'est pourquoi la fenêtre de progression affiche alors une estimation qui ne correspond pas au processus de copie.

Dépend-il du cache de l'unité externe?

Est 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.

Y a-t-il des options de configuration qui peuvent changer le comportement.

Il existe d'autres questions similaires à celle-ci, comme la copie de fichiers sur une clé USB jamais terminée, mais je me concentre davantage sur la mécanique pour savoir pourquoi cela se comporterait comme ça.

Je suppose que vous utilisez Nautilus comme gestionnaire de fichiers et si c'est le cas, il y a des bogues de longue date à ce sujet. Trop numineux pour mentionner effectuer Mint, Fedora, Red Hat et autres. Ubuntu n'est pas sans ce même problème.

Certains suggèrent de désactiver l'affichage des vignettes. D'autres placent leurs espoirs dans le "noyau le plus récent" mais cela existe toujours.

Le problème = démarre rapidement, puis ralentit. En effet, lorsqu'il est monté avec async, il écrit dans le cache, lorsque le cache est plein, vous voyez la vitesse d'écriture "réelle".

Le travail autour 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 belle réponse avec une solution: /unix//a/181236 Elle dit:

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 souhaitez essayer quelques astuces pour les utilisateurs expérimentés, vous pouvez réduire la taille du tampon utilisé par Linux en définissant / proc / sys / vm / dirty_bytes à quelque chose comme 15728640 (15 Mo). Cela signifie que l'application ne peut pas obtenir plus de 15 Mo avant sa progression réelle.

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 contre 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 de dirty_bytes sur une valeur raisonnablement petite peut également aider à empêcher votre système de ne plus répondre lorsque vous manquez de mémoire et exécutez 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 "lent".