HAMMER REDO recovery now in head

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

    Ok, the REDO recovery code is now in head and will be part of the
    2.6 release.  Needless to say this is highly experimental since it
    just went in, so vfs.hammer.fsync_mode is going to default to 0 for
    the release.

    The generation side has been in a while and is quite well tested
    but the recovery code is brand new.  Recovery is complex so there
    are probably bugs.

    The REDO fsync feature can be enabled via the vfs.hammer.fsync_mode
    sysctl:

    Mode 2 will issue the I/O and wait for completion, then issue a disk
    synchronization command (guaranteeing the data is on the media).

    Mode 3 will do the same thing but without the disk synchronization
    command.  Mode 3 is equivalent to what a UFS fsync() does, but
    should be even faster since it also involves no seeking.

    All HAMMER fsync modes are meta-data safe regardless.  Basically the
    way the REDO fsync modes work is that REDO information is written
    immediately to the log and determines when fsync() returns,
    kinda like a write-ahead-log, while the normal meta-data synch
    mechanism (which always involves disk synchronization commands)
    operates as if the fsync() had never occured.  Thus HAMMER's disk
    synchronization is no longer in the critical path.

					-Matt