當網路中斷發生時，位於已掛載 NFS 目錄上的二進製文件的執行是否會失敗？
所以我有一台充當 NFS 伺服器的 Linux 機器。許多程序已安裝到要導出的文件夾中。
在另一台 Linux 機器上，我一直在執行一個位於導出的 NFS 文件夾中的程序很長時間，但它不會很快完成。
原來，現在我需要對網路做一些緊急的維護工作，所以網路會出現一段時間的宕機。
我想知道正在執行的程序會發生什麼？
我的理解是程序以惰性方式載入到 RAM 中。所以在最好的情況下，假設程序正在執行一些已經載入到 RAM 中的循環部分程式碼，那麼在網路中斷期間它根本不需要訪問執行檔，並且程序將繼續正常執行，就像什麼都沒發生一樣，對吧？
但是，如果事實證明程序確實需要將執行檔的其他部分載入到 RAM 中並且網路目前已關閉。它會“凍結”一段時間，然後在網路啟動時繼續正常執行嗎？
我在想這個載入過程最終會呼叫一些與 io 相關的系統呼叫，而這些系統呼叫最終將由 NFS 客戶端庫處理。如果網路斷開，NFS 客戶端庫將在網路斷開的時間段內繼續重試，然後在網路正常執行時返回成功。所以從系統的角度來看，這看起來就像一個系統呼叫需要很長時間。
我不確定我的推理，特別是對於載入過程的一部分。將部分執行檔載入到 RAM 中時，作業系統會呼叫 io 相關的系統呼叫嗎？或者它是否可以繞過系統呼叫並以更低級別的方法執行然後失敗，這樣我的程序的執行將由於失敗而停止？
另外，我是否需要在推理時考慮 NFS 記憶體策略？
謝謝~！
您的理解並不完全正確，但非常接近。該程序確實是一頁一頁地延遲載入的。（其中一些實際上可能會在使用前載入，但這是性能與記憶體之間的權衡，而不是您可以指望的東西。）
執行載入的系統部分是核心本身。最遲在程序需要該塊記憶體時載入頁面，以訪問數據或跳轉到機器指令。它的工作方式是處理器中的每個記憶體訪問都通過MMU；如果包含請求訪問的頁面映射到程序的 MMU 表中，則 CPU 只需訪問記憶體；如果頁面未映射，則觸發陷阱，該陷阱在核心中執行一段程式碼，分析陷阱原因，分配物理記憶體頁面，載入所需的頁面內容並將控制權返回給程序以執行訪問再次。
當記憶體頁被程序修改時，它的內容可能會被放入交換區，然後再載入回來。當記憶體頁面直接來自文件（可執行或不可執行）時，其內容將從該文件載入。這不會通過系統呼叫，因為它都發生在核心內部，但它會進行與訪問文件的系統呼叫相同的低級訪問。
結果是，如果儲存正在執行的執行檔的文件系統變得不可訪問，則該程序將掛起。它將保持不間斷的睡眠，直到文件系統為請求提供服務。
如果執行檔位於 NFS 上並且 NFS 文件系統使用該
hard選項掛載，則執行檔將永遠等待或直到伺服器回复，以先到者為準。如果 NFS 文件系統使用該soft選項掛載，則 NFS 請求將在超時後失敗，這會轉化為程序的信號（我認為是 SIGSEGV，即 segfault）。