Last night I committed roll-forward code to the trunk; you can enable it
by compiling the kernel with LFS_DO_ROLLFORWARD.  In my tests over the
weekend this seemed to work; ymmv.

In order for this to work you will have to use a filesystem created with a
very recent newfs_lfs (rev 1.21 of lfs.c).  The older newfs_lfs did not
match the ifile version number and inode generation number on / and
/lost+found which will make the roll-forward code do the wrong thing if it
tries to update these directories.  (Now that I'm writing this I realize
the fix is pretty simple but ... it's not in there yet.)

In addition there is at least one problem outstanding with this code, and
that concerns the non-monotonic nature of time.  The roll-forward code
uses the timestamp on the partial-segments to determine when it has
encountered the end of the log.  If the clock is jumped backward, some
data written, and then a crash occurs, you may end up rolling forward more
than you should and get unexpected results.

The fix for this is also simple but it will require enlarging the on-disk
data structures so it will have to be postponed to "version 2" along with
the other changes that need on-disk structure changes.

						Konrad Schroder
						perseant@hhhh.org