Silly question perhaps, but are you sure you’re using the correct port on your Linux system? If I plug my external HD into a USB2 port, I’m stuck at 30-40MB/sec, while on a USB3 port I get ~150-180MB/sec. That’s proportionally similar to the difference you described so I wonder if that’s the culprit.

You can verify this in a few different ways. From Terminal, if you run lsusb you’ll see a list of all your USB hubs and devices.

It should look something like this:

Bus 002 Device 001: ID xxxx:yyyy Linux Foundation 3.0 root hub
Bus 002 Device 002: ID xxxx:yyyy <HDD device name>
Bus 003 Device 001: ID xxxx:yyyy Linux Foundation 2.0 root hub
Bus 004 Device 001: ID xxxx:yyyy Linux Foundation 3.0 root hub

So you can see three hubs, one of which is 2.0 and the other two are 3.0. The HDD is on bus 002, which we can see is a USB 3.0 hub by looking at the description of Bus 002 Device 001. That’s good.

If you see it on a 2.0 bus, or on a bus with many other devices on it, that’s bad and you should re-organize your USB devices so your low-speed peripherals (mouse, keyboard, etc.) are on a USB2 bus and only high-speed devices are on the USB3 bus.

You can also consult your motherboard’s manual, or just look at the colors of your USB ports. By convention, gray ports are USB 1.0, blue ports are 2.0, and green ports are 3.x.

If you’re running KDE, you can also view these details in the GUI with kinfocenter. Not sure what the Gnome equivalent is.

rsync -aP <source>/ <dest>

I find it faster and more reliable than most GUI explorers

That’s just the state of things. I have experienced this as well, trying to copy a 160 GB usb stick to another one (my old itunes library). Windows manages fine, but neither Linux nor MacOS do it properly. They crawl, and in macos’ case, it gets much slower as time goes by, and I had to stop the transfer. Overall, it’s how these things are implemented. It’s ok for a few gigabytes, but not a good case for many small files (e.g. 3-5 mb each) with many subfolders, and many GBs overall. Seems to me that some cache is overfilling, while windows is more diligent to clear up that cache in time, before things get into a crawl. Just a weak implementation for both Linux and MacOS IMHO, and while I’m a full time Linux user, I’m not afraid to say it how I experienced it under a debian and ubuntu.

I/O scheduler issue?

Connect that USB stick, and run command:

grep '' /sys/block/*/queue/scheduler

show output.

Random peripherals get tested against windows a lot more than Linux, and there are quirks which get worked around.

I would suggest an external SSD for any drive over 32GB. Flash drives are kind of junk in general, and the external SSDs have better controllers and thermals.

Out of curiosity, was the drive reformatted between runs, and was a Linux native FS tried on the flash drive?

The Linux native FS doesn’t help migrate the files between Windows and Linux, but it would be interesting to see exFAT or NTFS vs XFS/ext4/F2FS.

Depends on the distro and desktop environment but some will “transfer” files to a software buffer that doesn’t actually write the data immediately. Works for limiting unnecessary writes on Flash memory but not USB sticks that are designed to be inserted and removed at short notice.

You can force Linux to commit pending writes using the ‘sync’ command. Note it won’t give you any feedback until the operation is finished (multiple minutes for a thumbdrive writing GBs of data) so append & to your command (‘sync &’) to start it as its own process so you don’t lock the terminal.

You can also watch the progress using the command form this Linux Stack Exchange Q;

https://unix.stackexchange.com/questions/48235/can-i-watch-the-progress-of-a-sync-operation#48245

Side question though, it seems that there are faster options. How come we don’t use those in GUI file explorers if they’re faster?