¿Hay que esperar para extraer un pen? (SOLUCIONADO)

Foro de soporte para usuarias de habla hispana

Moderator: Wibol

Forum rules
Topics in this forum are automatically closed 6 months after creation.
User avatar
linux123
Level 5
Level 5
Posts: 605
Joined: Thu Sep 03, 2015 6:43 am
Contact:

¿Hay que esperar para extraer un pen? (SOLUCIONADO)

Post by linux123 »

Hola.
Cuando he copiado un archivo grande a un pen y le doy extraer, tengo que esperar unos segundo desde que sale "el dispositivo fue retirado" hasta que me dice "ahora puede extraer..." ¿Por qué es esto? Al parecer debo esperar más cuanto más grande sea el archivo. Si no lo hago el archivo se rompe. ¿Alguna idea?

Mint 18 cinnamon.

Saludos.
Last edited by LockBot on Wed Dec 28, 2022 7:16 am, edited 2 times in total.
Reason: Topic automatically closed 6 months after creation. New replies are no longer allowed.
User avatar
Wibol
Level 6
Level 6
Posts: 1300
Joined: Fri Nov 27, 2015 7:00 am
Location: España

Re: ¿Hay que esperar para extraer un pen?

Post by Wibol »

Investigando sobre el tema he leido que algunas BIOS/UEFI llevan el ajuste que se observa en la línea superior:

Image

También podría estar realcionado con el modo de emulación usado (FFD/HDD).
Image

No olvides:
  • Leer la Guía de publicación antes de hacer una consulta.
  • Añadir [SOLUCIONADO] al título del primer mensaje de tu consulta cuando así lo consideres.
User avatar
JCSenar
Level 11
Level 11
Posts: 3646
Joined: Sat Sep 06, 2014 6:26 pm
Location: Irun, España
Contact:

Re: ¿Hay que esperar para extraer un pen?

Post by JCSenar »

mmmmm.... Yo uso indicator-usb para ello. Apenas tiene retardo a la hora de expulsar un pendrive.
Si tu consulta ha sido resuelta, por favor, edita tu primer mensaje y añade [SOLUCIONADO] al título. Gracias.
User avatar
linux123
Level 5
Level 5
Posts: 605
Joined: Thu Sep 03, 2015 6:43 am
Contact:

Re: ¿Hay que esperar para extraer un pen?

Post by linux123 »

Lo de la BIOS, nada. Indicator-usb, tampoco :cry:
Solo me queda lo de HDD o FFD, ¿que hago con eso?
La verdad es que es muy muy incómodo esto, al parecer "hay una operación pendiente", o al menos eso dice si tras darle a extraer le vuelvo a dar a montar. :?: :!:

Gracias.
Saludos.
User avatar
Wibol
Level 6
Level 6
Posts: 1300
Joined: Fri Nov 27, 2015 7:00 am
Location: España

Re: ¿Hay que esperar para extraer un pen?

Post by Wibol »

La única diferencia que se me ocurre entre los modos FCC y HDD es que el primero habilite la caché de escritura y el segundo no, debido a que los disquetes se pueden extraer en cualquier momento sin causar daños a los datos pero los discos duros no.

Podría estar pasando que al pulsar el botón "Extraer", el sistema comience a grabar el contenido de la caché al pendrive antes de su expulsión y sea esto lo que demora la aparición del cartel "Es seguro retirar el hardware"
Image

No olvides:
  • Leer la Guía de publicación antes de hacer una consulta.
  • Añadir [SOLUCIONADO] al título del primer mensaje de tu consulta cuando así lo consideres.
User avatar
JCSenar
Level 11
Level 11
Posts: 3646
Joined: Sat Sep 06, 2014 6:26 pm
Location: Irun, España
Contact:

Re: ¿Hay que esperar para extraer un pen?

Post by JCSenar »

linux123 wrote:Hola.
Cuando he copiado un archivo grande a un pen y le doy extraer, tengo que esperar unos segundo desde que sale "el dispositivo fue retirado" hasta que me dice "ahora puede extraer..." ¿Por qué es esto? Al parecer debo esperar más cuanto más grande sea el archivo. Si no lo hago el archivo se rompe. ¿Alguna idea?
He copiado un archivo de 1,9 gb. a un pendrive y utilizando indicator-usb han pasado 2 segundos (cronometrados) desde que le he dado a "Expulsar" hasta que ha aparecido el mensaje "Device can be removed now". ¿A tí te darda más? ¿Cuanto más?

