Le système se bloque / ne répond pas / est inutilisable lors de la copie d'un fichier volumineux sur USB

52

Hier, je copiais un fichier unique de 8 Go sur une clé USB avec une vitesse d’écriture lente de 7 Mo / s, alors que ma mémoire RAM représentait 3 Go. Lors de la copie du système, je suis resté bloqué au point où je ne pouvais même plus déplacer le curseur.

J'ai réussi à me connecter à la console de saisie du texte et iotop, en cours d'exécution, cela a montré qu'un processus nommé kswapd0prenait 99,99% des E / S.

Existe-t-il des solutions pour que la copie d'un fichier volumineux ne rende pas mon système inutilisable?

usb freeze

— sashoalm
source

14

Ce bug est tellement ridicule ...

— king_julien

Oui, cela ne se produit pas uniquement avec Ubuntu, mais également dans d’autres versions de Debian. J'ai également vu le même problème dans Kali Linux et Parrot OS. Kali a le pire scénario, tandis que perroquet le rend lisse mais reste suspendu pour les très grandes tailles. Je pense que c'est le problème dans le noyau Linux et comment il est écrit. Ceci est et restera le pire cauchemar de Linux de tous les temps.

— Mohith7548

34

Selon ce rapport de bogue je l'ai résolu en ajoutant les lignes suivantes

vm.dirty_background_ratio = 5
vm.dirty_ratio = 10

dans /etc/sysctl.conf

et courir

sudo sysctl -p

— Philippe Gachoud
source

12

Voulez-vous expliquer ce que les lignes ci-dessus font?

— Nsane

3

@ nisargshah95 désolé, mais vous n'avez pas la moindre idée, cherchez vous-même ;-)

— Philippe Gachoud

4

@ nisargshah95 Les détails du problème sont expliqués dans les deux articles de LWN liés dans unix.stackexchange.com/a/107722/52205

— Rmano

1

Merci, je viens de trouver que mon Ubuntu 16.04 ne peut pas écrire deux fichiers de 1,4 Go sur USB sans ces deux lignes, je me suis figé pendant des heures, ce problème résolu, peu importe, peu importe la façon dont vous voulez copier des fichiers et les déplacer. sur.

— Mike

1

J'avais les valeurs 5 et 60. Celles-ci contrôlent le pourcentage de mémoire utilisé pour les opérations, while dirty_background_byteset dirty_bytesutilisent des valeurs en octets absolus . J'ai corrigé ce problème avec la deuxième réponse, mais pour le rendre persistant, ajoutez-le à sysctl.conf, voyez cette réponse . Ainsi, lorsque vous utilisez des valeurs en pourcentage, modifiez-les lors de la mise à niveau de la mémoire.

— PeterM

20

Je suis tombé sur le même problème. Le mien est un Ubuntu 14.04 64 bits. Donc, après une longue lutte, j'ai trouvé une réponse qui résout mon problème. Pour faciliter l'utilisation, j'ai ajouté les commandes ci-dessous utilisées dans la réponse mentionnée ci-dessus . Vérifiez la réponse pour une explication détaillée.

echo $((16*1024*1024)) > /proc/sys/vm/dirty_background_bytes
echo $((48*1024*1024)) > /proc/sys/vm/dirty_bytes

Après avoir utilisé la commande ci-dessus, le système a commencé à fonctionner normalement lors de la copie de fichiers.

Merci à @Rmano .

— Mahendran Sakkarai
source

2

Les paramètres de ratio ne m'ont pas aidé sur mon système 12.04 avec un partage NAS lent. Mais après avoir défini directement les octets, comme suggéré ici, mon système est à nouveau utilisable lors de la copie sur le NAS.

— mardi

6

Cette question a 3 ans et elle est toujours nécessaire pour éviter d’obtenir un système inutilisable lors de la copie sur une clé USB. Quelques informations: si la clé USB est formatée avec un fs Linux comme ext4, cela ne se produit pas. Lorsque je dis "système inutilisable", je le pense vraiment, le pointeur de la souris ne répond plus et vous devez insister pour le déplacer sur l'écran, vous regardez le moniteur du système et l'utilisation des ressources n'est pas anormale. Les utilisateurs du noyau utilisent-ils tous des processeurs Intel et des disques SSD de sixième génération? Comment se fait-il qu'ils ne s'en rendent pas compte pendant les tests.

