`ln`はNFSでアトミックで信頼できますか？このユースケースでは、NFSはGFSを置き換えることができますか？

すべてのノードが同時にアクセスするGFSグローバルファイルシステムを含む共有ディスクを含む複数のサーバーで構成されるクラスタがあります。

クラスタ内のすべてのノードは同じプログラムを実行します（シェルスクリプトが主なコアです）。システムは複数の入力ディレクトリに表示されるファイルを処理し、次のように動作します。

• プログラムは入力ディレクトリを繰り返します。
• 見つかったファイルごとに「ロックファイル」があることを確認し、ロックファイルがある場合は次のファイルにジャンプします。
• ロックファイルが見つからない場合、ロックファイルが生成されます。ロックファイルの作成に失敗した場合（レース失敗）、次のファイルにジャンプします。
• 「私たち」がロックを所有している場合は、ファイルを処理し、完了したらファイルを別の場所に移動します。

これはすべてうまく機能しますが、うまくいくためのより安価で複雑なソリューションがないかどうか疑問に思います。 NFSやSMBを考えています。

私は2つの理由でGFSを使います：

1. 各ファイルは1つの場所（もちろん冗長ベースハードウェア）にのみ保存されます。
2. ファイルロックは安定して動作します。

次のようにロックファイルを作成します。

date '+%s:'${unid} > ${currlock}.${unid}
ln ${currlock}.${unid} ${currlock}
lockrc=$?
rm -f ${currlock}.${unid}

$unid一意のセッション識別子はどこに$currlockあります。/gfs/tmp/lock.${file_to_process}

その美しさはlnまさにそれです。原子、同時に同じことを試みる人を除くすべての人は失敗します。

だから私が尋ねるのは、NFSが私の要件を満たすかどうかです。lnNFSで作業するのはGFSで作業するのと同じくらい安定していますか？