同じホスト上で動作している2つのプロセス間でのメモリの読み出し/書き込みブロックを共有するには、ジョーは、両方のプロセスから同じローカルファイルをmmaps。
シナリオB：
は、2つの異なるホスト上で実行されている2つのプロセス間でのメモリの読み出し/書き込みブロックを共有することは、ジョーはホスト間のNFSを介しファイルを共有し、そして、共有mmaps両方のプロセスからのファイル。
誰もシナリオBを試しましたか？シナリオBで発生する余分な問題は、シナリオAには適用されません。
シナリオBにはあらゆる種類の問題があります（コメントに示唆されているように動作すると仮定します）。最も明白なことは、標準の並行処理の問題です.2つのプロセスが1つのリソースをロックなどの形で共有していないと、問題につながる可能性があります... NFSがこの点に関して独自の特有の癖を持っているかどうかは不明です。
何とか並行性の問題を回避できるとすれば、安定した（かつ高速な）ネットワーク接続を維持することに頼っているはずです。明らかにネットワークが途切れた場合、いくつかの変更が欠落する可能性があります。この問題があなたのアーキテクチャに依存するかどうか。
私は、別のマシンでメモリのブロックを共有するのは簡単な方法だと思っていますが、それができていると聞いたことはありません。私がprocs間でデータを共有すると思うと、私はDB、メッセージング、または専用サーバーと思っています。このケースでは、1つのprocをマスターにして（コンカレントを処理して概念を所有する場合は、この男が言うデータの中で最高のコピーです）、それはうまくいくかもしれません...
Mmapは何も追加せずにデータを共有しません行動。
ファイルのmmaped部分のデータを変更すると、変更はメモリ内にのみ保存されます。 msyncまたはmunmap、またはOSカーネルとそのFSのクローズ、あるいは決定まで、ファイルシステム（ローカルまたはリモート）にフラッシュされません。
NFSを使用すると、ローカルFSを使用する場合よりもデータのロックと格納が遅くなります。フラッシングのタイムアウトとファイル操作の時間も変わります。
On the sister site人々は、NFSのキャッシュポリシーが貧弱であると言っているので、NFSサーバーはI/O要求カウントをローカルFSに比べてはるかに多くのI/O要求があります。
正しい動作のためには、バイトレンジロックが必要です。それらはNFS> = v4.0で利用できます。
あなたはおそらく 'ENODEV'を得ます。しかし、NFSからファイルをマップしようとするプログラムを書くことは、この質問を書くよりもキーストロークが少なくて済みます。 – C2H5OH
@ C2H50H：なぜNODEVを返すのですか？私はかなりmmapのシステムコールが成功を返すと確信しています - しかし、これは私の質問に答えることはありません。 –