I had an issue where transferring files to (not sure if same happens to from) USB drives would hang, and often not complete. The transfer/completion rates were also falsely reported.
A common solution to this is adjusting the value of dirty_bytes (whatever that is) by running this command on startup:
echo $((16*1024*1024)) > /proc/sys/vm/dirty_background_bytes echo $((48*1024*1024)) > /proc/sys/vm/dirty_bytes
Which I am currently doing and can confirm has solved the issue for me. The default settings for these variables(?) is generally considered inadequate for modern 64-bit operating systems.
This is a quite serious issue and as a by-product introduces many other isseus with USB drives on linux (like incomplete file transfers, and usb devices 'hanging' so you cannot eject them, and an inability to cancel running file transfers, or rather, it takes a very long time after you hit cancel for it to close), there are even reported cases of this issue slowing/freezing the entire system I'm surprised it hasn't been fixed by now. Especially considering how easy it is to fix, and how old it is.
Update: Further clarification after further research.
The reason the default settings are considered inadequate for modern 64-bit Operating Systems has to do with the amounts of RAM they typically have, when these settings were created for the kernel, they were only created with 8-64MB of RAM in mind, and seems to operate half-decently up to 1GB of RAM.
These settings, when misconfigured on 64-bit operating systems with large amounts of memory (Confirmed for 12GB+, presumed to affect 2GB+, further testing needed) can cause more serious issues than the aesthetic ones that I mentioned earlier, there have been reports of system-hangs related to this issue. This issue does not seem to affect Manjaro, so it has presumably be fixed in the scheduler we use (BFQ) but it still mis-reports the file transfer completion rate, as well as the transfer speeds of the transfer in question, which, while it seemingly doesn't impede function, is still worth looking more deeply into. Such issues are generally unacceptable for a modern consumer that happens to use USB Drives for any reason.
It is likely that adjustments to the scheduler configuration could be an alternative solution to fix the issue.
There is also a possibility that setting vm_highmem_is_dirtyable to 1 would solve the issue. It was a suggested solution to make dirty memory behave the same way on 64-bit systems as on 32-bit ones, which seemingly has not been enabled by default.
In 2013, Linus Torvalds said this about the issue:
Right. The percentage notion really goes back to the days when we
typically had 8-64 megabytes of memory So if you had a 8MB machine
you wouldn't want to have more than one megabyte of dirty data, but if
you were "Mr Moneybags" and could afford 64MB, you might want to have
up to 8MB dirty!!
Things have changed.
So I would suggest we change the defaults. Or pwehaps make the rule be
that "the ratio numbers are 'ratio of memory up to 1GB'", to make the
semantics similar across 32-bit HIGHMEM machines and 64-bit machines.
The modern way of expressing the dirty limits are to give the actual
absolute byte amounts, but we default to the legacy ratio mode..
Update 2: Out of concerns for possible performance impact of changing these settings, I did some simple benchmarking in a below post, there are more benchmarks if you scroll further down.
There seems to be a real possibility that contrary to my fears, adjusting this setting can improve drive (write) performance noticably, even on fast drives.