操作系統三大核心：虛擬性，并發，持久性

虛擬：

 

關鍵概念：引入進程

正在運行的c程序

想要構建的系統：

虛擬CPU（極短的CPU完成任務切換），安全問題引出受限制的系統，即內核與用戶級，內核擁有全部資源trap table 進入內核等級的系統調用

虛擬化CPU考慮的問題，進程之間調度

1.切換線程：由系統完成切換 引出問題

如何完成切換？OS如何獲得控制權？

CPU完成調度，切換是根據進程表，包含有進入地址（具體調度策略后面再講），通過時鐘中斷（時間片是心臟），CPU如何保存進程信息，執行到那個指令和入口地址呢？？？關鍵點 保存和恢復上下文

 

調度策略

不說了

 

地址空間

核心：空閑空間管理以及快速地址轉化

圍繞了虛擬化內存保護系統，以及程序運行（無須指定加載和運行地址）。

并發

講了進程和線程之間的通信與同步（以后再說，這個偏實踐和用的）

持久性

NFS 文件系統

一、 核心思想：協議之上的虛擬文件系統

NFS 的本質是一個分布式文件系統協議。它的目標是讓用戶能夠像訪問本地文件一樣，通過網絡訪問遠程服務器上的文件，而對用戶和應用程序來說，這個過程是透明的。

  • 實現方式:

    • 客戶端: 在 Linux 內核中實現為一個虛擬文件系統 (VFS) 的客戶端。當應用程序發起 open, read, write 等系統調用時，VFS 會判斷目標路徑是否為 NFS 掛載點。如果是，VFS 不會將操作傳遞給本地的磁盤驅動，而是將其轉化為一系列 NFS RPC (遠程過程調用) 請求。

    • 服務端: 運行一個 NFS 服務進程，負責監聽并處理來自客戶端的 RPC 請求，執行真正的本地文件系統操作（如 ext4 的讀寫），然后將結果返回給客戶端。

沒有源碼 沒有圖，只是基于目的 等等進行一個猜測 ！！！！

look up協議

mount -t nfs -o vrer=3 nolock 192.168.6.12 :/home/book/nfs_rootfs /mnt

IP地址 192.168.6.12 |本地掛載點 | 本地掛載點 | 目標掛載點

返回文件句柄等 

write協議[前提已經打開了文件]

客戶 操作請求 | 文件句柄 | 操作內容

服務器 操作請求--> (open，write，close） message -->協議規定了如何操作

 

二、 關鍵基石：無狀態協議 

這是 NFS (尤其是 NFSv2/v3) 設計哲學的核心，也是它與許多其他網絡協議的根本區別。

  • 概念: 服務器不保留任何關于客戶端連接狀態的信息。服務器處理的每一個請求，都必須包含完成該操作所需的全部信息。

  • 為什么無狀態？: 為了健壯性 (Robustness)。

    • 服務端崩潰恢復: 如果服務器突然崩潰重啟，它不需要恢復任何連接狀態。當客戶端再次發送請求時，服務器可以像處理第一個請求一樣處理它，因為所有信息都在請求里。

    • 客戶端崩潰無影響: 如果客戶端崩潰，它沒有在服務器上“占用”任何資源（比如打開的文件句柄）。服務器端不會因此產生任何資源泄漏。

三、 核心抽象：文件句柄 (File Handle)

既然服務器是無狀態的，它不記錄“哪個客戶端打開了哪個文件”，那么客戶端如何持續地對同一個文件進行操作呢？答案就是文件句柄。

  • 概念: 文件句柄是服務器為文件系統中的每一個文件或目錄生成的一個唯一的、持久的標識符。它就像是文件的“身份證號碼”。

  • 構成 (通常):

    1. 文件系統標識 (Filesystem ID): 區分服務器上不同的分區或文件系統。

    2. Inode 號 (Inode Number): 文件在文件系統內的唯一編號。

    3. 世代號 (Generation Number): 一個隨機數。當一個 Inode 號被重新使用時（例如，刪除一個文件后，又創建了一個新文件恰好用了同一個 Inode 號），世代號會改變。

  • 作用:

    • 唯一標識: 文件系統ID + Inode號 + 世代號 的組合，可以在服務器的整個生命周期內唯一地標識一個文件，完美地解決了 Inode 復用帶來的歧義問題。

    • 替代狀態: 客戶端的每一個 read 或 write 請求，都會帶上這個文件句柄，告訴服務器：“我要操作的是擁有這個‘身份證號’的文件”。服務器不需要記住你之前做過什么，只需要根據這個句柄去找到對應的文件即可。

四、 應對網絡不可靠：操作的冪等性 (Idempotency)

網絡是不可靠的，客戶端發送一個請求后，可能因為網絡超時而無法確定服務器是否已處理。

  • 概念: 冪等性指一個操作無論執行一次還是執行多次，產生的結果都是相同的。

  • NFS 如何實現:

    •  / : 這些只讀操作天然是冪等的。

    • WRITE: WRITE 請求中包含了文件句柄、固定的偏移地址 (offset) 和數據。客戶端如果超時，可以無腦地重發同一個 WRITE 請求。因為每次寫入的位置和內容都完全一樣，即使服務器收到了兩次，也只是把同一塊數據在同一個位置覆蓋了一遍，文件最終的狀態是一致的。

    • 非冪等操作: CREATE (創建文件) 和 REMOVE (刪除文件) 不是冪等的。NFS 客戶端需要更復雜的機制（如事務ID）來確保這類操作只被成功執行一次。

五、 提高性能：客戶端緩沖 (Client-Side Caching)

無狀態協議的每次操作都需要通過網絡，效率低下。因此，客戶端緩沖是提升 NFS 性能的關鍵手段。

  • 機制:

    • 寫緩沖 (Write Caching): 當應用程序 write 數據時，NFS 客戶端通常先把數據緩存在本地內存的“頁緩存 (Page Cache)”中，并立即向上層應用返回成功。內核會在稍后的某個時刻（或緩沖區滿時）將多個小的寫操作合并成一個大的 WRITE RPC，一次性地發給服務器。

    • 讀緩沖 (Read Caching): 當應用程序 read 文件時，客戶端會一次性從服務器讀取一個較大的數據塊（預讀），并緩存在本地頁緩存中。后續的 read 請求如果命中緩存，就可以直接從內存返回，無需網絡交互。

六、 緩沖帶來的挑戰：數據一致性 (Cache Consistency)

緩沖極大地提升了性能，但也引入了經典的一致性問題：

  • 場景:

    • 客戶端 A write 了一個文件，數據還停留在 A 的本地緩存中。

    • 客戶端 B 此時去 read 同一個文件，它會從服務器讀到舊的數據，因為它不知道 A 已經做了修改。

  • 解決方案 (以 NFSv3 為例):

    • 關閉時刷新 : NFS 提供了一種弱一致性保證。當客戶端 A 修改完文件并調用  時，NFS 客戶端必須將所有寫緩存刷新 (flush) 到服務器。當客戶端 B 調用  打開該文件時，它會向服務器發起一個 GETATTR 請求，獲取文件的最新屬性（如修改時間）。

    • 屬性校驗: 客戶端 B 會比較自己緩存的文件的屬性和從服務器獲取的最新屬性。如果發現不一致（比如修改時間變了），B 就會主動使其本地緩存失效 (invalidate)，確保下一次 read 會去服務器重新拉取最新的數據。