一、崩潰一致性(Crash Consistency)：
為了執行日誌調查，我們來看一個例子。 我們需要使用以某種方式更新磁碟結構的workload。 先以一個簡單的假設為例：將單個data block附加到現有文件。 通過打開文件，調用lseek（）將文件偏移量移至文件末尾，然後在關閉文件之前向文件發出單個4KB寫入來完成附加操作。
假設我們在磁碟上使用標準的簡單文件系統結構，其類似於我們以前見過的文件系統。
這個例子包括：
- inode bitmap（只有8位，每個inode）
- data bitmap（也是8位，每個data block一個）
- inode（共8個，編號為0到7，分佈在四個block中）
- Data blocks （共8個，編號為0到7）。
以下是這個文件系統的圖表：
如果查看圖中的結構，可以看到在inodebitmap中標記了一個inode（inode編號2）和一個分配的數據塊（數據塊4），這些數據塊也標記在數據中bitmap。 inode表示為I [v1]，因為它是此inode的第一個版本; 它將很快更新（由於上述工作量）。
讓我們來看看這個簡化的inode。 在我[v1]的內部，我們看到：
在這個簡化的inode中，文件的大小是1（它有一個block），第一個pointer指向block 4（文件的第一個Data Blocks），而其他三個pointer 為空（表示它們未被使用）。 當然，真正的inode有更多的domain。
當我們追加文件時，我們正在為它添加一個新的Data block，因此必須更新三個磁碟結構：(如下所述)
- inode（必須指向新block）
- 新Data Blocks Db
- 新版本的data bitmap（稱之為B[v2]）
才能指示新Data Blocks已經被分配。
因此，在系統的memory中，我們有三塊，必須寫入磁碟。 更新的inode（inode版本2，簡稱I [v2]）現在看起來像這樣：
更新後的資料bitmap（B[v2]）現在看起來像這樣：00001100.
最後，有Data Blocks（Db），可填充使用者放入的任何內容文件(例如：音樂)。
我們想要的是文件系統的最終磁盤image如下所示：
為了實現這種轉換，文件系統必須對磁碟執行三次獨立寫入操作，每次對inode（I [v2]），bitmap（B [v2]）和數據塊（Db）執行一次寫入。
請注意，當用戶發出write（）系統調用時，這些寫入的操作通常不會立即發生；而是會汙染內存空間。
首先bitmap和新數據將駐留在主內存中（在頁面緩存或緩衝區緩存中）一段時間; 那麼，當文件系統最終決定將它們寫入磁碟（例如5秒或30秒之後）時，文件系統將向磁碟發出必要的寫入請求。
不幸的是，過程中可能會發生崩潰，從而干擾磁盤的這些更新。
尤其是，如果在發生一次或兩次寫入之後發生崩潰，但不是全部三次，則文件系統可能會處於一種有趣的狀態。
