hammerscript/index.mdwn

   1 Notes for Justin and Samuel to pass back and forth.
   2
   3
   4 Introducing HAMMER (sjg)
   5
   6 * About filesystems (what they do and how they do it, in brief)
   7 * Storage is exploding, facts
   8 * Users need features to manage the increasing complexity of storage management
   9 * Backups
  10 * Recovery
  11 * Snapshots / A "safety net"
  12
  13 The problems everyone thinks they have, but really don't -or- The problems HAMMER was NOT designed to solve
  14
  15 * Only somewhat suitable for large enterprise deployments
  16 * Not the primary design goal
  17 * Plenty of room to improve in this arena
  18 * Not really suitable for small systems
  19 * Still performs well under memory constraint
  20 * Can be tuned to work
  21
  22 The nail
  23
  24 * 2+ disk deployments, 1+ per server
  25 * 1-2+ server deployments
  26 * Low tolerance for data loss
  27 * "Most common low-end datacenter and home server scenarios"
  28
  29 How HAMMER compares to its peers and predecessors (sjg)
  30
  31 Traditional filesystems
  32
  33 * UFS
  34 * Ext2/3
  35 * FAT
  36 * General how & why
  37 * Conclusions
  38
  39 Modern filesystem trends
  40
  41 * Ext4
  42 * BTRFS
  43 * ZFS
  44 * Conclusions
  45 * The design and rationale of HAMMER
  46
  47 Getting to know HAMMER (jcs)
  48
  49 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.
  50
  51 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.  (??)
  52
  53 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, and the number of snapshots is limited only by total disk space.
  54
  55 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.
  56
  57 Hammer supports a feature found in higher-end filesystems: deduplication.  In general terms, a deduplicated system keeps track of all the data on a system.  When 2 ranges of data match exactly, the system keeps only one of those ranges, but maintains two references to it.  The total amount of space used on a disk can be greatly reduced, without changing the data stored.
  58
  59 Deduplication results vary depending on how much repeated data structures exist on a Hammer volume.  The results tend to be a 10% to 40% reduction in disk usage.
  60
  61 Hammer offers a number of other modern benefits:
  62
  63 * It will near-instantly recover from a crash, so boot times aren't increased after a system crash and reboot.  (No fsck needed.)
  64 * Hammer will checksum its data as part of deduplication and mirroring, so data errors can be detected.
  65 * Multiple pseudo-file-systems can be created on a single Hammer volume, and each one can have its own historical retention settings.
  66 * Historical snapshots are always live and always accessible.
  67 * Hammer volumes can be up to 1 exabyte in size.
  68
  69 Deploying HAMMER
  70
  71 * Home fileserver
  72 * (explain)
  73 * Small datacenter deployment
  74 * (explain)
  75 * Leveraging swapcache
  76 * (explain)
  77
  78 HAMMER recipes, a guide for the impatient. (jcs)
  79
  80 Are you impatient?  Are you sold on Hammer and just want to try it out?  Did you just delete something really, really important and need to get it back?  Here's some simple use cases for Hammer to show just what you can do.
  81
  82 *Simple case: I scrambled a file*
  83
  84 The most simple case: you've scrambled a file. Maybe you rewrote several lines and saved it, or accidentally mashed the keyboard, but either way, the file is still present - just wrong.
  85
  86 By default, the undo tool will output the previous version of a file with a note about the timestamp for that last change, prefixed with >>>.
  87
  88
  89     undo filename
  90
  91     >>> filename 0000 0x00000001c059c3d0 20-Aug-2011 19:24:18
  92
  93     (previous version info here)
  94
  95 Other options exist, like using -i to iterate over all previous versions saved to disk, or way to generate a diff. What if you delete the file? It'll still work.
  96
  97 *Help!  I filled up the disk!*
  98
  99 File history takes up space on disk.  Remember, the amount of history data isn't determined by the quantity of files, but rather how frequently they change.  Those changes are what makes up filesystem history.  It's possible to fill a disk because of that history, yet the df command will still report less than 100% usage.
 100
 101 Each pseudo-file-system (PFS) on a Hammer volume is part of that volume's space.  If a particular PFS is very busy, it can eat up all space on the disk and make every PFS unusable.  You can prune older history entries from each volume using 'hammer prune /PFSname', or if you don't care about losing recent fine-grained history entries, 'hammer prune-everything'.  That command may take a few minutes to complete.
 102
 103 For a long-term fix, you may want to change the amount of history retained in any given PFS with 'hammer viconfig'.  That same config controls what 'hammer prune' will remove.
 104
 105 *How to create a snapshot*
 106
 107 By and large, you don't need to create a snapshot.  Hammer volumes are set up to do so, once a day, by default, and saved for 60 days.  Snapshots happen at the PFS level.
 108
 109 These snapshots can be found in /var/hammer, in directories named after the matching PFS.  So, if you happen to delete an important log file in /usr, chances are good you can find an older version of it in /var/hammer/usr/.  Each snapshot is named by the time at which it is taken, i.e. 'snap-YYYYMMDD-HHMM'.  Treat them as read-only backup volume that you can copy from at any time.
 110
 111 If you do want to create a snapshot at an arbitrary time, 'hammer snap PATH' will take an immediate snapshot of the PFS that contains PATH.