Comment 122 for bug 1208993

Can't believe this bug dates all the way back from 2014 and 8 years later in 2022 this is still a thing! Not only that the bug has nobody assigned to it and is of "undecided" importance!

My experience is appalling even by juggling with the vm.dirty_ratio and other dirty bytes values and my system is nothing to sneeze at (2 x 7763 Epycs, 2TB RAM etc). Trying to copy 16TB of data, that consists of big files (tens and even hundreds of GB of files), to a USB 3.0 RAID0 drive, would start initially at ~300MB/s copy speeds (cp, rsync...doesn't matter) and fall quickly to like 10% of that value of 30MB/s as dirty bytes values soar as soon as copy begins. Bumping the drity ratio to even 99, meaning filling up the RAM with the dirty values, doesn't help much either as it only block the whole RAM but also allows for only a few files to be copied at full speed, the throttle still being applied as soon as the threshold is reached. To get back at full copy speeds, one needs to either wait for dirty values to go down (ages) or find a way to clear the RAM cache (hard reboot would do it but it's unacceptable).

This BUG is simply incredible and prof that Linux and the kernel more precisely has yet to mature itself even after 30+ years