¿Por qué al copiar a una unidad externa la ventana de progreso no es correcta?


11

Siéntase libre de editar el título para explicar mejor lo que voy a escribir aquí.

Cuando copio archivos grandes en un pen drive, por ejemplo, la ventana de progreso muestra una estimación de que la mayoría de las veces no deja de mostrar el tiempo real y el porcentaje para terminar, pero hay casos en los que dice que todo ha terminado y la ventana de progreso cierra Voy a extraer el pen drive y dice que todavía está en uso. Después de verificar el pen drive, veo que todavía está copiando los archivos, pero no hay una ventana de progreso que lo muestre.

No solo ocurre con archivos grandes, también sucede con muchos archivos pequeños. Si los copio, la barra de progreso podría decir 15 segundos, por ejemplo, y terminar en ese tiempo, pero el tiempo real podría ser de 1 minuto y durante los siguientes 45 segundos necesito mirar la luz en el pen drive para ver si hay Es una actividad real en él.

No quiero saber cómo solucionarlo, ya que he leído qué tan profundo podría ser una solución para esto. Lo que quiero saber es por qué entonces la ventana de progreso muestra una estimación que no corresponde con el proceso de copia.

¿Depende de la caché en la unidad externa?

Es el tamaño del archivo y la cantidad de influencia del archivo en la estimación correcta. Por ejemplo 1 archivo de 4 GB o 1000 archivos de 4 MB.

¿Hay opciones de configuración que pueden cambiar el comportamiento?

Hay otras preguntas similares a esta, como copiar archivos a una memoria USB nunca finalizada, pero estoy más centrado en la mecánica de por qué se comportaría así.

Respuestas:


6

Supongo que está utilizando Nautilus como su administrador de archivos y, de ser así, existen errores de larga data al respecto. Demasiado numinoso para mencionar que afecta a Mint, Fedora, Red Hat y todo lo demás. Ubuntu no está exento de este mismo problema.

Algunos sugieren que desactivar la vista en miniatura ayuda. Otros ponen sus esperanzas en el "núcleo más nuevo", pero esto todavía existe.

El problema = Comienza rápido, luego va más lento Esto se debe a que cuando se monta con asíncrono, escribirá en el caché, cuando el caché esté lleno, verá la velocidad de escritura "Real".

El trabajo alrededor parece ser sudo cp /filetobecopied /dev/nameofdevice

otro publicado aquí dice que "copiar en trozos" funciona. Sin confirmar de mi parte.


3
Para aclarar, el núcleo almacena en caché los datos en la RAM en lugar de escribirlos directamente (por razones de rendimiento). Cuando hace clic en Expulsar, syncse ejecuta un comando en segundo plano, que vacía el caché. Para grandes cantidades de datos, esto puede llevar un tiempo.
treinta

1
SUGERENCIA: sudo cp / filetobecopied / dev / nameofdevice reemplazará todo el sistema de archivos con su archivo, por lo general no lo que desea ...
Lennart Rolland

1

Esta también es una buena respuesta con una solución: /unix//a/181236 Dice:

La razón por la que sucede de esa manera es que el programa dice "escribir estos datos" y el kernel de Linux los copia en un búfer de memoria que está en cola para ir al disco, y luego dice "ok, hecho". Entonces el programa piensa que ha copiado todo. Luego, el programa cierra el archivo, pero de repente el kernel lo hace esperar mientras ese búfer se expulsa al disco.

Entonces, desafortunadamente, el programa no puede decirle cuánto tiempo tomará vaciar el búfer porque no lo sabe.

Si desea probar algunos trucos para usuarios avanzados, puede reducir el tamaño del búfer que utiliza Linux configurando / proc / sys / vm / dirty_bytes en algo así como 15728640 (15 MB). Esto significa que la aplicación no puede obtener más de 15 MB antes de su progreso real.

Un efecto secundario es que su computadora puede tener un rendimiento de escritura de datos más bajo con esta configuración, pero en general, me resulta útil ver que un programa se ejecuta durante mucho tiempo mientras escribe muchos datos frente a la confusión de tener un El programa parece estar hecho con su trabajo, pero el sistema está muy retrasado ya que el núcleo hace el trabajo real. Establecer "dirty_bytes" en un valor razonablemente pequeño también puede ayudar a evitar que su sistema deje de responder cuando tenga poca memoria libre y ejecute un programa que de repente escribe muchos datos.

¡Pero no lo configure demasiado pequeño! Utilizo 15 MB como una estimación aproximada de que el núcleo puede vaciar el búfer a un disco duro normal en 1/4 de segundo o menos. Evita que mi sistema se sienta "lento".

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.