Originally Posted by bodhi.zazen
That sounds correct, is there any work around to this ?
Bodhi - you really did divert this thread, tho' unintentionally.
Your issue seems to be that the USB i/o is asynchronous, so you fill memory buffers, then at the end or at umount there is a huge delay.
You can type 'sync' and this will (unreliably) cause the outstanding I/O to flush.
You can mount the flash device with the 'sync' option so all I/O completes to the hardware before the write call returns. This may cause improvement in overall time since the writes are overlapped with the other operations. The caveat about the 'sync' mount option is that if you are constantly updating the same block then you will wear the USB. So on a mass copy or rsync it's safe to use 'sync' ,but you don't want to use 'dirsync'.
The OPs problem is quite different - his system becomes unresponsive during USB I/O.
---------- Post added at 10:47 AM ---------- Previous post was at 10:16 AM ----------
Originally Posted by alejandromx
yes, my system run like a turtle when copy to USB device (large files)
the strange thing is that processors do not show overload (I have a Core2Duo at 2.00 MHz) are approximately 10% each when I copy files.
sorry for my english, I am from Mexico, my primary language is Spanish
BTW your english is fine - you are making yourself understood.
I think there are two possible causes of this behavior.
Years ago on Linux some of the device drivers would incorrectly lock resources during I/O. So this would prevent most of the other processes from running. They would block. If you run this command in a window it will print the list of all "runnable" processes every two seconds (or slower). It will include the 'ps' command. It may also include a few other commands when the system is busy.
while true; do echo "---" ; ps -eo state,pid,user,args | grep "^R"; sleep 2; done
If you do this in one window and then do the copy, does the list show nothing or just the copy process.
Try some commands in another window too.
It may help to 'spin' bash in another window so we have some process that only dependent on I/O like
while true; do echo "---" > /dev/null ; done
Then you will see 'ps' and 'bash' and maybe a few others in the runnable list.
If 'bash' is listed with 'ps' then it's blocking for no good reason.
The more likely possibility is that you are out of memory. It's likely that Fedora by default uses more DRAM than some other distros. What does this command report during a slowdown ?
Or use this in a separate window
while true ; do echo "---" ; free ; sleep 5; done
Please post the results of 'free' during slowdown
If the amount of "swap/used" is large or changing then you are out of memory.
If that's the case. If the copy is using up memory and causing free buffers to drop too low, then the trick above (mount with sync option) may help.