Pourquoi mon bureau se verrouille-t-il lorsque je copie de nombreux fichiers sur une clé USB?

11

Mon bureau est généralement très réactif, même sous forte charge. Mais lorsque je copie des fichiers sur une clé USB, il se verrouille toujours après un certain temps. Par "enfermer", je veux dire:

Le déplacement du focus d'une fenêtre à une autre peut prendre 10 à 20 secondes
Changer de bureau peut prendre 10 à 20 secondes
Les vidéos ne sont plus mises à jour (sur YouTube, l'audio continue de jouer, seule la vidéo se fige)

La charge du système n'est pas exceptionnellement élevée lorsque cela se produit. Parfois, je vois beaucoup de blanc sur xosview indiquant que le noyau est occupé quelque part.

À première vue, il semble que la copie de fichiers sur la clé USB interfère d'une manière ou d'une autre avec compiz, mais je ne peux pas imaginer quelle pourrait être la connexion.

Voici la sortie de htop:

Sortie de htop peu de temps après le blocage

Voici la sortie de iostat -c -z -t -x -d 1pendant un blocage de 2 minutes:

19.07.2012 20:38:22
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           1,27    0,00    0,38   37,52    0,00   60,84

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sdg               0,00     2,00    0,00  216,00     0,00 109248,00  1011,56   247,75  677,69    0,00  677,69   4,63 100,00

Comme vous pouvez le voir, seul le disque dur externe est actif. Voici le journal complet: http://pastebin.com/YNWTAkh4

Le blocage a commencé à 20:38:01 et s'est terminé à 20:40:19.

Informations sur le logiciel:

openSUSE 12.1
KDE 4.7.x
Systèmes de fichiers: reiserfs et btrfs sur mon disque dur interne, btrfs sur la clé USB

linux kde btrfs

— Aaron Digulla
source

1

Avez-vous essayé de monter le lecteur USB syncpour voir quel effet (le cas échéant) cela a?

— Alexios

2

Un inconvénient de l'USB est le fait qu'il repose fortement sur le CPU pour IO. De quel type de CPU dispose votre système? Ajoutez la sortie de grep name /proc/cpuinfoà votre question s'il vous plaît.

— jippie

1

Faites-vous glisser-déposer les fichiers en utilisant Dolphin? Si tel est le cas, essayez à cppartir de la ligne de commande d'exclure d'éventuels bogues de dauphin.

— Jari Laamanen

@JariLaamanen: J'utilise rsyncdepuis la ligne de commande.

— Aaron Digulla

1

@jippie: Pas vraiment parce que l'interface se bloque quand ça arrive, donc je ne peux pas faire de capture d'écran. Je vais essayer de créer un journal aveciostat -c -z -d 1

— Aaron Digulla

4

Ma première supposition était btrfsque les processus d'E / S de ce système de fichiers prenaient parfois le relais. Mais cela n'expliquerait pas pourquoi X se bloque.

En regardant les interruptions, je vois ceci:

# cat /proc/interrupts 
           CPU0       CPU1       CPU2       CPU3       CPU4       CPU5       CPU6       CPU7       
  0:        179          0          0          0          0          0          0          0  IR-IO-APIC-edge      timer
  1:          6          0          0          0          0          0          0          0  IR-IO-APIC-edge      i8042
  8:          1          0          0          0          0          0          0          0  IR-IO-APIC-edge      rtc0
  9:          0          0          0          0          0          0          0          0  IR-IO-APIC-fasteoi   acpi
 12:         10          0          0          0          0          0          0          0  IR-IO-APIC-edge      i8042
 16:    3306384          0          0          0          0          0          0          0  IR-IO-APIC-fasteoi   ehci_hcd:usb1, nvidia, mei, eth1

Eh bien, duh. Le pilote USB utilise le même IRQ que la carte graphique et il est le premier de la chaîne. S'il se bloque (parce que le système de fichiers fait quelque chose de cher), la carte graphique meurt de faim (et le réseau aussi).

— Aaron Digulla
source

2

J'avais vu des problèmes similaires avec le noyau linux-3.1 d' OpenSUSE 12.1 et constaté que la désactivation des pages volumineuses transparentes aidait:

echo never > /sys/kernel/mm/transparent_hugepage/enabled

Le problème sous-jacent est que si une application alloue 4 Mo ou plus, le noyau essaiera de lui donner une énorme page, pour laquelle il a besoin de toute une RAM contiguë de 4 Mo. Maintenant, s'il y a beaucoup de pages sales autour, qui doivent encore être écrites sur un périphérique USB lent, il attend que cette entrée-sortie se termine avant de poursuivre l'allocation de mémoire.

— Bernhard M.
source

1

Comme mentionné, cela a probablement à voir avec la configuration des énormes pages du noyau. Je connais plusieurs personnes avec ce problème. Vous pouvez trouver plusieurs documentations à ce sujet sur le Web, par exemple

J'ai complètement résolu le problème sur ma configuration en procédant comme suit. Remarquez YMMV, toutes les corrections ci-dessous peuvent ne pas être nécessaires, et peut-être qu'elles ne seront pas suffisantes. J'ai peut-être oublié quelque chose pour être honnête. Quoi qu'il en soit, c'est ma configuration et cela fonctionne.

Utiliser le noyau linux-ck
echo madvise > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag

— AF7
source

-2

Changez le câble. Retirez l'oxyde du port / des câbles USB.

— Luis
source

Cela doit être un peu plus élaboré. Veuillez consulter la FAQ

— Karlson