既存のファイルを書き換えて、完全に一度だけ書き込まれた後、アトミックに新しいバージョンに置き換えられるようにします

私は漠然と、どこかで読んだことを覚えています。一部のUnicesでは、既存のファイルを書き込み用に開き、カーネルに古いバージョン（読み取り用にアクセスする他のプロセス）を使用するように要求するフラグがあり、「新しい"バージョンは完全に記述され（fdは閉じられます）、その時点からファイルは新しいバージョンとして表示されました。

言い換えると、他のプロセスは、古いバージョンまたは新しいバージョンのいずれかを認識し、不完全に記述されたバージョンは認識しませんでした。

知識のある人が私に参照を示すことができますか？

あなたが説明しているのは、ファイルを上書きする基本的な名前変更とまったく同じです。

あるファイルを別のファイルの上に名前変更/移動すると、古いファイルはリンク解除されます。ファイルはまだ存在していますが、ファイルシステムツリーには存在しません。したがって、古いアプリケーションは、開いたままである限り、引き続きファイルにアクセスできます。すべてのアプリケーションが古いファイルを閉じると、実際にはディスク上で未割り当てになります。

renameシステムコールはアトミック操作です。そのためには、別の名前で新しいファイルを作成してrenameから、一時ファイルの名前を変更して、一時ファイルの名前を変更します。操作はアトミックであるため、ファイルが欠落している期間は絶対にありません。すぐに古いファイルから新しいファイルに移動します。
ただし、一時ファイルと置き換えられるファイルは同じマウントポイントに存在する必要があることに注意してください。

パトリックの書き込み、これを行うための通常の方法は、アトミックそれを上書きし、古いファイル名に、新しいバージョンを別のファイルに新しいバージョンを書き、そして時に完成し、リネームすることです。この2番目の操作は、overwrite-by-renameと呼ばれます。

次に、いくつかの参照：

• ISO Cはrenameアトミックである必要があります。Open Group Base Specificationsから：

  新しい引数で指定されたリンクが存在する場合、そのリンクは削除され、古い名前がnewに変更され ます。この場合、newという名前のリンクは、名前変更操作全体を通して他のプロセスに表示されたままになり、操作が開始される前にnewまたはoldによって参照されるファイルを参照します。

• Mac OS Xの古いバージョンには、アトミックな名前変更がありませんでした。これはLionで修正されたと伝えられています。

• パフォーマンス上の理由から、Btrfsはアトミックな名前変更を保証しないことにより、明らかに意図的に標準に違反しています。ただし、overwrite-by-renameはまだatomicであり、この目的に必要なのはこれだけです。

これは、Allocate On Flushを思い出させます。ファイルシステムがこの機能を使用すると、ディスクに直接データを書き込むのではなく、ディスクの空き領域カウンターから書き込むデータのサイズを減算し、同期システムコールが実行されるか、カーネルが決定するまでデータをメモリに保持しますダーティバッファをフラッシュします。

この場合、ファイルが1つのプロセスによって変更され、別のプロセスによって開かれた場合、後者のプロセスはファイルの変更されていない（または「古い」）バージョンを「参照」します。

もちろん、上記は理論的なものであり、さまざまな要因に依存します。カーネルがダーティページをフラッシュするタイミングが正確にはわからないため、少し予測できないと思います。たとえば、Linuxの場合（Linuxカーネルの理解のセクション15.3を参照することもできます）、次の条件下でダーティページがディスクに書き込まれます。

• ページキャッシュがいっぱいになり、より多くのページが必要になるか、ダーティページの数が多くなりすぎます。

• ページが汚れたままになってから時間が経過しすぎています。

• プロセスは、ブロックデバイスまたは特定のファイルの保留中のすべての変更をフラッシュするように要求します。これは、sync（）、fsync（）、またはfdatasync（）システムコールを呼び出すことでこれを行います。

この機能は、HFS +、XFS、Reiser4、ZFS、Btrfs、ext4ファイルシステムに実装されていることが知られています。