No se, sin duda mejor sería que fuera inmediato pero, personalmente, no me parece reseñable.
Si tu consulta ha sido resuelta, por favor, edita tu primer mensaje y añade [SOLUCIONADO] al título. Gracias.
User avatar
linux123
Level 5
Level 5
Posts: 605
Joined: Thu Sep 03, 2015 6:43 am
Contact:

Re: ¿Hay que esperar para extraer un pen?

Post by linux123 »

Minutos, minutos, minutos, cuartos de hora, etc.
User avatar
JCSenar
Level 11
Level 11
Posts: 3646
Joined: Sat Sep 06, 2014 6:26 pm
Location: Irun, España
Contact:

Re: ¿Hay que esperar para extraer un pen?

Post by JCSenar »

linux123 wrote:Minutos, minutos, minutos, cuartos de hora, etc.
Pues sí, eso es mucho. ¿Y te ha empezado a pasar recientemente o desde siempre? Por que mires a ver si has hecho algún cambio reciente, etc...
Si tu consulta ha sido resuelta, por favor, edita tu primer mensaje y añade [SOLUCIONADO] al título. Gracias.
User avatar
linux123
Level 5
Level 5
Posts: 605
Joined: Thu Sep 03, 2015 6:43 am
Contact:

Re: ¿Hay que esperar para extraer un pen?

Post by linux123 »

Ha ocurrido ahora de repente. En el chat me están ayudando Wibol, Jopeta y algunos más a veces, a ver en qué acaba esto. Si tú sabes algo por supuesto puedes contestar.
Información: BIOS actualizada, probado desde live, limpiado los puertos, configurado algunas cosas en nemo, configuración de BIOS comprobada, etc.

Saludos.
jmarinho

Re: ¿Hay que esperar para extraer un pen?

Post by jmarinho »

Hola.

A mi también me pasa lo que a ti y he estado investigando sobre el tema, así que te voy a contar a ver si te ayuda en algo. Te envío también algún enlace de donde se explica el asunto para que saques tú también tus propias conclusiones porque, aunque yo saqué las mías, no soy un experto sino más bien un usuario curioso al que le gusta este tema. Además de lenguaje técnico los enlaces están en inglés con lo que no sé si estoy interpretando del todo bien todo esto.

El problema creo que está relacionado con los ajustes que trae el kernel por defecto y afecta sobre todo a equipos que tengan una buena cantidad de memoria RAM. El problema viene explicado aquí: https://lwn.net/Articles/572911/ . Y la solucion al probelma aquí: http://unix.stackexchange.com/questions ... 722#107722.

Yo lo he probado y funciona. En mi caso mi pc (12 GB de RAM) no se congela pero observo el mismo comportamiento que observas tú: cuando copio un archivo muy grande o muchos archivos pequeños que ocupan bastante tamaño, una vez que la barra de progreso se detiene como si terminara de copiar, le doy a extraer el pen y tarda mucho tiempo en decirme que está listo para ser desconectado. Probé con iotop, que es una utilidad para monitorizar los procesos de entrada y salida del ordenador (no viene por defecto hay que instalarla: sudo apt install iotop, y después lanzarla como superusuario: sudo iotop) y efectivamente comprobaba que el proceso de desmontar el pendrive (si ya le había dado a expulsar) o el proceso de copia de archivos seguía funcionando durante un buen rato despúes de que la barra de progreso de la copia de archivos se hubiese detenido.

Al hacer lo que sugiere el usuario Rmano en Unix&Linux Stackexchange que es añadir antes de la línea final (exit0) al archivo /etc/rc.local el siguiente contenido:

Code: Select all

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


Una vez que reinicias el comportamiento es el siguiente: la copia de archivos puede que parezca un poco más lenta, o sea, la barra de progreso en nemo no va tan rápido, pero una vez que la barra de progreso te dice que terminó el copiado de archivos y expulsas el pen puedes retirarlo al momento. Puedes comprobarlo con sudo iotop.

Por último, por lo que veo tienes Linux MInt 18 que viene ya con SystemD, con lo cual lo de añadir ese código a rc.local puede cambiar un poco. Yo ahora no puedo verlo porque solo tengo a mano un equipo con LM17, pero creo que en SystemD no existe rc.local con lo cual una solución es crearlo. Yo lo había hecho en Debian y funcionaba. Los pasos serían:

Code: Select all

sudo touch /etc/rc.d/rc.local
#añades el contenido del script
sudo chmod +x /etc/rc.d/rc.local
 
Con un editor de texto le pones este contenido:

Code: Select all

