For context:
I’m copying the same files to the same USB drive for comparison from Windows and from my Fedora 41 Workstation.
Around 10k photos.
Windows PC: Dual Core AMD Athlon from 2009, 4GB RAM, old HDD, takes around 40min to copy the files to USB
Linux PC: 5800X3D, 64GB RAM, NVMe SSD, takes around 3h to copy the same files to the same USB stick
I’ve tried chagning from NTFS to exFAT but the same result. What can I do to improve this? It’s really annoying.
I find that it’s around the same, except linux waits on updating the UI until all write buffers are flushed, whereas Windows does not.
That’s nice but I managed to copy 300GB worth of data from the Windows PC to my Linux PC in around 3h to make a backup while I reinstall system and now I’ve been stuck for half a day copying the data back to the old Windows PC and I’ve not even finished 100GB yet… I’ve noticed this issue long ago but I ignored it as I never really had to copy this much data. Now it’s just infuriating.
One thing I ran into, though it was a while ago, was that disk caching being on would trash performance for writes on removable media for me.
The issue ended up being that the kernel would keep flushing the cache to disk, and while it was doing that none of your transfers are happening. So, it’d end up doubling or more the copy time because the write cache wasn’t actually helping removable drives.
It might be worth remounting without any caching, if it’s on, and seeing if that fixes the mess.
But, as I said, this has been a few years, so that may no longer be actively the case.
This actually sounds like it could be the case, I’ll explore tomorrow as I’m already in bed. Thanks for suggestion.
Edit: disabling caching yielded an improvement but very minor, writing to USB stick still sucks
Are you using two separate devices? If so another option could be LocalSend, it allows you to send files over the same network.
I used it for sending a couple hundred GBs of files. Didn’t take too too long. Also avoids unnecessary writes to flash media.
except linux waits on updating the UI until all write buffers are flushed, whereas Windows does not.
I wish that were true here. But when I copy to USB the file manager ( XFCE/Thunar ) shows the copy is finished and closes the copy notifications way way before it’s even half done, when I copy movies to a stick.
I use fast USB 3 stick on USB 3 port, and I don’t get anywhere near the write speed the stick manufacturer claims. So I always open a terminal and run sync, to see when it’s actually finished.I hate to the extreme when systems don’t account for write cache before claiming a copy is finished, it’s such an ancient problem we’ve had since the 90’s, and I find it embarrassing that such problems still exist on modern systems.
I’ve ran sync and it exited already 4 times and the copy is still going
rsync -aP <source>/ <dest>
I find it faster and more reliable than most GUI explorers
-avP
I do
-azP
for compressionthat’s good if your data is not already compressed, otherwise is more of a CPU waste
images, videos, audio, game assets, standardized data files, and a bunch of other things are likely already compressed.
compression is good when copying over the network, but would just waste cpu time when copying to a usb stick.
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.
For sanity check I’ve tried.
Bus 004 Device 004
and it’s USB 3.0 as it should be.Also I’ve disabled caching and I’m now copying 6 video files at only just 15MB/s (and it’s slowing down, byt the time I went to make screenshot for this post it dropped again). And it’s quite a bit slower than on Windows still.
Now down to 9MB/s and still going down
EDIT: 12 min later…
Still going…
it just finished, 4h for 40GB (6 files)
Did the USB drive get excessively warm during this because it looks like the drive is throttling?
Incidentally, this is why I switched to using external SSDs. A group of 128GB flash drives I had would slowly fall over when I would write 100GB off files to it.
This is a really good point. I generally have the opposite experience re: Linux vs windows file handling speed. But I have been throttled before by heat.
OP, start again tomorrow and try the reverse, and tell us the results.
single 4.4GB video file
- Zen1 based Windows PC - 2min 10s (could unmount right after progress finished)
- Zen4 based Fedora41 laptop - 3min 1s (progress finished within 1min but then took 2min to unmount)
- Zen3 based Fedora41 PC - 5min 16s (progress finished within 20s but took almost 5min to unmount)
No it did not get warm at all because it was barely doing anything. But so that I’m fair I’ve borrowed different USB 3.2 Gen1 drive and tested also with my Fedora Laptop.
single 4.4GB video file
- Zen1 based Windows PC - 2min 10s (could unmount right after progress finished)
- Zen4 based Fedora41 laptop - 3min 1s (progress finished within 1min but then took 2min to unmount)
- Zen3 based Fedora41 PC - 5min 16s (progress finished within 20s but took almost 5min to unmount)
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?
I haven’t had this problem. It could be the filesystem you’re using? Sometimes Linux gets weird with Windows filesystems. Try formatting it to ext4.
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.