场景 A：
为了在同一主机上运行的两个进程之间共享一个读/写内存块，Joe 从两个进程映射同一个本地文件。
场景 B：
为了在两个不同主机上运行的两个进程之间共享一个读/写内存块，Joe 在主机之间通过 nfs 共享一个文件，然后从两个进程中映射共享文件。
有人尝试过场景 B 吗？场景 B 中出现了哪些不适用于场景 A 的额外问题？
【问题讨论】：
ENODEV。但是编写一个尝试从 NFS 映射文件的程序比编写此问题所需的击键次数更少。
标签： linux memory-management shared-memory mmap nfs
您将需要字节范围锁定才能获得正确的行为。它们在 NFS >= v4.0 中可用。
【讨论】：
我会说场景 B 有各种各样的问题（假设它按照 cmets 中的建议工作）。最明显的是标准并发问题 - 2 个进程共享 1 个资源而没有任何形式的锁定等。这可能会导致问题......不确定 NFS 在这方面是否有自己的特殊怪癖。
假设您可以以某种方式解决并发问题，您现在依赖于维持稳定（和快速）的网络连接。显然，如果网络中断，您可能会错过一些更改。这是否重要取决于您的架构。
我的想法是，这听起来像是一种在不同机器上共享内存块的简单方法，但我不能说我听说过这样做，这让我觉得它不太好。当我想到在 procs 之间共享数据时，我会想到 DB、消息传递或专用服务器。在这种情况下，如果您将一个 proc 设为 master（以处理并发并拥有该概念 - 即，无论这个人说什么是数据的最佳副本），它可能会起作用......
【讨论】：
如果没有一些额外的操作，Mmap 不会共享数据。
如果您更改文件的 mmaped 部分中的数据，则更改将仅存储在内存中。在msync 或 munmap 或关闭甚至决定操作系统内核及其 FS 之前，它们不会被刷新到文件系统（本地或远程）。
使用 NFS 时，数据的锁定和存储将比使用本地 FS 慢。刷新的超时时间和文件操作的时间也会有所不同。
On the sister site 人们说 NFS 的缓存策略可能很差，因此与本地 FS 相比，NFS 服务器的 I/O 请求会更多。
【讨论】：