Of Episodes, Phases and Forks

[Matthew Dillon]

:(Daniel writes)
:
:Hi Matt,
:
:I copied you on this post for comment by way of fullfilling a promise I 
:made a couple of months ago to describe the Tux3 atomic commit strategy 
:in greater detail.
:
:In a previous post I described the physical write pattern we wish to 
:produce during a particularly common kind of heavy write load[1], but 
:did not explain how that write pattern actually implements an atomic 
:commit or how Tux3 will go about generating it.  Today I will address 
:that omission by describing in some detail what goes on behind the 
:scenes, and how the desired ACID compliant behavior is to be achieved.

    Thanks Daniel, I tihnk that gives me a pretty good understanding.
    It certainly looks like a viable solution to me.

:The same rule applies recursively to the parent block, however Tux3 does 
:not remap recursively all the way to the root of the filesystem tree as 
:in my original Phase Tree design[2].  Instead, it encodes in the commit 
:block of the update transaction a promise to modify the parent block on 
:disk some time in the future, while actually making the modification 
:only to the cached version of the parent block.

    Very well worded.  I like the concept of the 'promise'.

:...
:the parents of member blocks.  Each promise is a triple:
:
:   { body extent, parent address, offset }

    There may be an issue when making multiple updates to related meta-data.
    For example, if inserting an element in a B-Tree the extent of the
    modification to the block may cover most of the block even though the
    actual operation is just an insertion.

    You might have to make the promises more sophisticated to be able to
    record such modifications without generating large amounts of data
    in the promise tuple.

    Side note:  HAMMER uses an unsophisticated method when generating its
    UNDO, but because the UNDO works in reverse of your promise, multiple
    modifications to the same meta-data within a single phase (using your
    terminology) only needs the initial UNDO and can throw away the
    generation of followup UNDOs for each modification covering the same
    meta-data space.

    The block forking sounds interesting.  I like that idea.

    I'm still working through the second half of your posting.


					-Matt
					Matthew Dillon 
					<dillon at backplane.com>