#!/bin/bash
echo $((16*1024*1024)) > /proc/sys/vm/dirty_background_bytes
echo $((48*1024*1024)) > /proc/sys/vm/dirty_bytes
exit 0
Lo inicias:

Code: Select all

sudo systemctl start rc-local.service
Y para comprobar si está funcionando:

Code: Select all

sudo systemctl status rc-local.service
Esto último lo saqué de aquí: https://ask.fedoraproject.org/en/questi ... e-rclocal/

Prueba a ver que tal, creo que puede ser una solución al problema
Last edited by jmarinho on Mon Dec 12, 2016 1:20 pm, edited 1 time in total.
User avatar
hatteras
Level 11
Level 11
Posts: 3884
Joined: Fri Sep 24, 2010 6:43 pm
Location: En el paraiso en la tierra
Contact:

Re: ¿Hay que esperar para extraer un pen?

Post by hatteras »

¿ Y simplemente montar la partición del pendrive con la opción sync en el archivo /etc/fstab ?

sync: Es la opción contraria a async. Añadiendo la opción sync fijaríamos que los datos sean transferidos, guardados o borrados, en el momento en que pedimos que se hagan. Esta opcion puede servir de mucho, y sobre todo ahorrarnos tiempo en la manera en la que se transfieren datos a dispositivos como los pen-drives y aquellos que se utilizan mediante conexión usb en los cuales necesitamos acceso/transferencia rapido/a.
Todos somos muy ignorantes. Pero no todos ignoramos las mismas cosas.
Es un placer ayudar, y ver que a alguien le es útil.
Es un placer pedir ayuda y ver que alguien te la da desinteresadamente.
User avatar
linux123
Level 5
Level 5
Posts: 605
Joined: Thu Sep 03, 2015 6:43 am
Contact:

Re: ¿Hay que esperar para extraer un pen?

Post by linux123 »

jmarinho wrote:Hola.

A mi también me pasa lo que a ti y he estado investigando sobre el tema, así que te voy a contar a ver si te ayuda en algo. Te envío también algún enlace de donde se explica el asunto para que saques tú también tus propias conclusiones porque, aunque yo saqué las mías, no soy un experto sino más bien un usuario curioso al que le gusta este tema. Además de lenguaje técnico los enlaces están en inglés con lo que no sé si estoy interpretando del todo bien todo esto.

El problema creo que está relacionado con los ajustes que trae el kernel por defecto y afecta sobre todo a equipos que tengan una buena cantidad de memoria RAM. El problema viene explicado aquí: https://lwn.net/Articles/572911/ . Y la solucion al probelma aquí: http://unix.stackexchange.com/questions ... 722#107722.

Yo lo he probado y funciona. En mi caso mi pc (12 GB de RAM) no se congela pero observo el mismo comportamiento que observas tú: cuando copio un archivo muy grande o muchos archivos pequeños que ocupan bastante tamaño, una vez que la barra de progreso se detiene como si terminara de copiar, le doy a extraer el pen y tarda mucho tiempo en decirme que está listo para ser desconectado. Probé con iotop, que es una utilidad para monitorizar los procesos de entrada y salida del ordenador (no viene por defecto hay que instalarla: sudo apt install iotop, y después lanzarla como superusuario: sudo iotop) y efectivamente comprobaba que el proceso de desmontar el pendrive (si ya le había dado a expulsar) o el proceso de copia de archivos seguía funcionando durante un buen rato despúes de que la barra de progreso de la copia de archivos se hubiese detenido.

Al hacer lo que sugiere el usuario Rmano en Unix&Linux Stackexchange que es añadir antes de la línea final (exit0) al archivo /etc/rc.local el siguiente contenido:

Code: Select all

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


Una vez que reinicias el comportamiento es el siguiente: la copia de archivos puede que parezca un poco más lenta, o sea, la barra de progreso en nemo no va tan rápido, pero una vez que la barra de progreso te dice que terminó el copiado de archivos y expulsas el pen puedes retirarlo al momento. Puedes comprobarlo con sudo iotop.

Por último, por lo que veo tienes Linux MInt 18 que viene ya con SystemD, con lo cual lo de añadir ese código a rc.local puede cambiar un poco. Yo ahora no puedo verlo porque solo tengo a mano un equipo con LM17, pero creo que en SystemD no existe rc.local con lo cual una solución es crearlo. Yo lo había hecho en Debian y funcionaba. Los pasos serían:

Code: Select all

sudo touch /etc/rc.d/rc.local
#añades el contenido del script
sudo chmod +x /etc/rc.d/rc.local
 
