Perché il mio PC si blocca mentre sto copiando un file su un pendrive?


61

Ho una situazione davvero strana qui. Il mio PC funziona bene, almeno nella maggior parte dei casi, ma c'è una cosa che non posso affrontare. Quando provo a copiare un file dal mio pendrive, va tutto bene - ho 16-19M / s, funziona abbastanza bene. Ma quando provo a copiare qualcosa sullo stesso pendrive, il mio PC si blocca. Il puntatore del mouse si ferma per un secondo o due, quindi si sposta leggermente e si interrompe nuovamente. Quando qualcosa suona, ad esempio, in Amarok, il suono si comporta come una mitragliatrice. La velocità salta da 500 K / sa 15 M / s, in media 8 M / s. Questo si verifica solo quando sto copiando qualcosa su un pendrive. Al termine del processo di copia, tutto torna alla normalità.

Ho provato di tutto: altri pendrive, una porta USB diversa sul pannello frontale o quelle porte sul retro, ho persino cambiato i pin USB sulla scheda madre (pannello frontale), ma non importa dove ho messo la mia chiavetta USB, è sempre la stessa. Ho provato filesystem differente - fat32, ext4. Non ho problemi con il dispositivo su Windows, sul mio laptop. Deve essere il mio PC o qualcosa del mio sistema. Non ho idea di cosa cercare. Sto usando i test Debian con Openbox autonomo. Il mio PC è un po 'vecchio: Pentium D 3GHz, 1GiB di RAM, disco verde WD da 1,5 TB. Se hai qualcosa che mi aiuterebbe a risolvere questo problema, sarei felice di saperlo.

Non so quali altre informazioni dovrei fornire, ma se hai bisogno di qualcosa, chiedi, aggiornerò questo post il prima possibile.

Ho provato a riprodurre questo problema su cd live Ubuntu 13.04. Ho montato la mia partizione crittografata + swap crittografato e ho collegato il mio pendrive a una porta USB. Successivamente ho provato ad avviare alcune app, e ora ho ~ 820 MiB in RAM e circa 400 MiB in SWAP. Non c'è nessun problema con la copia, nessun congelamento, tutto è come dovrebbe essere. Quindi, sembra che sia un errore del sistema, ma dove esattamente? Cosa causerebbe un comportamento così strano?


Quando ho riscontrato qualcosa di simile a questo è stato perché avevo problemi con il disco rigido sul mio laptop. Il disco aveva delle aree difettose e ogni volta che stavo cercando di leggere qualcosa da quelle aree, si bloccava fino a quando non veniva eseguito. Solo un'idea da esaminare. Forse hai settori danneggiati da cui stai provando a leggere.
slybloty,

Il mio hdd è ok, almeno intelligente dillo (dopo la scansione completa).
Mikhail Morfikov,

Prova a ridurre la priorità di I / O del processo di copia, ad es ionice -c3 cp something.tgz /media/pendrive. Ciò inserirà il cpprocesso appena generato nella terza (= minima) classe di priorità "inattivo".
n.

Ho provato questo, ma non ha alcun effetto.
Mikhail Morfikov,

@MikhailMorfikov FYI, questo problema è stato risolto in Linux 4.9. Non ho ancora testato la correzione da solo. YMMV.
Seamus Connor,

Risposte:


85

Stai usando una versione a 64 bit di Linux con molta memoria? In tal caso il problema potrebbe essere che Linux può bloccarsi per minuti su grandi scritture su dispositivi lenti come ad esempio schede SD o chiavette USB. È un bug noto che dovrebbe essere corretto nei kernel più recenti.

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

Soluzione alternativa: come problema principale:

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

L'ho aggiunto al mio /etc/rc.localfile nei miei computer a 64 bit.

TANSTAAFL ; questa modifica può (e probabilmente ridurrà) la velocità effettiva di questi dispositivi --- è un compromesso tra latenza e velocità. Per tornare al comportamento precedente è possibile

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

... quali sono i valori predefiniti, il che significa che il comportamento di writeback sarà controllato dai parametri dirty_ratioe dirty_background_ratio.

Nota per le persone non così esperte con Linux: i file in /proc sono pseudofile --- solo canali di comunicazione tra il kernel e lo spazio utente. Non usare mai un editor per modificarli o guardarli; ottieni invece un prompt della shell --- per esempio, con sudo -i(Ubuntu flavours) oe su rootusa echoe cat).

Aggiornamento 2016/04/18 sembra che, dopo tutto, il problema sia ancora qui. Puoi vederlo su LWN.net , in questo articolo sulle code di writeback .


3
Ho 64 bit ma solo 1GiB di RAM e devo dirti che questa soluzione funziona! L'ho appena testato e dopo aver impostato i due parametri, non c'è più congelamento. :)
Mikhail Morfikov,

1
Nella mia installazione 14.04, uname -aritorna 3.13.0-32-generic, quindi sì. Ma non ho verificato se la patch per il problema fosse stata finalmente integrata nel kernel o meno. Ho una macchina da 16 GB e sembra funzionare bene senza la soluzione alternativa, anche se devo dire che non ho provato con dispositivi particolarmente lenti.
Rmano,

1
@ IonicăBizău --- che è uno pseudo-file, non modificarlo vim mai . Ottieni una shell di root (con sudo -i) e usa i comandi di cui sopra.
Rmano,

