I've been ripping my hair out for months about transferring large files, or groups of small files to my mp3 player. It will start fast, then just die down, and take forever to finish. I've searched all over the web and found that some people have this problem and others don't, which would lead me to believe that it is hardware related. But I don't think it is.

If I mount the device with the graphical widget thing, open it in dolphin, and start copying files, it acts as described above. If I mount it from a command line with no options, it seems to finish the transfer, but then I cannot unmount it for a long period of time, as it says it is busy.

I have the same issue with an old 1GB flash drive. So upon experimenting with it, I've found that it only happens if it is formatted fat32. If it is formatted ext2, the transfers buzz right along, no problem. So obviously it is not hardware related.

So apparently there is a mount option that I am missing to make it work right. I've tried the -sync option, but that seems to make no difference. Can someone shed some light please?

I've had the same "start fast, then slow to a crawl" issue transferring to a usb flash drive in Suse 11.1. The usb drive is undoubtedly formatted FAT32 -- used first in Win and I haven't formatted it.

Interesting news that the format makes a difference. I should try ntfs on the usb drives, since I need them also readable in Win.

the problem you're describing (device busy) is caused by you still being in the directory you're trying to umount.
2 example options:
or if all else fails you can use 'lazy' umount
cheers

For what it may be worth... several years ago I experienced a similar issue (using XP). Copying files to/from a USB flash drive, MP3 player or digital camera was almost impossible. Talk about SLOW!

One day I needed to transfer some files and I tried the USB drive in a Fedora machine. Worked great. I dual booted the Fedora machine to XP and it worked great. The original XP machine and the dual boot machine were both Dell Dimension 4600s of almost identical spec.

After pondering the situation I determined that the only difference was that the mis-behaving machine had a bunch of other USB things attached (printers, scanner, UPS). "USB devices don't conflict with one another" so this should make no difference.

Well... I started unplugging USB things one by one, testing the file transfer and then reattaching each USB thing if it did not have any impact.

Bottom line, it was my Brother HL5170DN laser printer at fault. When it was unplugged (power off was not good enough) the file transfers were speedy as expected. When the laser printer was attached the USB file transfer rate was essentially unusable. The laser printer is now shared on my Ethernet network.

So, even though USB devices do not conflict... might try transferring the file with no other USB things attached.

Ken

p.s. as to the difference in performance based on the drive format... this SHOULD also have no impact, but...

Yes, I know that the device busy can be caused by being in that directory. However, if I get the device to unmount, only a portion of the data has transferred, meaning that it never finishes, something causes it to hang. I believe it has something to do with the way it is handling the file allocation table, because it never happens with drives with linux formats.

Hang on, after it returns finished, it has still only transferred part of the data?

Sound like the write was not completed fully, ie cached/buffered somewhere!

I have also had slow USB xfer rates when multiple USB devices are attached to the computer,
even causing USB to get disconnected/reset.
Check dmesg before and after to see if there are any new entries that can be related to the xfer.
In fact USB requires more resources (eg CPU ticks) than say Firewire, and then there is the issue of
all the h/w implementation that were buggy (eg Via chips).
Throw in USB hubs and things get really messy.
That is why I prefer to use Firewire external drives vs USB external drives!
In fact, my external drive in Firewire mode (it has both USB & 1394 ports) consistently beats out USB on
every computer I have connected it to!
But unfortunately, USB seems to be what everyone is moving towards!

No, it doesn't return finished. It keeps saying that it is copying, but it will never finish. The file size cutoff where this happens seems to be about 250MB. When the amount to be transferred is below that, it seems to finish. When it goes past that mark, the speed drops way down to nothing, and even if you let it go all night, it will not finish.

I have done a lot of reading online about other people with this issue. The common thread is that reads are always fine, it is only writes.
And it never happens to me with a stick formatted ext2, I have had it with fat32, and I have not bother to try ntfs or anything else.

Also worth noting is that when I was messing with a windows formatted ipod, it was the same way. As roy said above, it gets cached somewhere and never written it seems.