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 [email protected] http://mailman.tux3.org/cgi-bin/mailman/listinfo/tux3
