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
