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


61

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?


Cuando encontré algo similar a esto fue porque tenía problemas con el disco duro en mi computadora portátil. El disco tenía algunas áreas malas y cada vez que intentaba leer algo de esas áreas se congelaba hasta que estaba listo. Solo una idea a tener en cuenta. Tal vez tienes sectores defectuosos de los que estás tratando de leer.
slybloty

Mi disco duro está bien, al menos inteligente decirlo (después de la exploración completa).
Mikhail Morfikov

Intente reducir la prioridad IO del proceso de copia, por ejemplo ionice -c3 cp something.tgz /media/pendrive. Esto colocará el cpproceso recién generado en la tercera (= más baja) clase de prioridad "inactivo".
n.st

Intenté esto, pero no tiene ningún efecto.
Mikhail Morfikov

@MikhailMorfikov FYI, este problema se abordó en Linux 4.9. Todavía no he probado la solución yo mismo. YMMV.
Seamus Connor

Respuestas:


85

¿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 .


3
Tengo 64 bits pero solo 1GiB de RAM, ¡y debo decirle que esta solución funciona! Lo acabo de probar y, después de configurar los dos parámetros, ya no hay congelación. :)
Mikhail Morfikov

1
En mi instalación 14.04, uname -aregresa 3.13.0-32-generic, así que sí. Pero no he comprobado si el parche para el problema finalmente se integró en el núcleo o no. Tengo una máquina de 16 GB y parece funcionar bien sin la solución, aunque tengo que decir que no lo intenté con dispositivos especialmente lentos.
Rmano

1
@ IonicăBizău --- que es un pseudoarchivo, no lo edite vim nunca . Obtenga un shell raíz (con sudo -i) y use los comandos antes mencionados.
Rmano

1
@Rmano ¡Funcionó! Sin embargo, lo edité con VIM. ¡Gracias!
Ionică Bizău

2
Estoy usando ubuntu 16.04 en una computadora portátil nueva (con 16 GB de RAM). Estaba realmente enojado con este problema. ¡Tu solución funcionó de maravilla! Tal vez podría agregar que esto aún podría ser necesario con el kernel 4.8.0-45.
LGenzelis

3

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.


1

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.


Siempre uso la única instancia de copia de archivos. Tengo BIOS actualizado (2008), y no hay una versión más nueva desde entonces. Creo que no es el BIOS. Mi distribución de Debian también se actualiza a la rama de prueba. Intenté usarlo stracey comenzó a congelarse casi instantáneamente, así que esperé unos segundos y terminé el proceso. Tengo un registro de 1Mb, pero no puedo leerlo, no sé qué buscar. Puede verificarlo aquí pastebin.com/u29RvqgC : no es el registro completo (limitado a 500 Kb), pero solo había líneas similares a las del final. Intentaré reproducir este problema con ubuntu live cd.
Mikhail Morfikov

Actualicé la pregunta en cuanto a las pruebas de CD en vivo.
Mikhail Morfikov

@MikhailMorfikov - Creo que estás al final de lo que puedes esperar hacer. Su hardware es bastante antiguo (2008) y realmente no hay mucho más que pueda hacer más allá de lo que he descrito anteriormente.
slm

Pero incluso las PC más antiguas pueden copiar archivos sin problemas.
Mikhail Morfikov

@MikhailMorfikov - La edad no es el único factor, pero lo que quise decir es que la posibilidad de obtener actualizaciones de firmware o actualizaciones de software para hardware antiguo es baja.
slm
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.