How to fix slow speed when copying to USB devices?

Question

linux

Comrades, hello! Help with the solution of a very old and, as shown by a three-day search on the Internet, partially solved, but in some places manifesting itself as a kernel-level problem, which takes its roots from "bug 12309", sort of.
The essence of the problem: when copying relatively heavy files (from 1 GB or more) to USB block devices (specifically, flash drives on different chips and different sizes with NTFS fs), I observe the following - at a speed of ~ 45MB / s, the I / O buffer is filled and after that the speed drops to critically low rates of ~ 130 Kb / s until the buffer is freed again and as a result 1.5 GB are copied to flash drives for unforgivable 30-40 minutes. The system does not hang to zero, maybe some friezes are observed. but they are not significant. Progress bars of three different explorers (Nemo 4.4.2, Thunar 18.04.0 and console mc) behave approximately the same as described above - it creeps quickly to the middle (~ 45MB / s), then indefinitely, HOWEVER, it happens like this, that the progress bar somehow crawls to the end, but it doesn’t work out to unmount the USB flash drive - it’s still busy copying. That is, at the moment
What I tried:
1) I mounted a flash drive with the sync option - the speed is stable ... Stably negligible - 130 Kb / s, as I understand it - this is bypassing the buffer with subsequent direct recording, but as you can see - the speed is still worthless.
2) I set disk buffer limits to 4 MB (sysctl variables: vm_dirty_bytes and vm_backgrounds_ditry_bytes) - it didn't help at all (later I found out that this is not a cure at all)
3) I checked for the mode in which the flash drive is mounted - mode 2.0.

How I solved the problem:
It turned out by accident, with the help of dd I successfully copied a 10 gig movie in blocks of 4 MB, specifying the block size in the bs= parameter, after looking at the optimal block sizes set in the flash drive with the fdisk command. It took about 7 minutes, which I consider the best option for the 2.0 standard. However, don't get me wrong, I don't want to use crutches. The dd program is chic, but for its range of tasks, you don’t even want to prescribe alias's and intertwine everything.

What I have:
- Linux Mint 18.04.1 with kernel 5.3.0-46-generic
- BIOS of ancient revisions, without the ability to configure Legacy-mode for USB.
- 8 GB of RAM
- The only HDD, broken as primitively as possible - / and swap for 16 GB

What krutilki to twist and what to change, prescribe, what to do, in general, so that I use copying as much as possible in a housewife? I ask you to exercise your restraint and if this question is considered childish and stupid in the circle of those in the know - still give me effective advice, which is generally accepted. If you need more specifics on the system (log outputs, monitor readings, etc.), then I will gladly provide everything. Thank you all in advance!

Answer 1

Use exfat

Answer 2

And if you specify the big_writes option when mounting?
And if you try to build the latest version of NTFS-3G?
Well, on a note:
1) keep in mind that the NTFS-3G userspace driver and it will a priori be much slower.
2) for yourself, try to avoid ntfs, there are a lot of native fs that Androids and TVs understand. There is a compromise in the form of exfat (there is already an option for both slow fuse and fast kernel)

Answer 3

Unfortunately, there is no exact unambiguous solution. If it didn't work right away, then it won't work, the USB subsystem in Linux is definitely the worst of all.
Seriously, the problem is known and very old.

Answer 4

I have 3 flash drives. And all three had different behavior when copying. Speed. Buffer. Hangup.
I agree with all speakers.