Pourquoi mon PC se fige-t-il lorsque je copie un fichier sur une clé USB?


61

J'ai une situation vraiment étrange ici. Mon PC fonctionne bien, du moins dans la plupart des cas, mais je ne peux pas gérer une chose. Quand j'essaie de copier un fichier de ma clé USB, tout va bien - j'ai 16-19M / s, ça marche plutôt bien. Mais lorsque j'essaie de copier quelque chose sur la même clé USB, mon PC se bloque. Le pointeur de la souris cesse de bouger pendant une seconde ou deux, puis il bouge un peu et il s'arrête à nouveau. Lorsque quelque chose se joue, par exemple à Amarok, le son agit comme une mitraillette. La vitesse passe de 500K / s à 15M / s, moyenne de 8M / s. Cela se produit uniquement lorsque je copie quelque chose sur une clé USB. Lorsque le processus de copie est terminé, tout revient à la normale.

J'ai tout essayé - autre clé USB, un port USB différent sur le panneau avant ou à l'arrière, j'ai même changé les broches USB de la carte mère (panneau avant), mais peu importe où je mets ma clé USB, c'est toujours la même chose. J'ai essayé différents systèmes de fichiers - fat32, ext4. Je n'ai aucun problème avec l'appareil sous Windows, sur mon ordinateur portable. Ce doit être mon PC ou quelque chose dans mon système. Je n'ai aucune idée de ce qu'il faut rechercher. J'utilise les tests Debian avec Openbox autonome. Mon PC est un peu vieux - Pentium D 3GHz, 1 Go de RAM, 1,5 To disque WD Green. Si vous avez quelque chose qui pourrait m'aider à résoudre ce problème, je serais heureux de l'entendre.

Je ne sais pas quelles autres informations je devrais fournir, mais si vous avez besoin de quelque chose, demandez-le simplement, je mettrai à jour ce message le plus tôt possible.

J'ai essayé de reproduire ce problème sur Ubuntu 13.04 live cd. J'ai monté ma partition cryptée + swap crypté et connecté ma clé USB à un port USB. Ensuite, j'ai essayé de démarrer certaines applications. Aujourd'hui, j'ai environ 820 Mo de RAM et environ 400 Mo de mémoire SWAP. Il n'y a pas de problème avec la copie, pas de congélation du tout, tout est comme il se doit. Donc, on dirait que c'est une faute du système, mais où exactement? Qu'est-ce qui causerait un comportement aussi étrange?


Lorsque j'ai rencontré quelque chose de similaire, c'est parce que mon ordinateur portable me causait des problèmes de disque dur. Le disque contenait des zones défectueuses et chaque fois que j'essayais de lire quoi que ce soit dans ces zones, il gelait jusqu'à ce que cela soit terminé. Juste une idée à examiner. Peut-être avez-vous de mauvais secteurs dans lesquels vous essayez de lire.
slybloty

Mon disque dur est ok, au moins malin le dire (après analyse complète).
Mikhail Morfikov

Essayez de réduire la priorité IO du processus de copie, par exemple ionice -c3 cp something.tgz /media/pendrive. Cela placera le cpprocessus nouvellement créé dans la troisième classe de priorité (= la plus basse) "inactif".
2014

J'ai essayé cela, mais cela n'a aucun effet.
Mikhail Morfikov

@ MikhailMorfikov FYI, cette question a été traitée dans Linux 4.9. Je n'ai toujours pas testé le correctif moi-même. YMMV.
Seamus Connor

Réponses:


85

Utilisez-vous une version 64 bits de Linux avec beaucoup de mémoire? Dans ce cas, le problème peut être que Linux peut verrouiller pendant plusieurs minutes les écritures volumineuses sur des périphériques lents, tels que des cartes SD ou des clés USB. C'est un bug connu qui devrait être corrigé dans les nouveaux noyaux.

Voir http://lwn.net/Articles/572911/

Solution: en tant que problème racine:

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

Je l'ai ajouté à mon /etc/rc.localfichier dans mes machines 64 bits.

