Pourquoi mon PC se bloque-t-il pendant que je copie un fichier sur une clé USB?
J'ai une situation vraiment étrange ici. Mon PC fonctionne très bien, du moins dans la plupart des cas, mais il y a une chose que je ne peux pas gérer. Quand j'essaie de copier un fichier depuis 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 se déplacer pendant une seconde ou deux, puis il se déplace un peu et s'arrête à nouveau. Quand quelque chose joue, par exemple, dans Amarok, le son agit comme une mitrailleuse. La vitesse passe de 500K/s à 15M/s, en moyenne 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 ces ports de l'arrière, j'ai même changé les broches USB sur 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 ne sais pas quoi chercher. J'utilise les tests Debian avec Openbox autonome. Mon PC est un peu vieux - Pentium D 3GHz, 1 Go de RAM, 1,5 To WD Green disk. 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 dois fournir, mais si vous avez besoin de quelque chose, demandez simplement, je mettrai à jour ce message dès que 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, et maintenant j'ai ~ 820 Mo en RAM et environ 400 Mo en SWAP. Il n'y a pas de problème de copie, pas de gel du tout, tout est comme il se doit. Donc , il semble que ce soit une faute du système, mais où exactement? Qu'est-ce qui provoquerait un tel comportement bizarre?
Utilisez-vous une version 64 bits de Linux avec beaucoup de mémoire? Dans ce cas, le problème pourrait être que Linux peut se verrouiller pendant des minutes sur de grandes écritures sur des appareils lents comme par exemple des cartes SD ou des clés USB. C'est un bug connu qui devrait être corrigé dans les noyaux plus récents.
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.local fichier dans mes machines 64 bits.
TANSTAAFL ; ce changement peut (et va probablement) réduire votre débit vers ces appareils --- c'est un compromis entre la latence et la 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 d'écriture différée sera contrôlé par les paramètres dirty_ratio et dirty_background_ratio.
Remarque pour les personnes pas si expertes avec Linux: les fichiers dans /proc sont des pseudofiles --- juste des canaux de communication entre le noyau et l'espace utilisateur. N'utilisez jamais un éditeur pour les modifier ou les consulter; obtenir à la place une invite Shell --- par exemple, avec Sudo -i (Versions Ubuntu) ou su root et utilisez echo et cat).
Mise à jour 2016/04/18 il semble que, après tout, le problème soit toujours là. Vous pouvez le consulter sur LWN.net , dans cet article sur les files d'attente d'écriture différée .
La raison peut être une amplification d'écriture, car le système essaie d'écrire en morceaux plus petits, que l'effacement de bloc (lecture/mod/écriture) + 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:
Modifier la valeur de l'USB "max_sectors" pour toute une famille d'appareils
Dans ce cas, j'avais remplacé max_sectors pour tous les appareils, qui utilisaient par défaut 240 (stockage USB) sur 32K secteurs ou 2K secteurs.
Sur mon système (Mageia 4, 3.14.24 core i7), je devais le faire en raison de vitesses d'écriture terriblement lentes (2 Mo/s) sur Kingston DT101 G2 16 Go:
vi /usr/lib/udev/rules.d/81-udisks_maxsect.rules
et ajouter:
SUBSYSTEMS=="scsi", ATTR{max_sectors}=="240", ATTR{max_sectors}="32678"
Et la vitesse d'écriture dd a été multipliée par 3. mccp probablement 10 à 20 fois plus haut (après avoir démarré la première partition @ 8192ème secteur et reformaté avec des clusters alignés à 64k):
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 (cochez [secteur de démarrage des données] doit être multiple de 128 (taille du cluster)). Ajustez le nombre de secteurs réservés (-R) si nécessaire.
Les max_sectors par défaut (240) semblent provoquer une forte amplification d'écriture sur certains des nouveaux lecteurs bon marché. Mais soyez très prudent avec un réglage aussi élevé, l'effet similaire est obtenu sur 2048 secteurs (probablement 1M de blocs d'effacement:
SUBSYSTEMS=="scsi", ATTR{max_sectors}=="240", ATTR{max_sectors}="2048"
Testez tous vos anciens périphériques USB, ils fonctionnent toujours bien. Utilisez des attributs de fournisseur/modèle dans les fichiers de règles pour être plus précis.
matériel vs logiciel
J'ai rencontré un problème étrange similaire à celui-ci 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 car j'ai plusieurs systèmes qui sont du matériel identique, et sur un, je peux faire cette opération sans problème, tandis que sur un autre le problème apparaît.
Que faire?
Vos options sont vraiment limitées ici. À propos des seules choses que vous pouvez faire, assurez-vous que le dernier BIOS/micrologiciel est installé sur votre système et assurez-vous que vous disposez des dernières versions des packages de votre disto.
Au-delà de cela, tout ce que je peux suggérer est de vous assurer que vous évitez cette situation en n'essayant pas de copier des fichiers pendant qu'une autre copie est en cours.
Si vous avez le type de personnalité où des choses comme ça vous contrarient, vous pouvez essayer une autre distribution en direct de Linux et répéter les étapes qui mènent à votre problème. Cela éliminerait simplement s'il s'agit d'un problème spécifique à la distribution ou d'un problème 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 m'enterrer la tête dans le sable, et non.
Rien d'autre?
Si vous êtes vraiment obsédé, vous pouvez essayer d'exécuter l'application avec laquelle vous effectuez la copie via strace dans l'espoir d'attraper le système dans n'importe quel appel système gelé. Vous devriez également pouvoir le faire à partir de la ligne de commande.
Exemple
$ strace -o cp1.log cp -r /path/to/dir1 /path/to/usb/.
Ensuite, pendant que cela fonctionne, commencez-en un autre.
$ strace -o cp2.log cp -r /path/to/dir2 /path/to/usb/.
Espérons que le système se fige pendant cette opération et vous aurez peut-être de la chance et trouverez de la fumée dans l'un de ces fichiers journaux.