(no commit message)
authorjustin <justin@web>
Fri, 20 Jan 2012 04:42:28 +0000 (20:42 -0800)
committerCharlie Root <root@leaf.dragonflybsd.org>
Fri, 20 Jan 2012 04:42:28 +0000 (20:42 -0800)
hammerscript/index.mdwn

index 3eff809..b7d58bd 100644 (file)
@@ -1,4 +1,3 @@
-
 Notes for Justin and Samuel to pass back and forth.
 
 
@@ -47,15 +46,16 @@ Modern filesystem trends
   
 Getting to know HAMMER (jcs)
 
-* The history
-* Development began?
-* Introduced in 2.0, in use since early 2008?
-* Feature timeline
+DragonFly, at its inception in 2003, was intended to be a single-system-image operating system, able to run on multiple machines but presenting a single running operating system to the user.  The increase in CPU cores has made that less desirable as a target, but being able to move data from volume to volume, no matter the location, is still useful.  
+
+Hammer is a filesystem designed to mirror disk volumes from server to server, retaining history and deduplicating data.  Development started in 2007, and was first released with DragonFly 2.0.  Deduplication was added in 2008 (??) and released with version 2.8.  (??)
+
+Hammer is a historical, fine-grained file system, saving the state of the disk every time the system commits to disk.  That fine-grained history means that old versions of files can be accessed at any point in time, live, as long as you have the disk space to hold that history of changes.  In addition, entire snapshots of Hammer volumes are saved, with read-only versions of the disk sitting for access.  This happens automatically, even with deleted files.  The amount of disk history retained is configurable.
+
+DragonFly also is able to mirror volumes from one disk to another, or from one machine to another, or even one machine to many slave machines.  It works over relatively slow links, too.  A Hammer volume can be mirrored to another off-site system as a backup strategy, or even to another local disk and a remote one at the same time.  The amount of history retention for each master and slave Hammer volume can be configured separately, so a large Hammer slave can be set to hold multiple months of disk activity, while the smaller Hammer master can keep much less, to conserve space.
 
-* Major differentiating features (each its own full sub-article)
-* Historical access
-* Mirroring
 * Deduplication
+* fast fsck, crc
 
 Deploying HAMMER