High single core usage while transferring files

Hi, I don't know why does this happen (I have searched but haven't find any answers about it)
This problems happens whenever I transfer large or a lot of files from my computer to an external drive.
when this happens the transfer speed and the computer goes extremely slow, even to the point where the transfer speed reaches 0/kbs for some time to re-take the transfer for sometime.
Last time it happened I waited about an hour to the files to finish, even after that the single core usage remained, I had to directly unplug the external drive to make the usage normal again.
This only happens when I transfer files with +10/mbs for some seconds, if it goes slow this does not happen.
I don't know why is this happening nor where else I could ask about it.
Could this be a software problem or a hardware?

Edit: when the CPU core usage is acting like that I cannot shut down the computer normally, it freezes when trying to shut down like that.

This is just a guess based on my experience with dd. My computer acts similar when I dd an iso on to 3.0 USB drive with a block size of 8 megabytes. It starts off saying it's copying very fast, but then slows to a crawl. Much slower than 3.0 should be and even slower than a 2.0. If I drop to a 4Mb block size it doesn't happen. I think it's miscalculating it's progress when copying that fast. I think when it starts it thinks it's copying faster that it really is and then later in the copy it seems to realize this, so it seems to compensate by showing a slower speed than it is actually copying. What's even stranger is, when the progress status counter gets done and my copy should apparently be finished, if I used the 8Mb block size, I just have to stare for about 5 minutes or so while it apparently does nothing before it finishes. I believe during that "idle" time it is really still copying. It just reported a faster speed than it was actually copying. I can't tell you a solution for a file manager, but in dd the solution is to use a smaller block size. Other than that, just wait for it or use a 2.0 port.


You need to provide your garuda-inxi output to help with diagnosis.

The first thing to do is to check your external drive for errors. Sadly, even if the drive scans as fine it could still be causing your issue. I've encountered several old drives of mine that passed all checks, but caused all manner of problems from I/O errors, transfer speed issues, and system freezes. When I took these drives out of service all the issues I was experiencing went away.

With these balky drives I could sometimes mask the problems by using different kernels and different I/O schedulers, but this is only a stopgap measure. A drive that has reliability issues needs to be replaced. Do you have an alternate drive that you could test out?

Sometimes it is not the drive itself that is causing the issue. Sometimes it is the circuitry inside the drive enclosure that is faulty and replacing the drive enclosure (not the drive) will correct the issue. I have experienced this issue more than several times in the past. This problem cropped up more than once when using external drive banks designed to host more than one drive. For that reason I no longer buy multi bay external drives. I have however also experienced issues with single drive enclosures in the past as well.

I cannot definitively say this is a hardware issue, but it sets my spidey senses to tingling when I read about the symptoms you describe.

Be sure to try alternate kernels, and also check you logs for USB & I/O errors. Your logs can often point to the smoking gun causing your issue. Search any errors you find in your logs thoroughly online and it may help identify the cause of your problems. You will want to post any errors you find in your logs.

Good luck

1 Like

Does your external drive use NTFS by chance?


This is correct. Unless you mount with sync. See more from man mount.
I usually do not want to mount with sync, so I watch my writeback cache with this to ensure completion:

alias watchsync='watch -n 1 -d grep -e Dirty: -e Writeback: /proc/meminfo'

@PerseverantX please also include the results of cat /etc/fstab and sudo smartctl --all /dev/sdX, where sdX is the disk in question.