Linux: avoiding slow performance for piped images

When MRtrix3 command pass data through a Unix pipe, what happens by default is that a temporary image is created, and held on the /tmp/ filesystem; the end stage of the pipe is responsible for deleting the file. This can sometimes cause some issues, particularly in terms of running out of space on /tmp if too many processes have crashed and failed to clean up the temporary files (this should be a rare occurrence these days). It can also be a problem when /tmp is too small to process large data files, in which case the TmpFileDir config file option can be set to a different user-writable location large enough to hold the data to be piped.

However, another option on Linux is to use the shared memory filesystem, typically mounted as a RAM-backed tmpfs filesystem at /dev/shm. Data placed in this location is guaranteed to remain in RAM, and by default this folder is allowed to take up at most half of the system RAM. Therefore, if the TmpFileDir config file option is set to /dev/shm, piped data will not be subject to slowdown due to dirty pages, and assuming the system is equipped with enough RAM, it should be possible to process large datasets (note that if your data to be processed approaches half of the available RAM, there’s a good chance that performance would be terrible anyway, since the system won’t be able to hold both input and output images if they’re both that large).

One potential issue with this approach is that if commands don’t cleanup their temporary images, this will now take up RAM rather than disk space on /tmp. This will however be cleared after a reboot, and the user can also remove any temporary files left over in /dev/shm.