Perché il desktop si blocca quando copio molti file su un'unità USB?

11

Il mio desktop di solito è molto reattivo, anche sotto carico pesante. Ma quando copio i file su un'unità USB, dopo qualche tempo si blocca sempre. Con "lock up" intendo:

Lo spostamento della messa a fuoco da una finestra all'altra può richiedere 10-20 secondi
Il cambio desktop può richiedere 10-20 secondi
I video non si aggiornano più (su YouTube, l'audio continua a essere riprodotto, solo il video si blocca)

Il carico di sistema non è eccezionalmente elevato quando ciò accade. A volte vedo molto bianco su xosview che indica che il kernel è occupato da qualche parte.

A prima vista, sembra che la copia dei file sull'unità USB interferisca in qualche modo con Compiz, ma non riesco a immaginare quale potrebbe essere la connessione.

Ecco l'output di htop:

Uscita di htop poco dopo il blocco

Ecco l'output di iostat -c -z -t -x -d 1durante un hang di 2 minuti:

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

Come puoi vedere, è attivo solo il disco rigido esterno. Ecco il registro completo: http://pastebin.com/YNWTAkh4

L'impiccagione è iniziata alle 20:38:01 e si è conclusa alle 20:40:19.

Informazioni sul software:

openSUSE 12.1
KDE 4.7.x
Filesystem: reiserfs e btrfs sul mio hard disk interno, btrfs sull'unità USB

linux kde btrfs

— Aaron Digulla
fonte

1

Hai provato a montare l'unità USB syncper vedere quale effetto (se presente) ha?

— Alexios,

2

Uno svantaggio dell'USB è il fatto che dipende fortemente dalla CPU per IO. Che tipo di CPU ha il tuo sistema? Aggiungi l'output di grep name /proc/cpuinfoalla tua domanda per favore.

— jippie,

1

Trascini i file usando dolphin? In tal caso, provare cpdalla riga di comando per escludere possibili bug dei delfini.

— Jari Laamanen,

@JariLaamanen: sto usando rsyncdalla riga di comando.

— Aaron Digulla,

1

@jippie: Non proprio perché l'interfaccia utente si blocca quando succede, quindi non posso fare uno screenshot. Proverò a creare un registro coniostat -c -z -d 1

— Aaron Digulla il

4

La mia prima ipotesi è stata btrfspoiché i processi I / O di questo file system a volte prendono il sopravvento. Ma non spiegherebbe perché X si blocca.

Guardando gli interrupt, vedo questo:

# 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

Bene, duh. Il driver USB utilizza lo stesso IRQ della scheda grafica ed è il primo della catena. Se si blocca (perché il file system fa qualcosa di costoso), la scheda grafica muore di fame (e anche la rete).

— Aaron Digulla
fonte

2

Avevo riscontrato problemi simili con il kernel linux-3.1 di openSUSE 12.1 e ho scoperto che disabilitare enormi pagine trasparenti ha aiutato:

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

Il problema di fondo è che se un'applicazione alloca 4 MB o più, il kernel proverà a dargli una pagina enorme, per la quale ha bisogno di un'intera RAM contigua da 4 MB. Ora, se ci sono molte pagine sporche in giro, che devono ancora essere scritte su un dispositivo USB lento, attende che quell'IO finisca prima di continuare con l'allocazione di memoria.

— Bernhard M.
fonte

1

Come accennato, questo probabilmente ha a che fare con l'installazione del kernel hugepages. Conosco diverse persone con questo problema. Puoi trovare diversi documenti a riguardo nel web, ad es

Ho risolto completamente il problema sulla mia installazione procedendo come segue. Nota YMMV, non tutte le correzioni riportate di seguito potrebbero essere necessarie e forse non saranno sufficienti. Potrei aver dimenticato qualcosa a dire il vero. Comunque questa è la mia configurazione e funziona.

Usa il kernel linux-ck
echo madvise > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag

— AF7
fonte

-2

Cambia il cavo. Rimuovere l'ossidazione dalla porta / cavi USB.

— luis
fonte

Deve essere un po 'più elaborato. Si prega di consultare le FAQ

— Karlson,