git: hammer2 - Major restructuring, part 1/several

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxxxxx>]

commit 0dea3156dc9c037aae4fd9fb00c631a401f62e5a
Author: Matthew Dillon <dillon@apollo.backplane.com>
Date:   Sat Apr 27 22:38:20 2013 -0700

    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.

Summary of changes:
 sys/vfs/hammer2/hammer2.h         |  245 ++++---
 sys/vfs/hammer2/hammer2_ccms.c    |    2 +-
 sys/vfs/hammer2/hammer2_chain.c   | 1329 +++++++++++++++++++++----------------
 sys/vfs/hammer2/hammer2_flush.c   |  946 ++++++++++++++------------
 sys/vfs/hammer2/hammer2_freemap.c |    5 +-
 sys/vfs/hammer2/hammer2_inode.c   |  510 +++++++-------
 sys/vfs/hammer2/hammer2_ioctl.c   |   87 ++-
 sys/vfs/hammer2/hammer2_msgops.c  |    2 +-
 sys/vfs/hammer2/hammer2_subr.c    |   51 +-
 sys/vfs/hammer2/hammer2_vfsops.c  |  126 ++--
 sys/vfs/hammer2/hammer2_vnops.c   |  496 +++++++-------
 11 files changed, 2097 insertions(+), 1702 deletions(-)

http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/0dea3156dc9c037aae4fd9fb00c631a401f62e5a


-- 
DragonFly BSD source repository