I have a device
/dev/mydisk that is based on a stack of functionality: a LUKS-encrypted, software RAID-1.
From time to time, I do a backup of
/dev/mydisk contents to an external USB disk, which is itself encrypted using LUKS. A couple of 100 GiB need to be transferred. This operation is not a simple
dd but a recursive
cp (I still need to change to use
A while after the backup starts, the interactivity of the whole system declines tremendously. The KDE interface is choked to death apparently waiting for memory requests to be granted. A wait time of 2 minutes for the prompt is not unusual. Waiting for network I/O likewise demands a lot patience. This is similar behaviour to what happens when
baloo kicks in and decides to unzip every zip and index every file content for purposes unknown: The system becomes swamp canoe.
It seems that the kernel gives all the RAM to the copying processes and is loath to hand it back to give interactive processes a chance. RAM is not shabby: 23 GiB. There is also 11 GiB of swap space, just in case, but it's just occupied by a few MiB at any time.
Is it possible to make sure interactive processes get their RAM in preference to the copying processes? If so, how?
- This is a Fedora 29 (4.19.15-300.fc29.x86_64) system but I know that I had this issue in earlier Fedora systems, too.
- The KDE version is based on "KDE Frameworks: 5.53.0".
Thanks to everyone for the answers so far!
Once one knows what to search for, one finds some things.
What I have hauled in:
- 2018-10: U&LSE entry apparently exactly about my problem: System lags when doing large R/W operations on external disks. As the questioner uses
dd, the remedy is to use the flag
oflag=directto bypass the page cache.
- 2018-11: U&LSE relatively general question about slowdown-on-write Why were “USB-stick stall” problems reported in 2013? Why wasn't this problem solved by the existing “No-I/O dirty throttling” code?. This is rather confusing and and we have to wrestle rumours and phenomena.
- 2013-11: Jonathan Corbet at LWM.net: The pernicious USB-stick stall problem. This is the article the "reported the problem in 2013". However, an answer to the question of 2018-11 says that this article is wrong and based on incorrect premises.
- 2011-08: U&LSE entry about how to forcefully clear the page cache, which may bring responsiveness back: Setting /proc/sys/vm/drop_caches to clear cache
- 2016-01: U&LSE entry about how to restrict the size of the buffer cache: Restrict size of buffer cache in Linux
- Discussions about I/O schedulers and writeback throttling.
- 2018-10: U&LSE question on this: Is “writeback throttling” a solution to the “USB-stick stall problem”?
- 2016-04: Jonathan Corbet at LWM.net: Toward less-annoying background writeback.
- I'm also thinking about: 2017-05: Improving Linux System Performance with I/O Scheduler Tuning, 2009-06: Selecting a Linux I/O Scheduler
Why aren't there expert systems handling the I/O tuning by now..?