cvs commit: src/sys/vfs/hammer hammer.h hammer_btree.c hammer_cursor.c hammer_cursor.h hammer_flusher.c hammer_inode.c hammer_io.c hammer_ioctl.c hammer_object.c hammer_ondisk.c hammer_subs.c hammer_transaction.c hammer_vfsops.c hammer_vnops.c

[Matthew Dillon]

dillon      2008/04/24 14:20:34 PDT

DragonFly src repository

  Modified files:
    sys/vfs/hammer       hammer.h hammer_btree.c hammer_cursor.c 
                         hammer_cursor.h hammer_flusher.c 
                         hammer_inode.c hammer_io.c hammer_ioctl.c 
                         hammer_object.c hammer_ondisk.c 
                         hammer_subs.c hammer_transaction.c 
                         hammer_vfsops.c hammer_vnops.c 
  Log:
  HAMMER 38A/Many: Undo/Synchronization and crash recovery
  
  * Separate all frontend operations from all backend media synchronization.
    The frontend VNOPs make all changes in-memory and in the frontend
    buffer cache.  The backend buffer cache used to manage meta-data is
    not touched.
  
    - In-memory inode contains two copies of critical meta-data structures
    - In-memory record tree distinguishes between records undergoing
      synchronization and records not undergoing synchronization.
    - Frontend buffer cache buffers are tracked to determine which ones
      to synchronize and which ones not to.
    - Deletions are cached in-memory.  Any number of file truncations
      simply caches the lowest truncation offset and on-media records
      beyond that point are ignored.  Record deletions are cached as
      a negative entry in the in-memory record tree until the backend
      can execute the operation on the media.
    - Frontend operations continue to have full, direct read access to
      the media.
  
  * Backend synchronization to the disk media is able to take place
    simultaniously with frontend operations on the same inodes.  This
    will need some tuning but it basically works.
  
  * In-memory records are no longer removed from the B-Tree when deleted.
    They are marked for deletion and removed when the last reference goes
    away.
  
  * An Inode whos last reference is being released is handed over to the
    backend flusher for its final disposition.
  
  * There are some bad hacks and debugging tests in this commit.  In particular
    when the backend needs to do a truncation it special-cases any
    negative entries it finds in the in-memory record tree.  Also, if a
    rename operation hits a deadlock it currently breaks atomicy.
  
  * The transaction API has been simplified.  The frontend no longer allocates
    transaction ids.  Instead the backend does a full flush with a single
    transaction id (since that is the granularity the crash recovery code will
    have anyway).
  
  Revision  Changes    Path
  1.48      +62 -28    src/sys/vfs/hammer/hammer.h
  1.36      +1 -1      src/sys/vfs/hammer/hammer_btree.c
  1.22      +6 -1      src/sys/vfs/hammer/hammer_cursor.c
  1.15      +3 -3      src/sys/vfs/hammer/hammer_cursor.h
  1.2       +2 -7      src/sys/vfs/hammer/hammer_flusher.c
  1.35      +425 -131  src/sys/vfs/hammer/hammer_inode.c
  1.25      +1 -1      src/sys/vfs/hammer/hammer_io.c
  1.8       +1 -1      src/sys/vfs/hammer/hammer_ioctl.c
  1.41      +215 -89   src/sys/vfs/hammer/hammer_object.c
  1.37      +1 -1      src/sys/vfs/hammer/hammer_ondisk.c
  1.16      +1 -1      src/sys/vfs/hammer/hammer_subs.c
  1.12      +31 -15    src/sys/vfs/hammer/hammer_transaction.c
  1.26      +18 -3     src/sys/vfs/hammer/hammer_vfsops.c
  1.38      +208 -118  src/sys/vfs/hammer/hammer_vnops.c


http://www.dragonflybsd.org/cvsweb/src/sys/vfs/hammer/hammer.h.diff?r1=1.47&r2=1.48&f=u
http://www.dragonflybsd.org/cvsweb/src/sys/vfs/hammer/hammer_btree.c.diff?r1=1.35&r2=1.36&f=u
http://www.dragonflybsd.org/cvsweb/src/sys/vfs/hammer/hammer_cursor.c.diff?r1=1.21&r2=1.22&f=u
http://www.dragonflybsd.org/cvsweb/src/sys/vfs/hammer/hammer_cursor.h.diff?r1=1.14&r2=1.15&f=u
http://www.dragonflybsd.org/cvsweb/src/sys/vfs/hammer/hammer_flusher.c.diff?r1=1.1&r2=1.2&f=u
http://www.dragonflybsd.org/cvsweb/src/sys/vfs/hammer/hammer_inode.c.diff?r1=1.34&r2=1.35&f=u
http://www.dragonflybsd.org/cvsweb/src/sys/vfs/hammer/hammer_io.c.diff?r1=1.24&r2=1.25&f=u
http://www.dragonflybsd.org/cvsweb/src/sys/vfs/hammer/hammer_ioctl.c.diff?r1=1.7&r2=1.8&f=u
http://www.dragonflybsd.org/cvsweb/src/sys/vfs/hammer/hammer_object.c.diff?r1=1.40&r2=1.41&f=u
http://www.dragonflybsd.org/cvsweb/src/sys/vfs/hammer/hammer_ondisk.c.diff?r1=1.36&r2=1.37&f=u
http://www.dragonflybsd.org/cvsweb/src/sys/vfs/hammer/hammer_subs.c.diff?r1=1.15&r2=1.16&f=u
http://www.dragonflybsd.org/cvsweb/src/sys/vfs/hammer/hammer_transaction.c.diff?r1=1.11&r2=1.12&f=u
http://www.dragonflybsd.org/cvsweb/src/sys/vfs/hammer/hammer_vfsops.c.diff?r1=1.25&r2=1.26&f=u
http://www.dragonflybsd.org/cvsweb/src/sys/vfs/hammer/hammer_vnops.c.diff?r1=1.37&r2=1.38&f=u