1 / 15

Chapter 42 Crash Consistency: FSCK and Journaling

Chapter 42 Crash Consistency: FSCK and Journaling. Jeongsoo Shin ( j eongsoo.shin@snu.ac.kr ) School of Computer Science and Engineering Seoul National University. Outline. File Append Example Crash Scenarios FSCK Journaling Data Journaling Metadata Journaling Summary.

overman
Download Presentation

Chapter 42 Crash Consistency: FSCK and Journaling

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Chapter 42Crash Consistency: FSCK and Journaling Jeongsoo Shin (jeongsoo.shin@snu.ac.kr) School of Computer Science and Engineering Seoul National University

  2. Outline • File Append Example • Crash Scenarios • FSCK • Journaling • Data Journaling • Metadata Journaling • Summary

  3. File Append Example Inode Bitmap Data Bitmap Inodes Data Blocks Db v1 Da v2

  4. Crash Scenarios (1/2) Inode Bitmap Data Bitmap Inodes Data Blocks Db v1 Da Inode Bitmap Data Bitmap Inodes Data Blocks v2 v1 Da Inode Bitmap Data Bitmap Inodes Data Blocks v1 Da

  5. Crash Scenarios (2/2) Inode Bitmap Data Bitmap Inodes Data Blocks v1 Da v2 Db Inode Bitmap Data Bitmap Inodes Data Blocks Db Db v1 Da Inode Bitmap Data Bitmap Inodes Data Blocks v1 Da v2

  6. Solution #1: File System Checker • Scans the entire file system multiple times, identifying and correcting inconsistencies • fsck • Validates the superblock • Rebuild the bitmaps by scanning all inodes • Deletes the duplicated pointers • Removes the bad pointers • Verifies the integrity of all directories

  7. Solution #2: Journaling (or Write-Ahead Logging) Superblock Journal Group 0 Group 1 … Group N Records each update to the file system as a transaction All transactions are written to a log If the file system crashes, all remaining transactions in the log must be performed ext3 and NTFS use journaling

  8. Data Journaling Example I v2 Db TxE ID=1 TxB ID=1 B v2 Journal • Begin a new transaction with a unique ID=k • Write the updated meta-data block(s) • Write the file data block(s) • Write an end-of-transaction with ID=k • Three writes: inode v2, data bitmap v2, data D2

  9. Checkpointing I v2 Db TxE ID=1 TxB ID=1 B v2 Journal Checkpoint Inode Bitmap Data Bitmap Inodes Data Blocks Db v1 Da v2 • Writes the data from the log out to disk

  10. Data Journaling Timeline File System Journal

  11. Crash Recovery (1/2) I v2 Db TxE ID=1 TxB ID=1 B v2 Journal No Change Inode Bitmap Data Bitmap Inodes Data Blocks Db v1 Da • Scenario : system crashes during logging

  12. Crash Recovery (2/2) I v2 Db TxE ID=1 TxB ID=1 B v2 Journal Checkpoint Inode Bitmap Data Bitmap Inodes Data Blocks v2 Db v1 Da Reboot • Scenario : system crashes during checkpointing

  13. Metadata Journaling I v2 TxE TxE ID=1 TxB ID=1 B v2 Journal Inode Bitmap Data Bitmap Inodes Data Blocks v2 Db v1 Da The most expensive part of data journaling is writing the data twice ext3 metadata journaling

  14. Metadata Journaling Timeline Journal File System

  15. Summary • Modern systems use journaling • ext3 / ext4 on Linux • NTFS on Windows • Journaling reduces recovery time • Metadata Journaling reduces the amount of traffic to the journal

More Related