HAMMER update - 22 June 2008. heads up on hammer prune vs softprune.

[Matthew Dillon]

    Heads up - 'hammer prune' is being removed, 'hammer softprune' is going
    to become the official way to prune the filesystem.  I will add a
    'hammer pruneall' command for emergencies which will do the same thing
    that 'hammer prune everything' does now.

    There are two reasons for doing this.  First and foremost, transaction
    id's can wind up not reflecting the current date and time.  If the
    filesystem is modified while the system time is off kilter it can cause
    the transaction id to jump.  If the system time is then corrected HAMMER
    cannot back-up the transaction id and the ids will no longer match the
    time.  If this occurs the old pruning commands stop working properly.
    I want to make a clean break before the release so transaction ids
    are not assumed to be time stamps, even if they kinda act like timestamps.

    The second reason is that it is a whole lot easier to manage pruning
    based on a directory full of softlinks.  Amoung other things we will
    be able to implement different pruning regimens for different parts of
    the directory hierarchy.

    --

    Pseudo-fs support will be committed today.   A pseudo-filesystem is
    basically a HAMMER filesystem inside a HAMMER filesystem, with its
    own inode numbering space.  Pseudo-fs's can also be pruned
    independantly.  The primary reason for doing this is for mirroring
    support but ultimately it will also remove the need to partition
    the drive.

    --

    I still have some issues to work through on the mirroring support, but
    its looking better for the release.  The main problem is figuring out
    how to make it work in a multi-master environment (something we will
    have to support for the later clustering work).  That is, so changes
    made on one machine propogate to the other mirrors and vise-versa without
    creating mass confusion.

    Ultimately (looking forwards into the clustering goal) DragonFly will
    have to do conflict resolution and cache coherency in a kernel layer
    to ensure that only non-conflicting modifications reach the underlying
    filesystem.  But in a multi-master environment, once the OS has decided
    a modifiying operation can run, the changes are committed to one of
    the N master copies of the filesystem and then must propogate to the
    other masters.  Any master must be able to propogate to any other
    master, all in parallel.  The underlying mirroring code being worked
    on now will also be responsible for multi-master updates.

    For the release we will have the mirroring support, but not the
    conflict resolution support.  The mirroring support just by itself
    will be a very powerful tool of course.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>