No subject

or bragging rights but rather:

- The fs will not fail, embarrass, or cost lost time or money.

- It will need less time install, configure, and maintain than other 
options (in which is included backup/restoral costs).

Needing less effort to muck about with tarballs and rsync offsets a 
(possibly) slower fs. Bigtime.

Not so lost or corrupted or even just wrongly erased data.

    I am down to three major items for the release:  The Recovery, balancing,
    and vacuuming subsystems.  All are interrelated and I am making good
    progress.  Beyond that the spike code needs some major tweaking but
    the only effect of that is poor write performance (probably through
    the alpha release).
30% of the I/O speed of current alternatives is fine with me. 25% or 
less might be problematic.

50% is even OK for the long-term if the backup/restoral/rollback pays 
off. Those things are otherwise not 'free'.

>     Of course, there are many other little issues
    that need to be dealt with before the release as well.

    Post release I'll have a go at implementing backup/mirroring streaming.
    I have a pretty good idea how to implement it -- basically by storing a
    last-transaction-id in cluster headers, super-cluster headers, and
    volume headers, in order to reduce the amount of initial scanning
    required to resynchronize a stream.
					-Matt
					Matthew Dillon 
					<dillon at backplane.com>
That last part sounds like 'journaling' to me.

But - at the end of the day - how much [extra?] on-disk space will be 
needed to insure mount 'as-of' is 'good enough' for some realisitic span 
(a week?, a month?)? 'Forever' may be too much to ask.

How close are we to being able to start predicting that storage-space 
efficiency relative to ${some_other_fs}?

Bill