TANSTAAFL ; ce changement peut (et va probablement le faire) réduire votre débit sur ces périphériques - c'est un compromis entre latence et vitesse. Pour revenir au comportement précédent, vous pouvez

echo 0 > /proc/sys/vm/dirty_background_bytes
echo 0 > /proc/sys/vm/dirty_bytes

... qui sont les valeurs par défaut, ce qui signifie que le comportement de réécriture sera contrôlé par les paramètres dirty_ratioet dirty_background_ratio.

Remarque pour les non-experts de linux: les fichiers /proc sont des pseudofichiers - juste des canaux de communication entre le noyau et l’espace utilisateur. Ne jamais utiliser un éditeur pour les modifier ou les regarder; obtenez à la place une invite du shell - par exemple, avec sudo -i(saveurs Ubuntu) ou su rootet utilisez echoet cat).

Mise à jour 2016/04/18 il semble qu'après tout, le problème est toujours là. Vous pouvez le consulter sur LWN.net , dans cet article sur les files d'attente d'écriture différée .


3
J'ai 64 bits, mais seulement 1 Go de RAM, et je dois vous dire que cette solution fonctionne! Je viens de le tester, et après avoir réglé les deux paramètres, il n'y a plus de gel. :)
Mikhail Morfikov

1
Dans mon installation de 14.04, uname -aretourne 3.13.0-32-generic, donc oui. Mais je n'ai pas vérifié si le correctif pour le problème avait été intégré au noyau ou non. J'ai une machine de 16 Go et cela semble fonctionner correctement sans la solution de contournement, bien que je dois dire que je n'ai pas essayé avec des appareils particulièrement lents.
Rmano

1
@ IonicăBizău --- c'est un pseudo-fichier, ne l'éditez pas avec vim jamais . Obtenez un shell root (avec sudo -i) et utilisez les commandes susmentionnées.
Rmano

1
@Rmano Cela a fonctionné! Cependant, je l'ai édité avec VIM. Merci!
Ionică Bizău

2
J'utilise Ubuntu 16.04 sur un tout nouvel ordinateur portable (avec 16 Go de RAM). J'étais vraiment en colère contre ce problème. Votre solution a fonctionné comme un charme! Peut-être pourriez-vous ajouter que cela pourrait encore être nécessaire avec le noyau 4.8.0-45.
LGenzelis

3

L'amplification en écriture peut être la raison, car le système tente d'écrire en morceaux plus petits que l'effacement de bloc (lecture / mod / écriture) + un désalignement de bloc.

Pour vérifier votre réglage actuel, procédez comme suit:

cat /sys/block/sd**X**/device/max_sectors

Vous pouvez régler les règles de salle pour ces appareils:

Changer la valeur de "max_sectors" USB pour toute une famille de périphériques

Dans ce cas, j'avais remplacé max_sectors pour tous les périphériques, qui utilisait une valeur par défaut de 240 (stockage USB) en 32K secteurs ou 2K secteurs.

Sur mon système (Mageia 4, 3.14.24 core i7), je devais le faire à cause de vitesses d’écriture terriblement lentes (2 Mo / s) sur Kingston DT101 G2 16GB:

vi /usr/lib/udev/rules.d/81-udisks_maxsect.rules

et ajouter:

SUBSYSTEMS=="scsi", ATTR{max_sectors}=="240", ATTR{max_sectors}="32678"

Et la ddvitesse d'écriture a été multipliée par 3. mc cpprobablement 10 à 20 fois plus haut (après avoir commencé la première partition et réformaté avec 64 000 clusters alignés):

fdisk -u /dev/sdh # make DOS compat off if on
mkfs.vfat /dev/sdh1 -n KINGSTON16G -s 128 **-R 4592*** and use *fsck.vfat -v /dev/sdh1

pour vérifier l'alignement (vérifiez [le secteur de début des données] doit être multiple de 128 (taille du cluster)). Ajustez le nombre de secteurs réservés (-R) si nécessaire.

