File transfer hangs for a long time before finishing

[Peter Linu]

I have a very similar problem and I don't use USB transfer at all. I have a network setup wherein I transfer from a dual boot laptop with Cinnamon 20.1 or (mainly) Win7 to several XFCE NAS shares. An initial transfer to a share is always deathly slow and sometimes it's quicker to reboot and then it works how it should. I asked a Linux propeller-head and he says that it's always been like that. Obviously he didn't have a solution.

[mikeflan]

An initial transfer to a share is always deathly slow

Can we assume deathly slow is 2 MB/sec or slower?

[Peter Linu]

Yes

[Daniels118]

I have the same problem, copying large files to usb hangs at 99% indefinitely. If I try to disconnect the device, the system says the device is in use.
To workaround open a terminal and run the "sync" command. This may take several seconds to finish, but should work.

[fstjohn]

It starts fast because it is filling up the memory buffers and once full slows down to the the write speeds for the USB drive. No way round this.

People are saying Windows or various GUI file managers don't have this problem. If one's able to do the same file transfer in Windows and Mint on the same computer, seems using a USB stick with an activity LED you could time how long the activity LED was blinking from the time the transfer was initiated until it finally went out. IMO that should give a fair comparison, buffer or no buffer, accurate transfer bar or not. Same technique should work comparing different file managers or the command line cp.

[fstjohn]

Just did an experiment. I copied a directory containing 10GB of assorted .mp3 files from my internal HD to a USB3.0 - 32GB memory stick using four different file managers. The times given are from initiating the copy until the activity light on the stick stops flashing. In all except Nemo the progress bar seemed to be reasonably accurate. In all cases when the program indicated the copy was complete it corresponded to activity light stopped. With Nemo the progress bar hung at 99% and remained until the transfer finished (activity light stopped flashing). Here are the times:

Nemo
13 min 29 sec

Double Commander
14 min 59 sec

Krusader
13 min 37 sec

Midnight Commander
17 min 46 sec

[Darkmaster006]

The way I see it, the problem of the original poster (and for me) is actually three problems:

1) Stupid implementation of write-cache for removable usb drives. Writing buffers are useful for hard disks, but it's a completely stupid thing to have for usb flash drives. It offers nothing in terms of actual writing speed, deceives the user about the true writing speed, and if the user removes a drive without unmounting, you get a corrupt filesystem. All file managers I have used are affected by this (nemo, double commander, midnight commander) and also the cp shell command. This thing is moronic: it absolutely should not exist and future linux distros should find a way to disable it. Until then there MUST be a workaround or a way to disable it.

2) Actual writing speed is slow: adding vm.dirty_bytes=15000000 in /etc/sysctl.conf makes the writing buffers small 15MB, effectively takes the writing cache out of the way and brings you face to face with the real problem: while copying to usb drives, I get speeds of 300kb/s and that's for usb 3 devices! I was wrong in my previous post. Copying 5 GB of data does finish if you leave the flash drive alone, it just happens after 10 hours or so. Users complain about "freezing" but it's not freezing, it's actually very very very slow copying.

3) During this slow copying procedure, Nemo becomes slow to respond or unresponsive. And because Nemo is an integral part of the desktop, the whole system becomes unresponsive while the usb copies (i.e. you can't open another folder and view it's contents). I have had to hard-reset the system after some time. Also, if you change your mind and decide to cancel copying, it takes some time (for me about 5 minutes) before copying actually stops. I think the system is waiting for that last file to finish copying before stopping and that may take some time

I've got this problem too. It can also just freeze at 5% and then stop for a while. I cancel it, yet to no avail, when I turn it off, it takes a looong time since, idk, it must be doing something with the data. It's really a shame since this has only happened in Mint to me and I haven't been able to find a solution.

[Larry78723]

It would be interesting to see if Debian 10 has the same problem. It uses Nautilus file manager.

[Larry78723]

Debian has the same issue so this isn't a Nemo issue.

[cyttorak]

I have the same problem in Linux Mint Xfce

[Moem]

I have the same problem in Linux Mint Xfce

Moderator's note:
Please start a new topic, this one is too old. Thanks!