Con un editor de texto le pones este contenido:

Code: Select all

#!/bin/bash
echo $((16*1024*1024)) > /proc/sys/vm/dirty_background_bytes
echo $((48*1024*1024)) > /proc/sys/vm/dirty_bytes
exit 0
Lo inicias:

Code: Select all

sudo systemctl start rc-local.service
Y para comprobar si está funcionando:

Code: Select all

sudo systemctl status rc-local.service
Esto último lo saqué de aquí: https://ask.fedoraproject.org/en/questi ... e-rclocal/

Prueba a ver que tal, creo que puede ser una solución al problema
Muchíiiiiiisimas gracias a todos, ¡por fin lo he podido solucionar con este método!
Aunque a pesar de tener systemd, el archivo rc.local ya existía, por lo que no he tenido que crearlo.

Si dices que pasa en en equipos con mucha RAM, tal vez por eso que nunca me pasó con el otro (el de mint 17.2), porque solo eran 2GB, pero este son 8GB.

Lo dicho, muchísimas gracias a todos.
Saludos.
jmarinho

Re: ¿Hay que esperar para extraer un pen?

Post by jmarinho »

De nada. Me alegro de que te haya servido.
Para mi, esto es algo que se debería hacer en cualquier equipo con una buena cantidad de RAM al que le instales una distribución GNU/Linux.

Saludos
User avatar
JCSenar
Level 11
Level 11
Posts: 3646
Joined: Sat Sep 06, 2014 6:26 pm
Location: Irun, España
Contact:

Re: ¿Hay que esperar para extraer un pen?

Post by JCSenar »

JOPETA wrote:Me habría gustado, o si es posible hacerlo aún, que tanto jmarinho como linux 123 "acotaran" un poco el problema con datos del equipo. En ambos casos el resultado de inxi -Fxzn, confirmaría la existencia de algunas coincidencias (procesador, marca modelo, BIOS, años de fabricación. kernel,...) En fín, algo más terrenal con lo que trabajar, por ejemplo de ser una regresión que kernels están implicados.
Si tu consulta ha sido resuelta, por favor, edita tu primer mensaje y añade [SOLUCIONADO] al título. Gracias.
jmarinho

Re: ¿Hay que esperar para extraer un pen?

Post by jmarinho »

