DragonFly commits List (threaded) for 2008-04
DragonFly BSD
DragonFly commits List (threaded) for 2008-04
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

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

From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Thu, 24 Apr 2008 14:20:34 -0700 (PDT)

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 
  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
  * 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


[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]