NFS マウント上の FIFO ファイル ロケートに書き込もうとすると、ブロックされます。何が問題なのですか?
私の /etc/export:
/tmp/test/ 10.0.0.0/24(rw,no_root_squash,async)
NFS サーバーとクライアントの ls /tmp/test は同じです
prw--w--w- 1 root root 0 2009-06-24 17:28 ui-input
そして、私はルートとして書いています
ありがとう。
この応答はおそらく遅すぎて役に立ちませんが、名前付きパイプと "nc" (netcat) コマンドを使用して同様の効果を達成できることは注目に値します。Netcat は、標準入力 (または名前付きパイプ) からの入力を受け入れ、ソケットを介して、別のホスト上の netcat の別のインスタンス (オプションで名前付きパイプ) にエコーアウトできます。
したがって、基本的に、セットアップは次のようになります。
Host1$ mkfifo Host1_named_pipe
Host1$ nc -l 1234 > Host1_named_pipe
Host2$ mkfifo Host2_named_pipe
Host2$ nc Host1 1234 < Host2_named_pipe
ここで、Host2 でプログラムを実行し、その出力を Host2_named_pipe に送信すると、その出力は Host1 の Host1_named_pipe から出力されます。
または ssh 経由:
Host1$ mknode Host1_named_pipe p
Host2$ mknode Host2_named_pipe p
Host1$ cat Host1_named_pipe | ssh Host2 'cat - > Host2_named_pipe'
FIFO は、プロセス間通信メカニズムであることを意図しています。NFS 経由で FIFO をエクスポートしようとすることで、ローカルのプロセス間通信をより多くのネットワーク通信メカニズムとして扱うようにカーネルに要求することになります。
これに関連する問題がいくつかありますが、最も明白な問題は、カーネル内の FIFO 読み取りの実装が、データのコピー先としてユーザー空間のバッファーを想定していることです。このようなバッファは、NFS では直接利用できません。したがって、カーネルは NFS を介した FIFO のエクスポートをサポートしていません。
代わりに、ネットワーク通信にソケットを使用したい場合があります。
これは名前付きの fifo ですが、ファイルシステムがマウントされているシステムでのみ機能すると思います。この fifo の読者はいますか? ライターとリーダーは同じシステム上にありますか?
fifo は次のように機能します。プロセスが fifo を開くと、カーネルがパイプを作成します。別のプロセスが fifo を開くと、カーネルは (名前から) 以前に開いたパイプと同じパイプであることを認識します。
これは、2 つの異なるマシンでは機能しません。つまり、プロセス A が client1 で実行され、プロセス B が client2 で実行されている場合、プロセス A とプロセス B は fifo を介して通信できません。これは、fifo が各マシンで作成されるためです。
fifo は開かれるまで存在せず、ローカルで終了するだけで、ファイルシステムの内容には影響しません。
FIFO にリーダーはありますか? FIFO は、相手側で何かが読み取られるまでブロックされます。(ノンブロッキング モードで開く場合の通常の例外が適用されます。)
NFS は、マルチ OS の最小公分母ファイルシステムとして設計されました。そのため、完全な Unix ファイル システム セマンティクスはサポートされていません。特に、FIFO/名前付きパイプは、使用できる場合でも、システム間で共有されません。(同じホスト上の 2 つのプロセスは、NFS FIFO 経由で通信できる場合がありますが、これを行うことはお勧めしません)。
完全な Unix セマンティクスが必要な場合は、RFSなどを使用する必要があります。NFS の移植性と 95% のソリューションと比較して、RFS の複雑さとパフォーマンスの低下により、RFS は基本的に時代遅れになっていることに注意してください。クロスホスト プロセス間通信の推奨ソリューションは、OS 環境に応じて、BSD スタイルのソケットまたは AT&T スタイルのストリームを使用することです。Linux の場合は、ソケットを使用します。