Por mi parte no hay problema. Lo que pasa es que creo que el problema está en Linux, el kernel, más que en nuestros equipos: si echais un ojo a https://lwn.net/Articles/572911/(si se os hace difícil en inglés, traduciéndolo con Google Translate creo que se entiende bastante bien) habla de un problema del núcleo del cual el escritor dice que Linus (supongo que Torvals) es consciente. Os pongo un extracto traducido por Google:
Linus fue rápido para entender lo que estaba pasando aquí. Todo se reduce al problema de igualar la velocidad a la que un proceso crea memoria sucia a la velocidad a la que se puede escribir esa memoria en el dispositivo de almacenamiento subyacente. Si a un proceso se le permite ensuciar una gran cantidad de memoria, el núcleo se verá comprometido a escribir un fragmento de datos que podrían tardar unos minutos en transferirse al almacenamiento persistente. Todos esos datos obstruyen las colas de E / S, posiblemente retrasando otras operaciones. Y, tan pronto alguien llama a sync (), las cosas se detienen hasta que se escribe toda la cola. Es un almacenamiento equivalente al problema bufferbloat.
En el enlace que puse a Unix Stack Exchange, (http://unix.stackexchange.com/questions ... 722#107722) el usuario Rmano que dió la solución que a mi y parece que también a linux123 nos va bien, puso una actualización en la que indica que el problema aún persiste y enlaza otro artículo, (https://lwn.net/Articles/682582/) que aún no me he leído, pero que termina así (creo que lo que viene antes más o menos viene a decir que están probando posibles soluciones):
Se trata de un conjunto de parches de etapas tempranas; No se espera que vaya río arriba en el futuro cercano. Los parches que cambian el comportamiento de administración de memoria a menudo pueden causar problemas inesperados con cargas de trabajo diferentes, por lo que tarda un tiempo en generar confianza en un cambio significativo, incluso después de que el trabajo de desarrollo se considera completo (lo que no ocurre aquí). De hecho, Dave Chinner ya ha informado de una regresión de rendimiento con una de sus cargas de trabajo de pruebas. La afinación de los límites de tamaño de la cola también debe hacerse automática si es posible. Es evidente que aún queda trabajo por hacer aquí; El conjunto de parches también es probable que sea un tema de discusión en el próximo Linux Storage, Filesystem y Memory-Management Summit. Así que los usuarios tendrán que esperar un poco más para que esta molestia particular sea abordada.
O sea: que están trabajando en ello.

Por último decir, que mi experiencia personal corrobora lo que apunté más arriba. En este ordenador desde el que escribo, he tenido instalado Ubuntu 12.04, Debian Jessie, Linux Mint 17 y ahora tengo Fedora (variedad de kernels y distribuciones, como podeis ver) y en todas me pasaba lo mismo. Siempre tuve problemas con pendrives cuando copiaba películas para ver en la tele. Al principio, cuando aún no era consciente del problema quitaba el pen antes de tiempo y me cargaba el sistema de ficheros, con lo cual al llegar a la televisión no me los leía. Desde que aplico este sistema, la copia se toma su tiempo en función de si el pendrive es más o menos rápido y, una vez que el diálogo de copia termina, puedo extraer el pen sin problemas (lo que no observo es que se me congele el sistema como dicen en los artículos, simplemente la copia se queda sin terminar y observo que, o bien el dialogo de copia termina pero al expulsar el pen tarda mucho en decirme que lo puedo sacar con seguridad, o bien el diálogo de copia se queda congelado en el último tramo sin avanzar por un buen rato). Por otra parte, no he observado que estos ajustes afecten negativamente al sistema (inestabilidad, etc).

Os paso la salida del comando que me pedís, por si quereis investigar, pero pienso que los tiros van más bien por donde apunté antes:

Code: Select all

inxi -Fxzn
System:    Host: localhost.localdomain Kernel: 4.8.12-300.fc25.x86_64 x86_64 (64 bit gcc: 6.2.1)
           Desktop: Gnome 3.22.2 Distro: Fedora release 25 (Twenty Five)
Machine:   Device: desktop Mobo: Gigabyte model: H61M-D2H-USB3
           BIOS: Award v: F7 date: 07/13/2012
CPU:       Quad core Intel Core i5-3570 (-MCP-) cache: 6144 KB
           flags: (lm nx sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx) bmips: 27137
           clock speeds: max: 3800 MHz 1: 3708 MHz 2: 3349 MHz 3: 3754 MHz
           4: 3786 MHz
Graphics:  Card: Intel Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller
           bus-ID: 00:02.0
           Display Server: Fedora X.org 119 driver: N/A
           Resolution: 1360x768@59.62hz
           GLX Renderer: Mesa DRI Intel Ivybridge Desktop
           GLX Version: 3.0 Mesa 13.0.2 Direct Rendering: Yes
Audio:     Card Intel 6 Series/C200 Series Family High Definition Audio Controller
           driver: snd_hda_intel bus-ID: 00:1b.0
           Sound: ALSA v: k4.8.12-300.fc25.x86_64
Network:   Card-1: Realtek RTL8192CE PCIe Wireless Network Adapter
           driver: rtl8192ce port: de00 bus-ID: 01:00.0
           IF: wlp1s0 state: up mac: <filter>
           Card-2: Qualcomm Atheros AR8151 v2.0 Gigabit Ethernet
           driver: atl1c v: 1.0.1.1-NAPI port: ef00 bus-ID: 05:00.0
           IF: enp5s0 state: down mac: <filter>
Drives:    HDD Total Size: 3000.6GB (58.5% used)
           ID-1: /dev/sda model: ST2000DM001 size: 2000.4GB temp: 22C
           ID-2: /dev/sdb model: ST1000DM003 size: 1000.2GB temp: 24C
Partition: ID-1: / size: 28G used: 8.9G (35%) fs: ext4 dev: /dev/sdb1
           ID-2: /home size: 881G used: 305G (37%) fs: ext4 dev: /dev/sdb2
           ID-3: swap-1 size: 10.00GB used: 0.00GB (0%) fs: swap dev: /dev/sdb3
RAID:      No RAID devices: /proc/mdstat, md_mod kernel module present
Sensors:   System Temperatures: cpu: 37.0C mobo: N/A
           Fan Speeds (in rpm): cpu: N/A
Info:      Processes: 221 Uptime: 6 min Memory: 1852.1/11932.9MB
           Init: systemd runlevel: 5 Gcc sys: 6.2.1
Mañana, si tengo tiempo haré pruebas en el ordenador del trabajo (lm17.3 con 8 Gb de RAM) al que no le cambié nada aún, porque la verdad es que no tengo necesidad, porque las pocas transferencias que hago a un pendrive son documentos de texto y poco más)
User avatar
JOPETA
Level 17
Level 17
Posts: 7762
Joined: Thu Nov 20, 2014 6:10 am
Location: En un lugar de cuyo nombre no quiero acordarme