— Hatoru Hansou

3

@HatoruHansou Je ressens la même chose, je viens d'installer une nouvelle version de Debian Stretch et cette erreur est également présente ici. Je sais que cela ne dépend pas de la distribution, mais des sources du noyau, mais hommes, comment se fait-il que cela ne soit toujours pas réglé?

— Marecky

1

@Marecky Après quelques lectures, il semble que les dirty_bytes ne soient pas une simple chose en usb. Elles affectent toutes les E / S. Après avoir utilisé l’écho, vous les modifiez au niveau global, et non plus uniquement pour les clés USB. Pour la session en cours seulement, je pense. Il semble que les valeurs actuelles du noyau soient modifiées en pensant aux nouveaux périphériques de stockage. Les disques lents souffrent d'effets secondaires. Désolé, pas de lien, mais cela doit être facile à trouver en le cherchant sur Google.

— Hatoru Hansou

3

Voir cette réponse pour la rendre persistante

— PeterM

5

Je rencontre un problème similaire avec le gel du système lors de la copie sur un lecteur flash. J'ai soumis un rapport de bogue à ce sujet: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1267648

En guise de solution de contournement, j'ai constaté que la désactivation de l'échange élimine complètement le problème.

— Vladimir Rutsky
source

1

Malheureusement, cela n'a pas fonctionné pour moi sur Ubuntu 16.04.

— Programster

Cela n’a pas fonctionné pour moi non plus sur Ubuntu 16.04.3 LTS, mais sur un ordinateur portable Alienware 17 R2.

— AnthonyK

4

Oui, il existe des paramètres de noyau que vous pouvez modifier en spécifiant la quantité de données devant être marquées comme écrites avant qu’elles ne soient réellement écrites sur le disque. Regardez ici pour une description assez complète d'eux. En particulier, vous voudrez trouver une valeur de dirty_ratio qui fonctionne bien pour vous (elle est généralement trop élevée pour un ordinateur de bureau / un ordinateur portable par défaut, mais aucun nombre magique ne convient à tout le monde).

— Bandrami
source

2

Hé, pourriez-vous s'il vous plaît me suggérer quels numéros je dois définir en fonction des spécifications de mon ordinateur portable? Reportez-vous à askubuntu.com/questions/713723/…

3

Je viens d'avoir exactement le même problème (en 2019), sous Ubuntu 19.10, lors de la copie d'un grand nombre de fichiers d'un disque USB vers un disque SATA. Les deux systèmes de fichiers sont ext4. Lorsque j'ai désactivé l'échange, le problème a disparu. Cela ressemble à un bogue dans l'allocation de mémoire pour les tampons de disque - apparemment, le noyau tente d'allouer le plus de mémoire possible pour les tampons de disque, dans une telle situation qui n'a pas de sens (créer des tampons de disque dans swap ...), ou il calcule à tort la taille de la mémoire qui peut être utilisée pour la mise en cache ...

— chaker
source

Est-ce que l'une des solutions ici a fonctionné pour vous? J'ai commencé à souffrir de ce problème après la mise à niveau vers 19.10 & dans le processus de mise à jour du noyau. Dans mon cas, cela se produit lorsque je copie un fichier volumineux de la partition A vers la partition B du même disque SSD. La désactivation de SWAP "corrige" le problème.

— pileofrocks

1

J'ai eu des problèmes similaires lors de la copie de fichiers sur un exfatlecteur. J'ai eu moins de difficulté à utiliser un ext4système de fichiers sur mon disque dur USB.

— masse
source

1

Eu aussi ce numéro sur ext4

— PeterM

Fedora 27 (noyau 4.17.5-100) copie de la rouille en rotation attachée par USB sur une clé USB. Cela semble aller aussi loin que de geler le screenlocker à mi-fondu. :-( ~~~

— David Tonhofer