A Detailed Example
Explore how file systems maintain crash consistency by examining a detailed example involving appending data. Learn about the roles of inodes, data bitmaps, and data blocks, and how crashes can cause inconsistencies. This lesson clarifies the challenges in achieving atomic updates and the importance of journaling and fsck for preserving file system integrity.
We'll cover the following...
To kick off our investigation of journaling, let’s look at an example. We’ll need to use a workload that updates on-disk structures in some way. Assume here that the workload is simple: the append of a single data block to an existing file. The append is accomplished by opening the file, calling lseek() to move the file offset to the end of the file, and then issuing a single 4KB write to the file before closing it.
Let’s also assume we are using standard simple file system structures on the disk, similar to file systems we have seen before. This tiny example includes an inode bitmap (with just 8 bits, one per inode), a data bitmap (also 8 bits, one per data block), inodes (8 total, numbered 0 to 7, and spread across four blocks), and data blocks (8 total, numbered 0 to 7). Here is a diagram of this file system:
If you look at the structures in the picture, you can see that a single inode is allocated (inode number 2), which is marked in the inode bitmap, and a single allocated data block (data block 4), also marked in the data bitmap. The inode is denoted I[v1], as it is the first version of this inode; it will soon be updated (due to the workload described above).
Let’s peek inside this simplified inode too. Inside of I[v1], we see:
In this simplified ...