Re: ¿Hay que esperar para extraer un pen?

Post by JOPETA »

jmarinho wrote:Lo que pasa es que creo que el problema está en Linux, el kernel, más que en nuestros equipos: si echais un ojo a https://lwn.net/Articles/572911/(si se os hace difícil en inglés, traduciéndolo con Google Translate creo que se entiende bastante bien) habla de un problema del núcleo del cual el escritor dice que Linus (supongo que Torvals) es consciente.
Si esa es la sospecha. También dicen en el desarrollo de los correos que Linus Torvald lo resuelve ya en el kernel 3.13. A eso me refiero con lo de las regresiones (problemas solucionados por kernels anteriores que reaparecen en otros más actuales) ya que en ocasiones se olvidan de incluir el parche que lo solucionaban. De hecho existe un vacío significativo de comentarios entre 2013 y el último del 2015.

Esperemos al aporte de Linux 123 para aclarar más cosas.
jmarinho

Re: ¿Hay que esperar para extraer un pen?

Post by jmarinho »

JOPETA wrote:
jmarinho wrote:Lo que pasa es que creo que el problema está en Linux, el kernel, más que en nuestros equipos: si echais un ojo a https://lwn.net/Articles/572911/(si se os hace difícil en inglés, traduciéndolo con Google Translate creo que se entiende bastante bien) habla de un problema del núcleo del cual el escritor dice que Linus (supongo que Torvals) es consciente.
Si esa es la sospecha. También dicen en el desarrollo de los correos que Linus Torvald lo resuelve ya en el kernel 3.13. A eso me refiero con lo de las regresiones (problemas solucionados por kernels anteriores que reaparecen en otros más actuales) ya que en ocasiones se olvidan de incluir el parche que lo solucionaban. De hecho existe un vacío significativo de comentarios entre 2013 y el último del 2015.

Esperemos al aporte de Linux 123 para aclarar más cosas.
Pues, acabo de probar en el ordenador del trabajo y por lo que vi, si que puede ser lo que tú dices (que haya alguna regresión en algunos núcleos)...

En este equipo copié a un pendrive bastante lento tres ISO'S de Linux Mint tanto con los ajustes de fábrica y con los ajustes que uso en el ordenador de casa y, en este caso, los resultados son similares: se toma su tiempo en hacer la copia (más o menos el mismo en ambos casos) y una vez termina el diálogo de copia puedes retirar el pendrive al momento ya que el proceso de copia de archivos termina totalmente. La única diferencia que veo es que con los ajustes de fábrica el diálogo de copia muestra al principio una velocidad de transferencia muy alta, que se va reduciendo, por ejemplo empieza señalando una transferencia de 30 Mb/s y 4 minutos restantes y va bajando poco a poco hasta quedar en 3 Mb/s y 20 min. Después se queda un buen rato al final en el 99% y 0 segundos restantes y cuando se cierra el diálogo de copia la transferencia de archivos termina totalmente (mirando en sudo iotop) y se puede extraer el fichero. Con los otros ajustes el diálogo de copia arranca con una velocidad de transferencia menor y no se reduce tan bruscamente y no se queda parado en nigún momento, pero por lo demás el tiempo que se toma en hacer la copia y el hecho de que finalice totalmente una vez que desaparece el diálogo de copia, pudiendo así extraer el pen al momento, es lo mismo en ambos casos.

Conclusión: si tienes el problema como linux123 o como yo en el ordenador de mi casa estos ajustes solucionan el problema. Si no lo tienes porque tu equipo no tiene mucha RAM o porque tengas un kernel que no tenga ese problema, déjalo tal cual viene.

Dejo la salida de inxi -Fxzn:

Code: Select all

System:    Host: conserxe-desktop Kernel: 3.19.0-73-generic x86_64 (64 bit gcc: 4.8.4)
           Desktop: Cinnamon 2.8.8 (Gtk 3.10.8~8+qiana)
           Distro: Linux Mint 17.3 Rosa
Machine:   Mobo: ASRock model: H110M-DGS
           Bios: American Megatrends v: P7.10 date: 10/19/2016
CPU:       Dual core Intel Core i3-6100 (-HT-MCP-) cache: 3072 KB
           flags: (lm nx sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx) bmips: 14784
           clock speeds: max: 3700 MHz 1: 800 MHz 2: 740 MHz 3: 3300 MHz
           4: 740 MHz