Par défaut, max_sectors (240) semble entraîner une forte amplification en écriture sur certains des nouveaux lecteurs bon marché. Mais soyez très prudent avec un réglage aussi élevé, l'effet similaire est obtenu à 2048 secteurs (probablement des blocs d'effacement 1M:

SUBSYSTEMS=="scsi", ATTR{max_sectors}=="240", ATTR{max_sectors}="2048"

Testez tous vos vieux périphériques USB, ils fonctionnent toujours bien. Utilisez des attributs de fournisseur / modèle dans les fichiers de règles pour être plus spécifique.


1

matériel vs logiciel

J'ai rencontré un problème étrange similaire à celui rencontré avec les clés USB, et dans mes recherches, il s'agit presque toujours d'un problème de pilote ou du matériel spécifique du PC / de la carte mère.

Je le sais parce que j'ai plusieurs systèmes qui sont du matériel identique, et sur un, je peux effectuer cette opération sans problème, alors que sur un autre, le problème se présente.

Que faire?

Vos options sont vraiment limitées ici. Il vous suffit de vous assurer que le dernier BIOS / firmware est installé sur votre système et que vous disposez des dernières versions des paquets de votre disto.

Au-delà de tout ce que je peux vous suggérer, c’est de vous assurer que vous évitez cette situation en ne tentant pas de copier des fichiers pendant qu’une autre copie est en cours.

Si vous avez le type de personnalité qui vous énerve, essayez une autre distribution live de Linux et répétez les étapes qui ont conduit à votre problème. Cela éliminerait simplement le problème, qu'il s'agisse d'un problème spécifique à la distribution ou d'un matériel, comme je l'ai décrit ci-dessus. Ce serait une petite consolation, mais j'aime toujours savoir des choses plutôt que de me plonger la tête dans le sable, et non.

Rien d'autre?

Si vous êtes vraiment obsédé par les obsessions, vous pouvez essayer d’exécuter l’application avec laquelle vous faites la copie, stracedans l’espoir d’attraper le système, quel que soit l’appel système gelé. Vous devriez également pouvoir le faire depuis la ligne de commande.

Exemple

$ strace -o cp1.log cp -r /path/to/dir1 /path/to/usb/. 

Ensuite, lancez-en un autre.

$ strace -o cp2.log cp -r /path/to/dir2 /path/to/usb/. 

Nous espérons que le système gèlera pendant cette opération et que vous aurez peut-être de la chance de trouver de la fumée dans l'un ou l'autre de ces fichiers journaux.


J'utilise toujours la seule instance de copie de fichier. J'ai mis à jour le BIOS (2008), et il n'y a pas eu de version plus récente depuis. Je pense que ce n'est pas le BIOS. Ma distribution Debian est également mise à jour pour la branche testing. J'ai essayé d'utiliser straceet le gel a joué presque instantanément, alors j'ai attendu quelques secondes et j'ai tué le processus. J'ai un journal de 1 Mo, mais je ne peux pas le lire, je ne sais pas quoi chercher. Vous pouvez le vérifier ici pastebin.com/u29RvqgC - ce n'est pas le journal complet (limité à 500 Ko), mais il n'y avait que des lignes similaires à celles de la fin. Je vais essayer de reproduire ce problème avec Ubuntu Live CD.
Mikhail Morfikov

J'ai mis à jour la question quant à vivre des tests de CD.
Mikhail Morfikov

@ MikhailMorfikov - Je pense que vous êtes à peu près au bout de ce que vous pouvez vous attendre à faire. Votre matériel est assez ancien (2008) et vous ne pouvez vraiment rien faire d'autre que ce que j'ai décrit ci-dessus.
slm

Mais même les plus vieux ordinateurs sont capables de copier des fichiers sans problèmes.
Mikhail Morfikov

@MikhailMorfikov - L'âge n'est pas le seul facteur à prendre en compte, mais il est peu probable que les mises à jour de microprogrammes ou les mises à jour de logiciels pour ancien matériel soient à la hauteur.
slm
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.