Good point. But before we close this off, I was wondering whether it might be worth adding a config file option to disable the use of memory-mapping on output - it’s just a trivial two-line change to force the use of delayed write-back regardless of the filesystem type (this was actually suggested by @rsmith a while back). That might be a more appropriate setting for users who can’t modify the kernel’s dirty page handling (requires admin rights), and where the amount of RAM isn’t a concern. Would that be useful?
This is in fact how things used to work (at least for a while), until users reported issues with RAM utilisation on memory-constrained systems. The problem with forcing the use of delayed write-back is that it will force an explicit RAM allocation, so can fail outright in cases that might otherwise have been OK to run. With memory-mapping, we rely on the kernel’s virtual memory management to handle the data, which allows it to run using less hardware RAM - even though, as you noticed, it will definitely perform a lot better when there is enough RAM to run without swapping data around…
Lots of discussion around this issue here and here, if anyone is interested…