Graphics:  Card: Intel Sky Lake Integrated Graphics bus-ID: 00:02.0
           Display Server: X.Org 1.17.1 drivers: intel (unloaded: fbdev,vesa)
           Resolution: 1600x900@60.0hz
           GLX Renderer: Mesa DRI Intel Skylake DT GT2
           GLX Version: 3.0 Mesa 10.5.9 Direct Rendering: Yes
Audio:     Card Intel Sunrise Point-H HD Audio
           driver: snd_hda_intel bus-ID: 00:1f.3
           Sound: Advanced Linux Sound Architecture v: k3.19.0-73-generic
Network:   Card: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
           driver: r8169 v: 2.3LK-NAPI port: e000 bus-ID: 02:00.0
           IF: eth0 state: up speed: 1000 Mbps duplex: full mac: <filter>
Drives:    HDD Total Size: 407.9GB (16.1% used)
           ID-1: /dev/sda model: KINGSTON_SUV400S size: 240.1GB
           ID-2: /dev/sdb model: STM3160318AS size: 160.0GB
           ID-3: USB /dev/sdc model: TransMemory size: 7.8GB
Partition: ID-1: / size: 213G used: 54G (27%) fs: ext4 dev: /dev/sda1
           ID-2: swap-1 size: 8.26GB used: 0.00GB (0%) fs: swap dev: /dev/sda5
RAID:      No RAID devices: /proc/mdstat, md_mod kernel module present
Sensors:   System Temperatures: cpu: 23.0C mobo: N/A
           Fan Speeds (in rpm): cpu: N/A
Info:      Processes: 201 Uptime: 2:50 Memory: 3786.3/7680.2MB
           Init: Upstart runlevel: 2 Gcc sys: 4.8.4
           Client: Shell (bash 4.3.111) inxi: 2.2.28 
User avatar
linux123
Level 5
Level 5
Posts: 605
Joined: Thu Sep 03, 2015 6:43 am
Contact:

Re: ¿Hay que esperar para extraer un pen?

Post by linux123 »

Hola.
inxi -Fxzn

Code: Select all

System:    Host: pablo-HP-Notebook Kernel: 4.4.0-53-generic x86_64 (64 bit gcc: 5.4.0)
           Desktop: Cinnamon 3.0.7 (Gtk 3.18.9-1ubuntu3.1)
           Distro: Linux Mint 18 Sarah
Machine:   System: HP product: HP Notebook v: Type1ProductConfigId
           Mobo: HP model: 80CB v: 99.50 Bios: Insyde v: F.22 date: 07/25/2016
CPU:       Quad core AMD A8-7410 APU with AMD Radeon R5 Graphics (-MCP-) cache: 8192 KB
           flags: (lm nx sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm) bmips: 17565
           clock speeds: max: 2200 MHz 1: 1300 MHz 2: 2000 MHz 3: 1600 MHz
           4: 1000 MHz
Graphics:  Card: Advanced Micro Devices [AMD/ATI] Mullins [Radeon R4/R5 Graphics]
           bus-ID: 00:01.0
           Display Server: X.Org 1.18.3 drivers: ati,radeon (unloaded: fbdev,vesa)
           Resolution: 1366x768@60.32hz
           GLX Renderer: Gallium 0.4 on AMD MULLINS (DRM 2.43.0, LLVM 3.8.0)
           GLX Version: 3.0 Mesa 11.2.0 Direct Rendering: Yes
Audio:     Card-1 Advanced Micro Devices [AMD] FCH Azalia Controller
           driver: snd_hda_intel bus-ID: 00:14.2
           Card-2 Advanced Micro Devices [AMD/ATI] Kabini HDMI/DP Audio
           driver: snd_hda_intel bus-ID: 00:01.1
           Sound: Advanced Linux Sound Architecture v: k4.4.0-53-generic
Network:   Card-1: Broadcom BCM43142 802.11b/g/n driver: wl bus-ID: 02:00.0
           IF: wlo1 state: up mac: <filter>
           Card-2: Realtek RTL8101/2/6E PCI Express Fast/Gigabit Ethernet controller
           driver: r8169 v: 2.3LK-NAPI port: 2000 bus-ID: 03:00.0
           IF: enp3s0 state: down mac: <filter>
Drives:    HDD Total Size: 1000.2GB (16.1% used)
           ID-1: /dev/sda model: TOSHIBA_MQ01ABD1 size: 1000.2GB
