BUKURO-JIN

NFS でセッション共有するには, PHP が動作する各Webサーバから NFSマウントしたディレクトリを session.save_path に指定して, session.save_handler = files にすれば OK。
何てことはなく, ファイルでのセッション管理と設定は変わりません。

で, 結論から言うと予期しない動作をするケースは発生し得ます。
ブラウザを二つ立ち上げて, 同じセッションID で同時にアクセスするケース。
この場合, セッションファイルがロックされていないので, セッションの値が更新される場合は, タイミングによってはセッションの値が予期した通りに設定されないかもしれません。
NFS で共有しているファイルに同時に書き込みすると簡単に壊れてしまいますので･･･。
この検証に関しては, 先の MLスレッドで詳しく検証されているのでそちらを参照下さい。

問題は, この事がどのくらいアプリケーションにとって脅威なのかということ。
セッションの使い方って, ログイン情報を管理する等の Webアプリにおけるユーザの状態保持や, フォームに入力された値を持ちまわすとかそれ位なんじゃないかなと。

重要なデータはセッションでは管理しないでしょうし, 何らかのデータの一連の更新処理は DB のトランザクションで管理するので, NFS で共有されているセッションファイルに同時にアクセスされても特に問題は起こらないでしょう。

アプリケーションにとって重要な処理はきちんとエラーチェックしている（はずな）ので, セッションデータが壊れたとしてもアプリケーションとしての致命的な不整合には結びつかないんじゃないかなぁ。
表示関係でおかしくなることはあるかもしれませんが。

ブラウザを 意図的に2つ立ち上げて, 同一セッションID でほぼ同時に異なる動作をする人は, テスター以外には殆どいないでしょう。
他の人が同じセッションID でアクセスしたらセッションファイル壊れるんじゃね？というのはそもそもセッションID が他人に漏れている時点でアウトなので論外。

NFS で共有されている flock が効かないセッションファイルに同時にアクセスできることが, どれだけ致命的な問題に結びつくかを電車の中とかであれこれ考えてみましたが, 問題ないんじゃないでしょうか。

銀行の残高をセッションに覚えさせておいて, セッションの値を更新してそのまま DB を UPDATE なんていうステキなプログラム書いてたら別ですが･･･。

確かにファイルロックが効かないのは気持ち悪いです。
でも, NFS で PHP のセッション共有しても特に問題はないというのが結論。
# Sharedance も flock していないようですし...
ただ, NFS では上記のような問題点が起こることは認識しておくべきことですけどね。

というか, 実際 NFS 使っている人多いんじゃない？
それともセッション管理するために memcached とかのセッション管理サーバを入れるのがスタンダードなのかしらん？

ちなみに NFS での PHPセッション管理ですが, パフォーマンスは悪くないと思います。
もちろん session.gc_probability = 0 にして, Webサーバ上でセッションの GC が起こらないようにしておくのが条件。
セッションファイルの削除は cron 使って NFS サーバ上で行ってください。

じゃないと, GC 走る度にディレクトリツリー情報が Web ⇔ NFS 間に転送されてしまって, セッションファイルが多くなったとき(数十万とか)に軽く死ねますので。