¿Por qué mi PC se congela mientras copio un archivo en un pendrive?

Tengo una situación realmente extraña aquí. Mi PC funciona bien, al menos en la mayoría de los casos, pero hay una cosa con la que no puedo lidiar. Cuando trato de copiar un archivo de mi pendrive, todo está bien: obtuve 16-19M / s, funciona bastante bien. Pero cuando trato de copiar algo en el mismo pendrive, mi PC se congela. El puntero del mouse deja de moverse durante un segundo o dos, luego se mueve un poco y se detiene nuevamente. Cuando algo suena, por ejemplo, en Amarok, el sonido actúa como una ametralladora. La velocidad salta de 500K / sa 15M / s, un promedio de 8M / s. Esto ocurre solo cuando estoy copiando algo en un pendrive. Cuando finaliza el proceso de copia, todo vuelve a la normalidad.

Intenté todo: otro pendrive, un puerto USB diferente en el panel frontal o esos puertos desde la parte posterior, incluso cambié los pines USB en la placa base (panel frontal), pero no importa dónde coloque mi memoria USB, siempre es lo mismo. Probé sistema de ficheros distinto - fat32, ext4. No tengo ningún problema con el dispositivo en Windows, en mi computadora portátil. Tiene que ser mi PC o algo en mi sistema. No tengo idea de qué buscar. Estoy usando las pruebas de Debian con Openbox independiente. Mi PC es algo antigua: Pentium D 3GHz, 1GiB de RAM, 1,5TB WD Green en disco. Si tiene algo que me ayudaría a resolver este problema, me alegraría saberlo.

No sé qué otra información debo proporcionar, pero si necesita algo, solo pregunte, actualizaré esta publicación lo antes posible.

Traté de reproducir este problema en ubuntu 13.04 live cd. Monté mi partición encriptada + intercambio encriptado y conecté mi pendrive a un puerto usb. Luego intenté iniciar algunas aplicaciones, y ahora tengo ~ 820MiB en RAM y aproximadamente 400MiB en SWAP. No hay problema con la copia, no se congela en absoluto, todo es como debería ser. Entonces, parece que es una falla del sistema, pero ¿dónde exactamente? ¿Qué causaría un comportamiento tan extraño?

¿Estás utilizando una versión de Linux de 64 bits con mucha memoria? En ese caso, el problema podría ser que Linux puede bloquearse durante minutos en grandes escrituras en dispositivos lentos como, por ejemplo, tarjetas SD o memorias USB. Es un error conocido que debería corregirse en los núcleos más nuevos.

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

Solución alternativa: como problema raíz:

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

Lo he agregado a mi /etc/rc.localarchivo en mis máquinas de 64 bits.

TANSTAAFL ; Este cambio puede (y probablemente lo hará) reducir su rendimiento a estos dispositivos --- es un compromiso entre la latencia y la velocidad. Para volver al comportamiento anterior puedes

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

... que son los valores predeterminados, lo que significa que el comportamiento de reescritura estará controlado por los parámetros dirty_ratioy dirty_background_ratio.

Nota para las personas no tan expertas con Linux: los archivos /proc son pseudofiles, solo canales de comunicación entre el núcleo y el espacio del usuario. Nunca use un editor para cambiarlos o mirarlos; obtenga en su lugar un indicador de shell --- por ejemplo, con sudo -i(sabores de Ubuntu) o su rooty use echoy cat).

Actualización 2016/04/18 parece que, después de todo, el problema todavía está aquí. Puede verlo en LWN.net , en este artículo sobre colas de reescritura .

La razón puede ser la amplificación de escritura, ya que el sistema intenta escribir en fragmentos que son más pequeños, que borrar bloque (haciendo lectura / mod / escritura) + desalineación de bloque.

Para verificar su configuración actual, haga lo siguiente:

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

Puede ajustar las reglas de pasillo para esos dispositivos:

Cambiar el valor de USB "max_sectors" para toda una familia de dispositivos

En este caso, reemplacé max_sectors para todos los dispositivos, que usaban el valor predeterminado de 240 (almacenamiento USB) en sectores de 32K o 2K.

En mi sistema (Mageia 4, 3.14.24 core i7) tuve que hacer esto debido a velocidades de escritura terriblemente lentas (2MB / seg) en Kingston DT101 G2 16GB:

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

y añadir:

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

Y la ddvelocidad de escritura subió 3 veces. mc cpprobablemente 10-20x arriba (después de haber comenzado la primera partición en el sector 8192 y reformatear con 64k grupos alineados):

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

para verificar la alineación (verificar [sector de inicio de datos] debe ser múltiplo de 128 (tamaño del clúster)). Ajuste el número de sectores reservados (-R) si es necesario.

Los max_sectors predeterminados (240) parecen causar una gran amplificación de escritura en algunas de las nuevas unidades baratas. Pero tenga mucho cuidado con una configuración tan alta, el efecto similar se logra en 2048 sectores (probablemente bloques de borrado de 1M:

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

Pruebe todos sus dispositivos USB antiguos, que todavía funcionan bien. Utilice los atributos de proveedor / modelo en los archivos de reglas para ser más específico.

hardware versus software

Me he encontrado con un problema extraño similar a este con las unidades de memoria USB, y en mi investigación casi siempre es un problema de controlador o el hardware específico dentro de la PC / Motherboard.

Sé esto porque tengo varios sistemas que son hardware idéntico, y en uno, puedo hacer esta operación sin problemas, mientras que en otro aparece el problema.

¿Qué hacer?

Sus opciones son realmente limitadas aquí. Las únicas cosas que puede hacer son asegurarse de tener el último BIOS / firmware instalado en su sistema y asegurarse de tener las últimas versiones de los paquetes de su disto.

Más allá de eso, todo lo que puedo sugerir es que se asegure de evitar esta situación al no intentar copiar archivos mientras otra copia está en progreso.

Si tienes el tipo de personalidad donde te molestan cosas como esta, puedes probar otra distribución en vivo de Linux y repetir los pasos que conducen a tu problema. Esto simplemente eliminaría si se trata de un problema específico de la distribución o un problema de hardware como he descrito anteriormente. Sería un pequeño consuelo, pero siempre me gusta saber cosas en lugar de enterrar mi cabeza en la arena, y no.

¿Algo más?

Si eres realmente obsesivo, puedes intentar ejecutar la aplicación con la que estás haciendo la copia con stracela esperanza de atrapar el sistema en cualquier llamada del sistema que se esté congelando. También deberías poder hacerlo desde la línea de comandos.

Ejemplo

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

Luego, mientras se está ejecutando, comience otro.

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

Con suerte, el sistema se congelará durante esta operación y tal vez tenga suerte y encuentre algo de humo en cualquiera de esos archivos de registro.