ページキャッシュで100％ページングされたファイルが他のプロセスによって変更された場合はどうなりますか？

その後、連続リリースは/apps/EXEを新しい実行可能ファイルに置き換えます。

これが重要な部分です。

新しいファイルを公開するには、新しいファイル（例：）を作成し/apps/EXE.tmp.20190907080000、コンテンツを作成し、権限と所有権を設定し、ついに(2) 最後の名前に名前を変更し、古い/apps/EXEファイルを変更します。

結果は新しい inode 番号を持つ新しいファイルです。つまり、事実上別のファイルです。

そして古いファイルには独自のinode番号があります。まだそこにいるファイル名がもはやその項目を指していなくても（またはそのinodeを指すファイル名はもうありません）。

したがって、ここで重要なのは、Linuxで「ファイル」について話すとき、通常実際に言うのは「inodes」ということです。なぜなら、ファイルが開いたら、inodeは私たちが保持しているファイルへの参照であるからです。

仮説1：プロセスP（および以前の実行可能ファイルを参照するファイル記述子を持つ他の誰も）は問題なく古いメモリ/ apps / EXEを引き続き使用し、そのパスを実行したいすべての新しいプロセスは新しい実行可能ファイルを取得すると仮定します。

正しい。

仮説2：ファイル内のすべてのページがメモリにマップされていない場合は、ページエラーが発生するまですべてが問題ないと仮定します。ファイルで置き換えられたページが必要で、セグフォルトも発生する可能性がありますか？

間違っています。古い inode がまだ存在するため、古いバイナリを使用しているプロセスのページエラーがディスク上のそのページを探すことができます。

以前のバイナリを実行しているプロセスの/proc/${pid}/exeシンボリックリンク（またはそれに対応する出力）を見ると、それに伴ういくつかの効果を確認できます。その後、名前はもう存在しませんが、inodeはまだ存在することがわかります。lsof/app/EXE (deleted)

また、バイナリで使用されるディスク領域は、プロセスが終了した後にのみ解放されることがわかります（対応するinodeが開いている唯一のプロセスであると仮定）。dfプロセス終了前後の出力を確認すると、もはや存在しないと思っていた以前のバイナリと同じくらいサイズが小さくなったことを確認できます。

ただし、これはバイナリファイルにのみ適用されるのではなく、開いているすべてのファイルに適用されます。プロセスでファイルを開いてファイルを削除すると、プロセスがファイルを閉じるか終了するまで、そのファイルはディスクに残ります。ハードリンクがディスクのinode名を指すカウンタを保持するのと同様に、ファイルシステムドライバ（Linuxカーネル）はそのinodeへの参照数のカウンタを保持します。記憶の中、実行中のシステムでそのinodeへのすべての参照が解放された後にのみ、inodeはディスクから解放されます。

質問1：vmtouchなどのツールを使用してファイル内のすべてのページをロックすると、状況が変わりますか？

この質問は、ページをロックしないとセグフォルトが発生するという誤った仮定2に基づいています。しないでしょう。

質問2：/apps/EXEがリモートNFSにある場合、違いはありますか？ （そうではありません）

それ意味はほとんどの場合、同じように動作しますが、NFSにはいくつかの「問題」があります。

時々、NFSでまだ開いている削除されたファイルを見ることができます（そのディレクトリに隠しファイルとして表示されます）。

NFSサーバーの再起動時にデバイス番号が「シャッフル」されないように、NFSエクスポートにデバイス番号を割り当てることもできます。

しかし、主なアイデアは同じです。 NFS クライアントドライバはまだ inode を使用し、inode が引き続き参照されている間 (サーバ上で) ファイルを保存しようとします。