HAMMER filesystem update - design document

[Matthew Dillon]

:Awesome!
:
:Tells me: "ZFS, bend over, grab your ankles and kiss your an(atomy) 'Goodbye'"
:
: From the amount of work that has HAD to go into this, it also tells me you are:
:
:A) probably single, or soon will be and

    Alas.

:B) don't sleep much anyway!
:...
:Bill Hacker

    I get a good 8 hours of sleep.  As I get older I find myself unable to
    pull all-nighters any more without really screwing up the entire next
    day.

    --

    ZFS serves a different purpose and I think it is cool, but as time
    has progressed I find myself liking ZFS's design methodology less and
    less, and I am very glad I decided against trying to port it.  I do
    not think it is a good idea to put all one's marbles in a single copy
    of a filesystem, no matter how redundant its storage model is, and there
    isn't much point having that level of redundancy if the intent is
    to operate in a replicated environment.

    The problem ZFS has is that it is TOO redundant.  You just don't need
    that scale of redundancy if you intend to operate in a multi-master
    replicated environment because you not only have wholely independant
    (logical) copies of the filesystem, they can also all be live and online
    at the same time.

    HAMMER's approach to redundancy is logical replication of the entire
    filesystem.  That is, wholely independant copies operating on different
    machines in different locations.

    Ultimately HAMMER's mirroring features will be used to further our
    clustering goals.  The major goal of this project is transparent
    clustering and a major requirement for that is to have a multi-master
    replicated environment.  That is the role HAMMER will eventually fill.
    We wont have multi-master in 2.0, but there's a good chance we will
    have it by the end of next year.

						-Matt