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