HAMMER REDO log - update 11-Jan-2010

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

    The REDO work is about half done.  The entire forward logging path
    is implemented and HAMMER will generate and sync REDO records.
    However, the recovery code does not yet parse the REDO records.
    The recovery side of the work is still ongoing.

    Some basic testing is possible but note that any crash recovery will
    not actually run the REDOs yet.  The filesystem meta-data should still
    be recovered properly, it just won't rerun the write()'s that were
    fsync()'d via the new REDO modes.

    Requirements for testing:

    * HAMMER filesystem must be version 4 or upgraded to version 4.

    * vfs.hammer.fsync_mode must be set to 2 or 3 (it defaults to 0).

	0	original non-REDO fsync mode.  Full meta-data flush
		to disk with a synchronous media flush command.

	1	original non-REDO fsync mode.  Full meta-data flush
		to disk with media flush command, but done asynchronously.

	2	fast-fsync mode REDO's generated and synced to disk,
		with a synchronous media flush.

	3	super-fast-fsync mode REDO's generated and synced to disk,
		with no media flush.

	4	fsync completely disabled

	Please only use filesystems you are willing to lose for now.
	I don't THINK I've made any mistakes but...

    * vfs.hammer.limit_redo defaults to 4194304 (4MB).  This specifies
      how much data can be written between fsync()s before HAMMER gives
      up trying to use the fast REDO mode.  You probably do not need
      to change this default.

    Since the recovery code hasn't been implemented yet the type of testing
    which can be done atm is, say, benchmark testing (like mysql benchmarks
    and such).

						-Matt