File System Caching and Consistency

Use a cache! (Put a smaller, faster thing in front of it.)

as memory (duh), but also

to cache file data in order to improve performance.

Big buffer cache, small main memory: file access is fast, but potential thrashing in the memory subsystem…​

Small buffer cache, large main memory: little swapping occurs but file access is extremely slow.

Entire files and directories!

open, close, read, write. (Same as the file system call interface.)

Pass down to underlying file system.

If file is not in the buffer cache, pass down to underlying file system and load contents into the buffer cache.

If the file is in the cache, return the cached contents.

If file is not in the buffer cache, pass load contents into the buffer cache and then modify them.

If the file is in the cache, modify the cached contents.

Remove from the cache (if necessary) and flush contents through the file system.

Buffer cache sees file operations, may lead to better prediction or performance.

Hides many file operations from the file system, preventing it from providing consistency guarantees.

Can’t cache file system metadata: inodes, superblocks, etc.

Disk blocks!

readblock, writeblock. (Same as the disk interface.)

Can cache all blocks including file system data structures, inodes, superblocks, etc.

Allows file system to see all file operations even if they eventually hit the cache.

Cannot observe file semantics or relationships.

Objects in the cache are lost on failures!

May increase the time span between when the first write of the operation hits the disk and the last is completed.

Don’t buffer writes!

We call this a write through cache because writes do not hit the cache.

Buffer all operations until blocks are evicted.

We call this a write back cache.

performance?

safety?

Write important file system data metadata structures—superblock, inode maps, bitmaps, etc.—immediately, but delay data writes.

What’s not atomic? Writing multiple disk blocks.

What is atomic? Writing one disk block.

Track pending changes to the file system in a special area on disk called the journal.

Following a failure, replay the journal to bring the file system back to a consistent state.

Update the journal!

This is called a checkpoint.

Start at the last checkpoint and work forward, updating on-disk structures as needed.

These are ignored as they may leave the file system in an incomplete state.

We could include them in the journal meaning that each data block would potentially be written twice (ugh).

We could exclude them from the journal meaning that file system structures are maintained but not file data.