"(Everything I Do) I Do It for You" replaces "Eye of the Tiger".

"The Silence of the Lambs" replaces "Gandhi".

Disk bandwidth is improving rapidly, meaning the operating system can stream reads or writes to the disk faster.

Computers have more memory. Up to 128 MB! (Whoa.)

And, alas, disk seek times are … still dog slow!

Oh, by the way: we’ve got a bunch of spare memory lying around. Might that be useful?

Use a cache! Or, put a smaller, faster thing in front of it.

In the case of the file system the smaller, faster thing is memory.

We call the memory used to cache file system data the buffer cache.

With a large cache, we should be able to avoid doing almost any disk reads.

But we will still have to do disk writes, but the cache will still help collect small writes in memory until we can do one larger write.

Great…​ um…​ how do we do that?

But some thorny details to address.

When the user calls sync, fsync or when blocks are evicted from the buffer cache.

It stored the inode map in a fixed location on disk.

inodes are just appended to the log and so they can move!

Yep, it logs the inode map.

We can log that stuff too!

Probably a lot of unused space earlier in the log due to overwritten inodes, data blocks, etc.

Clean the log by identifying empty space and compacting used blocks.

LFS seems like an incredibly great idea…​ until you start thinking about cleaning.

(Then it becomes a debatably great idea…​)

Probably when the system is idle, which may be a problem on systems that don’t idle much.

Large segments amortize the cost to read and write all of the data necessary to clean the segment.

…​but small segments increase the probability that all blocks in a segment will be "dead", making cleaning trivial.

Cleaner overhead is very workload-dependent, making it difficult to reason about the performance of log-structure file system. (And easy to fight about their performance!)

Block allocation is extremely discontiguous, meaning that reads may seek all over the disk.