Re: Regarding Filesystems

From:

Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>

Date:

Mon, 28 Jul 2008 09:44:38 -0700 (PDT)

:On the other hand, the "mirroring" feature in HAMMER is
:not really a RAID-1 (which is what people usually mean
:when they talk about a mirror in the context of storage).
:It is rather a replication mechanism, too, not completely
:unlike DF's VFS journaling.
:
:So, in other words, DragonFly now supports two different
:FS replication features, one of them is called journaling
:and the other is called mirroring, while it is neither
:really the one or the other. :-)
:
:(Please don't take this as criticism. I'm just trying to
:explain my confusion.)
:
:Best regards
: Oliver
Yah, well the terminology gets a bit mixed up because it all operates
in the logical layer instead of the physical layer. In the logical
layer mirroring and replication mean just about the same thing. I've
been saving the term 'replication' for the multi-master cluster stuff.
Generally speaking I view replicated systems as being multi-master,
and I view mirrored systems as being less integrated single-master
systems.
The high level VFS journaling was originally intended to be used as
part of the cluster synchronization mechanic (and it still might be),
but the implementation in the tree never got much past the replication
elements. Even so there is additional audit-trail information in
the stream. There is no single term that describes its function set.
The big issue with DragonFly's older high level VFS journaling is that
it is queued... if the pipe stalls, so to does the filesystem, and if
you interrupt the stream you wind up back at square-one. Plus even if
the pipe doesn't stall it can still severely effect filesystem
performance. That limits its usefulness.
HAMMER's mirroring is not queued. Mirroring operations are completely
disconnected from frontend filesystem operations, so the filesystem
is unaffected if a mirroring operation stalls. HAMMER's mirroring has
no limitations on the number of mirroring targets, on chaining mirrors,
on link speed, or on link reliability. You can kill and restart
a mirroring stream on a whim, or leave it disconnected for months and
then pick up where you left off, and so on and so forth. This makes
HAMMER's mirroring far more useful.
I'll give you an example... lets say you had a laptop and you wanted
to maintain a complete off-site backup of the laptop whenever it had
internet connectivity. With HAMMER's mirroring you can do that with
a little 5 minute cron job to probe internet connectivity and start
up bandwidth-limited incremental mirroring batches whenever you see
connectivity, without caring about disconnects. It would be
completely impossible to do that with high level VFS journaling.
-Matt
Matthew Dillon
<dillon@backplane.com>