Partition: ID-1: / size: 633G used: 149G (25%) fs: ext4 dev: /dev/sda1
           ID-2: swap-1 size: 2.20GB used: 0.00GB (0%) fs: swap dev: /dev/sda4
RAID:      No RAID devices: /proc/mdstat, md_mod kernel module present
Sensors:   System Temperatures: cpu: 45.0C mobo: 20.0C gpu: 44.0
           Fan Speeds (in rpm): cpu: N/A
Info:      Processes: 196 Uptime: 27 min Memory: 1187.8/6937.1MB
           Init: systemd runlevel: 5 Gcc sys: 5.4.0
           Client: Shell (bash 4.3.421) inxi: 2.2.35 
User avatar
linux123
Level 5
Level 5
Posts: 605
Joined: Thu Sep 03, 2015 6:43 am
Contact:

Re: ¿Hay que esperar para extraer un pen?

Post by linux123 »

Perdonad, olvidé marcar como solucionado :oops:
fjal

Re: ¿Hay que esperar para extraer un pen? (SOLUCIONADO)

Post by fjal »

Buenos días,

Yo también sufro estos problemas con las memorias USB de gran capacidad al copiar gran cantidad de archivos...

(comparaba la copia, con respecto a W7 y ahora con W10 y tardaba una eternidad)

había escrito algún comentario anteriormente y no veía solución, puede que pronto se solucione... en el kernel....

o modificaré como dicen ustedes esos ficheros...

Se va viendo la luz del problema.

Les dejo una copia de mi sistema con... inxi -Fxzn

Code: Select all

toshiba@toshiba ~ $  inxi -Fxzn
System:    Host: toshiba Kernel: 3.16.0-4-amd64 x86_64 (64 bit gcc: 4.8.4) 
           Desktop: Cinnamon 3.2.7 (Gtk 3.14.5+4) Distro: LinuxMint 2 betsy 
Machine:   System: TOSHIBA product: TECRA M11 v: PTME3E-00600VCE
           Mobo: TOSHIBA model: Portable PC v: Version A0
           Bios: TOSHIBA v: Version 3.50 date: 10/23/2012
CPU:       Dual core Intel Core i5 M 520 (-HT-MCP-) cache: 3072 KB
           flags: (lm nx sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx) bmips: 9575 
           Clock Speeds: 1: 1199 MHz 2: 1333 MHz 3: 1199 MHz 4: 1199 MHz
Graphics:  Card: NVIDIA GT218M [NVS 2100M] bus-ID: 01:00.0
           Display Server: X.Org 1.16.4 driver: nvidia
           Resolution: 1920x1080@74.92hz
           GLX Renderer: NVS 2100M/PCIe/SSE2
           GLX Version: 3.3.0 NVIDIA 340.96 Direct Rendering: Yes
Audio:     Card-1 Intel 5 Series/3400 Series High Definition Audio 
           driver: snd_hda_intel bus-ID: 00:1b.0 
           Card-2 NVIDIA High Definition Audio Controller 
           driver: snd_hda_intel bus-ID: 01:00.1 
           Card-3 Logitech HD Pro Webcam C920 
           driver: USB Audio usb-ID: 004-007 
           Sound: Advanced Linux Sound Architecture v: k3.16.0-4-amd64
Network:   Card-1: Intel Centrino Advanced-N 6200
           driver: iwlwifi v: in-tree: bus-ID: 03:00.0
           IF: wlan0 state: up mac: <filter>
           Card-2: Intel 82577LM Gigabit Network Connection
           driver: e1000e v: 2.3.2-k port: 4020 bus-ID: 00:19.0
           IF: eth0 state: down mac: <filter>
Drives:    HDD Total Size: 512.1GB (5.4% used)
           ID-1: /dev/sda model: Samsung_SSD_850 size: 512.1GB
Partition: ID-1: / size: 58G used: 26G (47%) fs: ext4 dev: /dev/sda4 
Sensors:   System Temperatures: cpu: 46.0C mobo: N/A gpu: 0.0:52C 
           Fan Speeds (in rpm): cpu: N/A 
Info:      Processes: 192 Uptime: 28 min Memory: 933.9/7858.0MB 
           Init: SysVinit runlevel: 2 Gcc sys: 4.9.2 
           Client: Shell (bash 4.3.301) inxi: 2.1.28 
Por si vale para algo.

Saludos cordiales.

fjal
Last edited by JCSenar on Fri Dec 23, 2016 5:58 am, edited 2 times in total.
Reason: inxi -Fxzn puesto en [code]
Locked

Return to “Español - Spanish”