1
@Rmano Ha funzionato! Tuttavia, l'ho modificato con VIM. Grazie!
Ionică Bizău,

2
Sto usando Ubuntu 16.04 su un laptop nuovo di zecca (con 16 GB di RAM). Ero davvero arrabbiato per questo problema. La tua soluzione ha funzionato come un fascino! Forse potresti aggiungere che questo potrebbe essere ancora necessario con il kernel 4.8.0-45.
LGenzelis,

3

Il motivo può essere l'amplificazione in scrittura, poiché il sistema tenta di scrivere in blocchi più piccoli rispetto alla cancellazione del blocco (facendo lettura / mod / scrittura) + disallineamento del blocco.

Per verificare le impostazioni correnti, procedi come segue:

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

È possibile ottimizzare le regole di sala per tali dispositivi:

Modifica il valore di "max_sector" USB per un'intera famiglia di dispositivi

In questo caso avevo sostituito max_sector per tutti i dispositivi, che utilizzavano i valori predefiniti da 240 (archiviazione USB) a settori 32K o settori 2K.

Sul mio sistema (Mageia 4, 3.14.24 core i7) ho dovuto farlo a causa di velocità di scrittura terribilmente lente (2 MB / sec) su Kingston DT101 G2 16GB:

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

e aggiungi:

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

E la ddvelocità di scrittura è aumentata 3 volte. mc cpprobabilmente 10-20 volte (dopo che avevo avviato la prima partizione all'8192 ° settore e riformattato con cluster allineati a 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

per verificare l'allineamento (selezionare [settore avvio dati] deve essere multiplo di 128 (dimensione del cluster)). Regola il numero dei settori riservati (-R) se necessario.

I max_sector predefiniti (240) sembrano causare un'elevata amplificazione della scrittura su alcune delle nuove unità economiche. Ma fai molta attenzione con un'impostazione così alta, l'effetto simile si ottiene in 2048 settori (probabilmente blocchi di cancellazione 1M:

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

Metti alla prova tutti i tuoi vecchi dispositivi USB, che funzionino ancora bene. Utilizzare gli attributi fornitore / modello nei file delle regole per essere più specifici.


1

hardware vs. software

Mi sono imbattuto in uno strano problema simile a questo con le levette USB e nella mia ricerca è quasi sempre un problema di driver o l'hardware specifico all'interno del PC / scheda madre.

Lo so perché ho diversi sistemi che sono identici hardware e su uno posso fare questa operazione senza problemi, mentre su un altro si presenta il problema.

Cosa fare?

Le opzioni sono davvero limitate qui. Le uniche cose che puoi fare sono assicurarti di avere l'ultimo BIOS / firmware installato sul tuo sistema e assicurarti di avere le ultime versioni dei pacchetti di disto.

Oltre a tutto ciò che posso suggerire è assicurarmi di evitare questa situazione non tentando di copiare i file mentre è in corso un'altra copia.

Se hai il tipo di personalità in cui cose come questa ti infastidiscono, potresti provare un'altra distribuzione live di Linux e ripetere i passaggi che portano al tuo problema. Questo eliminerebbe semplicemente se si tratta di un problema specifico della distribuzione o di un problema hardware come ho descritto sopra. Sarebbe una piccola consolazione, ma mi piace sempre sapere le cose piuttosto che seppellire la testa nella sabbia, e non.

Qualunque altra cosa?

Se sei veramente ossessivo, potresti provare a eseguire l'applicazione con cui stai eseguendo la copia stracenella speranza di catturare il sistema in qualunque chiamata di sistema si blocchi. Dovresti essere in grado di farlo anche dalla riga di comando.

Esempio

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

Quindi mentre è in esecuzione inizia un altro.

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

Si spera che il sistema si blocchi durante questa operazione e forse sarai fortunato e troverai del fumo in uno di quei file di registro.


Uso sempre l'unica istanza di copia dei file. Ho aggiornato il BIOS (2008) e da allora non esiste una versione più recente. Penso che non sia il BIOS. La mia distro debian viene anche aggiornata al ramo di test. Ho provato a usarlo stracee ha iniziato a congelarsi quasi istantaneamente, quindi ho aspettato qualche secondo e ho ucciso il processo. Ho un registro da 1 Mb, ma non riesco a leggerlo, non so cosa cercare. Puoi controllarlo qui pastebin.com/u29RvqgC - non è il registro completo (limitato a 500 KB), ma c'erano solo linee simili a quelle alla fine. Proverò a riprodurre questo problema con ubuntu live cd.
Mikhail Morfikov,

Ho aggiornato la domanda relativa ai test cd live.
Mikhail Morfikov,

@MikhailMorfikov - Penso che tu sia praticamente alla fine di quello che puoi aspettarti di fare. Il tuo hardware è piuttosto vecchio (2008) e non c'è molto altro che puoi fare oltre a quello che ho descritto sopra.
slm

Ma anche i PC più vecchi sono in grado di copiare i file senza problemi.
Mikhail Morfikov,

@MikhailMorfikov - L'età non è l'unico fattore, ma la probabilità che si verifichino aggiornamenti di firmware o aggiornamenti di software per hardware vecchio è bassa, è ciò che intendevo dire.
slm
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.