hammer2 - Major restructuring, part 1/several
authorMatthew Dillon <dillon@apollo.backplane.com>
Sun, 28 Apr 2013 05:38:20 +0000 (22:38 -0700)
committerMatthew Dillon <dillon@apollo.backplane.com>
Sun, 28 Apr 2013 07:37:59 +0000 (00:37 -0700)
commit0dea3156dc9c037aae4fd9fb00c631a401f62e5a
tree3a6454073e797126807fee635a3b2acfc85fe3cc
parenta1b0744772b1d56cb4f043bb4cbd8006b63108ed
hammer2 - Major restructuring, part 1/several

* This breaks a lot of things.  The next few commits will get it all
  working again.

* Significantly rework the data structures.  Instead of embedding the
  RBTREE for a chain's children in the chain, the chain instead points
  to a secondary structure containing the RBTREE.

  Chains can no longer be moved within the in-memory topology.  That is,
  if a file is renamed or a block is resized or a block is moved into or
  out of an indirect block, the in-memory chain representing that block
  is NOT moved.  Instead, the in-memory chain is marked deleted and a
  copy is created at the new location.  Both the old and the new chain
  reference the same secondary structure and thus share the same RBTREE,
  and reference the same media storage.

  In addition, chain->duplink points from the deleted chain to its relocated
  copy and maintains a reference on the target until the deleted chain is
  deallocated.  It is possible for the linked list to span more than one
  element.

  This link will soon be used to retarget inode->chain pointers (which can
  wind up pointing to stale data) and also eventually effect chain->parent
  traversals (real parent becomes chain->parent->[duplink*]).  A rethink
  might be needed down the line.

* This will allow the flush code to run 100% asynchronous from the
  frontend and still be able to flush to a synchronization point no
  matter how complex a set of changes have occured to the filesystem
  concurrent to the flush (but after its synchronization point).

* The change also stabilizes chain->parent, which simplifies quite a bit
  of code.

* Simplify nearly all the hammer2_chain_*() API functions, and other
  functions.

* Add a hammer2_trans (transaction) structure to keep track of modifying
  transactions.  This will be flushed out later and used to detect flush
  synchronization points.  It currently contains the transaction id.

* Start adding API infrastructure and start reworking the flush and other
  tree-modifying code to work under the new abstraction.
sys/vfs/hammer2/hammer2.h
sys/vfs/hammer2/hammer2_ccms.c
sys/vfs/hammer2/hammer2_chain.c
sys/vfs/hammer2/hammer2_flush.c
sys/vfs/hammer2/hammer2_freemap.c
sys/vfs/hammer2/hammer2_inode.c
sys/vfs/hammer2/hammer2_ioctl.c
sys/vfs/hammer2/hammer2_msgops.c
sys/vfs/hammer2/hammer2_subr.c
sys/vfs/hammer2/hammer2_vfsops.c
sys/vfs/hammer2/hammer2_vnops.c