Under certain circumstances, MRtrix3 commands seem to stall when handling large images, even when running operating on local files. The most likely explanation lies with the Linux kernel’s handling of dirty pages.
Dirty pages refers to sections of a file that have been modified in RAM, but not yet committed to disk (for further details, look up page caching). The Linux kernel’s policy for handling dirty pages is that only a proportion of the RAM is allowed to be in a ‘dirty’ state. If that threshold is reached, the OS will force dirty pages to be written to disk immediately, before further processing can take place. Since MRtrix3 normally accesses images via memory-mapped files, this can cause a stall.
In MRtrix3, this issue can become problematic if the program makes small modifications in lots of distinct pages, and often comes back at a later stage to make further modifications to the same pages. This causes a large number of dirty pages, triggering the OS to write them to disk, only to find many of the same pages it just wrote to disk have been updated again. This situation is not uncommon, and would be expected to happen when data are processed out of stride (in particular, if the strides of the input image do not match that of the output image).
Workaround: edit the dirty page thresholds
On Linux, you can query your current dirty page handling settings with sysctl -a | grep dirty. Those settings can be modified in /etc/sysctl.conf by adding the following two lines to /etc/sysctl.conf (you’ll need admin rights to do this):
vm.dirty_background_ratio = 60
vm.dirty_ratio = 80
vm.dirty_background_ratio is a percentage fraction of your RAM and should be larger than the image to be written. After changing /etc/sysctl.conf, execute sysctl -p (as root) to configure the new kernel parameters at runtime. Depending on your system, these changes may not persist after a reboot.