About File system logging

This is a note @MIT OCW 6.824 Lecture 7:

The main point of a log is make complex operations atomic.

I.e. operations that involve many individule writes. You want all writes or none, even if a crash in the middle.

A "transaction" is multi-write operation that should be atomic. The logging system needs to know which set of write from a transication.

Re-do with checkpoint:

Most logs work like this, e.g. FSD,
allows much faster recovery: ca use on-disk data
write-ahead rule:

delay flushing dirty block from in-memory data cache until corresponding commit recore is on disk

Check point rules:

all data writes before check point must be stable on disk checkpoint may not advance beyond first uncommitted Begin

Recovery:

for each block mentioned in the log
find the last xaction that wrote that block
if committed: re-do
if not committed: un-do

Why is logging fast:

group commit -- batched log writes.
could delay flushing log -- may lost committed transactions but at least you have a prefix.

Single seek to implement a transaction.
maybe less if no intervening disk activity, or group commit

Write-behind of data allows batched/schedules.
one data block may reflect many transactions, i.e. create many files in a directory.
don't have to be so careful since the log is the real infomation.