This problem seems to have drawn to a conclusion as of today, so I will document my understanding for closure. If network disks were massively slower than local hard disks, I don't think anyone would use them, and it would be a well-known problem. The network team didn't believe that a local disk was faster that a network disk, and they said the /tmp test was invalid because it was virtual memory. They were only convinced when they saw a real local disk performing at the same speed as /tmp. This is to be expected, as a read-only disk file of 1.6 GB is read in just a few seconds and then should be permanently cached in memory. The characteristics of the network disk is that in the beginning, maybe for a couple of minutes, it is about 2.5 times slower than a local disk, but over time it ends up being 20 times slower. I know of no hardware with such characteristics so I said this was an additional problem that should be investigated, on top of the failure of the network file to be cached. I can't see how it would be possible for Linux to actually cache a network disk, because it has no way of knowing if another system updated the file. I would expect Linux needs some special configuration option to say "this network file is static, please cache it whenever it is opened". No further investigation is going to be done, as the conclusion has been drawn that it is a problem with NFS3 and can't be changed. I know nothing about networks, and I am not in that group, and it is way beyond my authority, so I can't do anything further either. The solution being chosen appears to be to put the database file on local disks as required, and point to it via a softlink from the network drive. This is a very strange situation in 2021.