git: HAMMER VFS - Implement REDO recovery code

[Matthew Dillon]

commit c58123da115775ad9efb096a539933097879d078
Author: Matthew Dillon <dillon at apollo.backplane.com>
Date:   Thu Mar 25 22:42:47 2010 -0700

    HAMMER VFS - Implement REDO recovery code
    
    * Implement the primary REDO recovery mechanics and document the whole mess.
      REDO recovery essentially works using an expanded UNDO/REDO FIFO range.
    
      The nominal UNDO range, required for running UNDOs, is calculated first.
      If a REDO_SYNC record is found within this range the record specifies
      the expanded FIFO start offset required to run REDOs.  This is necessary
      because the inodes related to REDOs layed down in the FIFO are not
      necessarily flush in the next flush sequence, so the recovery code may
      have to scan the UNDO/REDO FIFO backwards considerably beyond the nominal
      recovery ranged required to run UNDOs in order to find active REDOs.
    
      When a REDO_SYNC record is found the recovery code expands the range
      by scanning backwards and validating the UNDO/REDO FIFO as it goes.
      It must make sure that the sequence space remains contiguous all the
      back to the REDO_SYNC point.
    
      While doing the reverse scan the recovery code collects REDO_TERM_*
      records which are used to mask earlier REDO_* records once their
      meta-data has been flushed.  Only TERM records in the expanded range
      that are outside the nominal UNDO range matter.  Any TERM records in
      the nominal UNDO range refer to meta-data which was undone by the
      stage1 UNDO recovery and so must be ignored (we want to run the
      related REDOs).
    
      The recovery code then does a forward scan through the entire expanded
      range of the UNDO/REDO FIFO executing any REDO_* records it finds
      which have not been masked by later REDO_TERM_* records.  It executes
      the REDOs using the live filesystem.
    
    * Expand the REDO FIFO structure, I had forgotten to add a localization
      field, otherwise HAMMER doesn't know which PFS the REDO is refering to.
    
    * Umount was improperly flushing the FIFO to the disk for read-only mounts.
      Fix it.
    
    * The recovery code now detects whether any REDOs are present by the
      observation of a REDO_SYNC record in the nominal UNDO recovery range.
      It will not run stage2 (the REDO pass) if it does not see this record.
    
    * Properly generate a REDO_SYNC record in the UNDO space when generating
      only REDOs, as well as UNDOs.  HAMMER was previously only generating
      the REDO_SYNC record when generating UNDOs.
    
    * Generate a REDO_TRUNC record during a file flush if any records were
      previously queued with REDO, even if those records no longer exist
      (e.g. due to a truncation) and even if REDO is now turned off due to
      redo heuristic limits being exceeded.
    
      This is necessary in order for the recovery code to properly sequence
      REDOs and TRUNCations during recovery.
    
    * For now be very verbose during redo recovery.
    
    * Make sure that mount -o ro and mount -u -o rw work properly.  The
      stage2 REDO cannot be run on a read-only mount because it requires a
      live filesystem.  The operations are defered until the mount is
      upgraded to rw.

Summary of changes:
 sys/vfs/hammer/hammer.h         |    4 +
 sys/vfs/hammer/hammer_disk.h    |    2 +
 sys/vfs/hammer/hammer_flusher.c |    2 +
 sys/vfs/hammer/hammer_mount.h   |    2 -
 sys/vfs/hammer/hammer_recover.c |  563 +++++++++++++++++++++++++++++++++++++--
 sys/vfs/hammer/hammer_redo.c    |   34 ++-
 sys/vfs/hammer/hammer_vnops.c   |   15 +-
 7 files changed, 586 insertions(+), 36 deletions(-)

http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/c58123da115775ad9efb096a539933097879d078


-- 
DragonFly BSD source repository