シナリオ A :
同じホストで実行されている 2 つのプロセス間でメモリの読み取り/書き込みブロックを共有するために、Joe は両方のプロセスから同じローカル ファイルを mmap します。
シナリオ B :
2 つの異なるホストで実行されている 2 つのプロセス間でメモリの読み取り/書き込みブロックを共有するために、Joe はホスト間で nfs を介してファイルを共有し、両方のプロセスから共有ファイルを mmap します。
シナリオ B を試した人はいますか? シナリオ A に当てはまらない、シナリオ B で発生する追加の問題は何ですか?
Mmap は、いくつかの追加アクションなしではデータを共有しません。
ファイルの mmaped 部分のデータを変更すると、変更はメモリにのみ保存されます。msyncこれらは、OS カーネルとその FS の munmap またはクローズ、さらには決定まで、ファイルシステム (ローカルまたはリモート) にフラッシュされません。
NFS を使用する場合、ローカル FS を使用する場合よりもデータのロックと保存に時間がかかります。フラッシュのタイムアウトとファイル操作の時間も異なります。
姉妹サイトでは、NFS のキャッシング ポリシーが貧弱である可能性があるため、I/O 要求数をローカル FS と比較すると、NFS サーバーへの I/O 要求がはるかに多くなる可能性があると言われています。
正しい動作のためにはバイト範囲ロックが必要です。NFS >= v4.0 で利用できます。
シナリオBにはあらゆる種類の問題があると思います（コメントで提案されているように機能すると仮定します）。最も明白なのは、標準の同時実行性の問題です。2つのプロセスが1つのリソースを共有し、ロックなどの形式はありません。これは問題につながる可能性があります...NFSにこの点で独自の癖があるかどうかはわかりません。
並行性の問題をなんとか回避できると仮定すると、安定した（そして高速な）ネットワーク接続を維持することに依存することになります。明らかに、ネットワークがドロップアウトした場合、いくつかの変更を見逃す可能性があります。これが重要かどうかは、アーキテクチャによって異なります。
異なるマシンでメモリのブロックを共有するのは簡単な方法のように思えますが、それが行われているとは言えないので、あまり良くないと思います。proc間でデータを共有することを考えるとき、DB、メッセージング、または専用サーバーを考えます。この場合、1つのprocをマスターにすると（並行性を処理し、概念を所有するために、つまり、この人が言うことはすべてデータの最良のコピーです）、それは機能する可能性があります...