Please look at http://www.namesys.com/benchmarks/v4marks.html
In brief, V4 is way faster than V3, and the wandering logs are indeed
twice as fast as fixed location logs when performing writes in large
We are able to perform all filesystem operations fully atomically, while
getting dramatic performance improvements. (Other attempts at
introducing transactions into filesystems are said to have failed for
Balancing at flush time works well, not using blobs works well,
allocating at flush time works well. CPU time is good enough to get by,
and it will improve over the next few months as we tweak a lot of little
details, but the IO performance is what matters, and this performance is
quite good enough to use. In all the places where V3 sacrifices
performance to save disk space, V4 saves more disk space and gains
rather than loses performance.
The plugin infrastructure works well, expect lots of plugins over the
next year or two.
Look for a repacker to come out in a few weeks that will make these
numbers especially good for filesystems that have 80% of their files
unmoving for long periods of time (which is to say most systems), and
might otherwise suffer from fragmentation.
These benchmarks mean to me that our performance is now good enough to
ship V4 to users (which means we need persons willing to try to crash it
so that the stability can become good enough to ship to users).
Sometime during the next week or two we will probably send a patch in,
and ask for inclusion. We need to run another round of stress tests
after our latest tweaks, and kill off two bugs that got added just
recently, and then we will ask for testers.
I will be going to Budapest to discuss filesystem semantics with Peter
Foldiak for a week, so V4 may get sent in for inclusion by members of my
team while I am absent. If so, please include it in 2.5/2.6.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to firstname.lastname@example.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Jul 23 2003 - 22:00:50 EST