Completing the Solution: The Checkpoint Region

The clever reader (that’s you, right?) might have noticed a problem here. How do we find the inode map, now that pieces of it are also now spread across the disk? In the end, there is no magic: the file system must have some fixed and known location on disk to begin a file lookup.

LFS has just such a fixed place on disk for this, known as the checkpoint region (CR). The checkpoint region contains pointers to (i.e., addresses of) the latest pieces of the inode map, and thus the inode map pieces can be found by reading the CR first. Note the checkpoint region is only updated periodically (say every 30 seconds or so), and thus performance is not ill-affected. Thus, the overall structure of the on-disk layout contains a checkpoint region (which points to the latest pieces of the inode map). The inode map pieces each contain addresses of the inodes and the inodes point to files (and directories) just like typical UNIX file systems.

Here is an example of the checkpoint region (note it is all the way at the beginning of the disk, at address 0), and a single imap chunk, inode, and data block. A real file system would of course have a much bigger CR (indeed, it would have two, as we’ll come to understand later), many imap chunks, and of course many more inodes, data blocks, etc.