Journaling

當系統在寫入檔案的過程中突然斷電或當機，磁碟上的資料可能處於不一致的狀態，例如 inode 已更新但對應的 data block 還沒寫入。Journaling 借用了資料庫 write-ahead logging 的概念，在正式修改檔案系統之前，先把即將執行的變更寫入一塊專用的 journal 區域。我們會學到兩種主要策略：physical journaling 直接記錄完整的 block image，而 logical journaling 只記錄高階的操作描述，後者可以大幅減少 journal 的寫入量。當 journal 中的 commit record 寫入完成後，我們才真正把變更套用到檔案系統本體，這個過程稱為 checkpointing。如果中途發生 crash，系統重啟時只需 replay journal 中已 commit 的紀錄，就能快速回復到一致的狀態，不需要像早期的 fsck 一樣掃描整顆磁碟。

Key Concepts

我理解為什麼檔案系統需要 crash consistency 機制，以及斷電或當機時可能造成哪些不一致的狀態

我理解 write-ahead logging（WAL）的核心原則：先將變更寫入 journal，再套用到檔案系統本體

我理解 physical journaling 與 logical journaling 的差異與各自的取捨，包括寫入量與恢復複雜度的不同

我理解 commit record 作為 atomicity boundary 的角色，決定一筆 transaction 是否需要在 crash recovery 時被 replay

我理解 checkpointing 的流程，即將 journal 中已 commit 的變更正式套用到檔案系統的 on-disk 結構

我了解 crash recovery 時 replay journal 的機制，以及這相比傳統 fsck 全磁碟掃描的優勢

Recommended Resources