Intente ionizar o mejorar el proceso de copia. El problema se debe al hecho de que IO tiene la misma prioridad que la GUI, lo que para un escritorio afecta la capacidad de respuesta percibida.
Hay una lluvia de ideas de Ubuntu sobre esto actualmente.
Linux ha tenido durante mucho tiempo un problema con los programas que acaparan toda la memoria caché "sucia" del sistema. Lo que sucede es que el proceso de copia está llenando el caché de escritura con los datos del archivo que está copiando y lo está haciendo muy rápido. Entonces, cuando aparece Firefox y necesita escribir, primero debe esperar a que haya espacio de búfer sucio o una ranura de escritura de cola de disco disponible. Mientras espera, compite con el proceso de copia y el subproceso pdflush del núcleo, que mueve los datos de los búferes sucios a la cola de escritura del disco.
Firefox tiene otro problema en este escenario. Utiliza SQLite para almacenar sus marcadores, historial y otras cosas. SQLite es una base de datos compatible con ACID y utiliza un sistema de transacciones con sus escrituras en disco descargadas en el disco . Por lo tanto, no solo tiene que esperar por el espacio del búfer, sino que también debe esperar a que la cola del disco, que está llena de archivos copiados, se borre antes de que pueda reconocer una escritura exitosa.
Ha habido mucho de ajustes realizados en el sistema de almacenamiento en búfer y cola de disco de Linux. Hay cambios en casi todas las versiones del kernel. Pruebe una de las versiones más recientes. También puede intentar ajustar los valores de sysctl. Me gustan estos:
vm.dirty_writeback_centisecs = 100
vm.dirty_expire_centisecs = 9000
vm.dirty_background_ratio = 4
vm.dirty_ratio = 80
También puede intentar ajustar la cantidad de ranuras en la cola del disco. Este valor está en /sys/block/sda/queue/nr_requests . Necesitas sustituir sda con lo que realmente sea su impulso. Más ranuras significan más posibilidades de fusionar solicitudes de E/S y el programador de E/S de CFQ puede hacer un mejor trabajo con las prioridades. Menos ranuras generalmente significa una espera más corta para escribir en el disco para IO síncrono como las transacciones de SQLite. Menos ranuras también significa una espera más corta para obtener E/S de lectura en la cola del disco si un proceso de escritura pesada llena completamente la cola con E/S de escritura.