Prova a ionizzare o perfezionare il processo di copia. Il problema è dovuto al fatto che l'IO ha la stessa priorità della GUI, che per un desktop influisce sulla reattività percepita.
C'è un brainstorming su Ubuntu al momento.
Linux ha avuto a lungo un problema con i programmi che monopolizzano tutta la memoria cache "sporca" del sistema. Quello che sta succedendo è che il processo di copia sta riempiendo la cache di scrittura con i dati del file che sta copiando e lo sta facendo molto rapidamente. Quindi, quando Firefox arriva e deve scrivere, deve prima attendere lo spazio del buffer sporco o uno slot di scrittura della coda del disco disponibile. Durante l'attesa è in competizione con il processo di copia e il thread pdflush del kernel, che sposta i dati dai buffer sporchi alla coda di scrittura del disco.
Firefox ha ancora un altro problema in questo scenario. Usa SQLite per memorizzare i suoi segnalibri, la cronologia e altre cose. SQLite è un database conforme ad ACID e utilizza un sistema di transazioni con le sue scritture su disco scaricate su disco . Quindi non solo deve attendere lo spazio del buffer, ma deve anche attendere che la coda del disco, che è piena di file copiati, venga cancellata prima di poter riconoscere una scrittura riuscita.
Ce n'è stato molto delle modifiche apportate al sistema di accodamento e buffering del disco di Linux. Ci sono modifiche in quasi tutte le versioni del kernel. Prova una delle versioni più recenti. Puoi anche provare a modificare i valori sysctl. Mi piacciono un po' questi:
vm.dirty_writeback_centisecs = 100
vm.dirty_expire_centisecs = 9000
vm.dirty_background_ratio = 4
vm.dirty_ratio = 80
Puoi anche provare a modificare il numero di slot nella coda del disco. Questo valore è in /sys/block/sda/queue/nr_requests . Devi sostituire sda con qualunque sia la tua guida. Più slot significano più possibilità di unire le richieste IO e lo scheduler CFQ IO può fare un lavoro migliore con le priorità. Meno slot di solito significano un'attesa più breve per essere scritti su disco per IO sincroni come le transazioni di SQLite. Meno slot significa anche un'attesa più breve per ottenere l'IO di lettura nella coda del disco se un processo pesante in scrittura riempie completamente la coda con l'IO di scrittura.