[Tux3] Design note: Log replay, continued

[Daniel Phillips]

One detail I omitted in the previous post: log entry replay is not 
idempotent, that is, a log entry such as an insert may not be replayed 
against a block that already has the inserted item.  The traditional 
method of dealing with this is to check the target block to see if the 
item is already present.

Tux3 uses a more precise mechanism: it is guaranteed that the physical 
block against which the entry is replayed is the version against which 
the entry was calculated.  This guarantee is possible because of the 
rule that a metadata block that is part of a consistent disk image is 
never overwritten.  Instead, it is always directed to a new location, 
and a retire entry is made for the original block, which prevents 
replay of any promises made against that block.  The redirect stores 
the full copy of the block, current as of the latest delta, making any 
promises against its earlier version redundant.  Thus, for any given 
block against which promises exist in the log, the block is either 
retired, or has the original data against which the promises were 
calculated.

Similarly, freeing a metadata block puts a retire entry in the log.

In an upcoming design note I will explain the role that buffer forking 
plays in saving the correct version of a physical block.

Daniel

_______________________________________________
Tux3 mailing list
Tux3 at tux3.org
http://mailman.tux3.org/cgi-bin/mailman/listinfo/tux3