NFSアトミック性のrename（）
私は次のようなプロセスを持っています：
- 新しい「.tmp」ファイルを書き込みます。
rename()syscallを使用して、既存のファイルを置き換えます。- このファイルは、リモートNFSクライアントからアクセスされています。
これを行うのは、アトミックファイルの更新が必要であり、 rename() 仕様に次のように記載されているためです。
Newpathがすでに存在する場合は、アトミックに置き換えられるため、newpathにアクセスしようとしている別のプロセスがnewpathを見つけられないことはありません。ただし、oldpathとnewpathの両方が名前が変更されるファイルを参照するウィンドウがおそらく存在します。
私たちはこの振る舞いに依存しています。
しかし、ここに落とし穴があります-つい最近、新しいNetApp（クラスターモード、7モードから）に移行してから-非常にまれにENOENTでフォールオーバーするプロセスがありました-そのようなファイルやディレクトリはありません。
「ごくまれに」とは、過去数週間に4〜5回、5分ごとに発生するプロセスを意味します。
これがNFSサーバーのバグであるかどうかについて、ベンダーと調査しています。
しかし、私が実際に理解しようとしているのは、その原子性保証が実際にNFSに適用できるかどうかです。 rename()のアトミック性保証がマルチクライアントNFSシナリオに適用されるかどうかを誰かが明確にすることができますか？この機能が機能しているかどうかは実際にはわかりませんが、そもそも保証されていませんでした。
差出人： RFC181
手順RENAMEは、ディレクトリ内のfrom.nameで識別されるファイルの名前をfrom.dirからディレクトリ内のto.name、to.dirに変更します。操作は、クライアントに対してアトミックである必要があります。
関連する場合は、SL6.5クライアントがONTAP-CDOT8.3のNFSデータストアにアクセスします。
NFSでの競合状態の回避
これは常に楽しい課題であり、アプリケーションを書き直さずに私が知っている唯一の回避策は、オプションsyncを使用して共有をマウントし、no_wdelayを使用するようにNFSサーバーを変更することです。 NetAppでno_wdelayを設定する方法を思い出せません。
この方法の欠点は、この共有への同時書き込みが多い場合、それらが指数関数的に遅くなることです。その共有にno_wdelayを設定する方法をネットアップに尋ねるか、問題を説明することをお勧めします。彼らはより良いアイデアを持っているかもしれません。私は少なくとも8年間NetAppに触れていません。