Re: Regarding Filesystems

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

: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>