Scary costume sent separately in case your spam filters reject it.
Reasons to apply:
* will more than double linux filesystem performance (see
http://www.namesys.com/v4/fast_reiser4.html), this was measured for
reading and writing the linux source code tree
* applying will allow vm and vfs changes to be tested and benchmarked on
what will be the fastest linux fs by a factor of two when 2.6.0 ships
* performs all fs operations as an atomic transaction, so that, for
instance, write() and truncate() system calls either happen entirely or
not at all
* creates necessary infrastructure for an atomic fs transaction API (not
yet included in Reiser4).
* scalable by design to arbitrarily large numbers of CPUs (use per node
locks rather than system wide locks)
* eliminates fixed size journal area
* creates a complete plugin based infrastructure. This will allow
folding in such features as constraints and inheritance as easily coded
plugins. It will make it possible to implement new security attributes
as just files with new plugins.
* First installment of an effective competitor to the Microsoft OFS
project. No other Linux FS is even trying to provide an alternative to OFS.
We are quite excited over having combined such dramatic performance
increases with atomic transactions, even better packing of small files,
and a plugin infrastructure. This functionality that has killed
performance in other filesystems. (BeFS for instance was forced to
abandon important parts of its original vision for performance reasons.)
You once told me that you agreed that filesystems should have until 6
weeks after VM/VFS stabilizes. I regret that I have the need to remind
you of that. Reiser4 could not be ready earlier. The changes we need
in the core code are all fairly trivial, exporting functions and the
like, I'll let you read the details yourself. I hope that my fellow
tribesman will look at the wooly mammoth on my shoulders as I come back
from the hunt, forgive me for being late for dinner, think a thought for
the poor hungry MS tribe, and help me make a roasting spit.;-)
We circulated all of the changes we needed in the core something like
two weeks ago, nobody objected, and Andrew Morton actually read through
them and ok'd them. Viro and Hellwig of course didn't read them on the
first posting, and then waited until today to find something to object
to, and complained there wasn't enough time left in today. (Being just
as helpful to our integration as with V3....) We will be happy to fix
things in the manner the discussion leads to as soon as the discussion
resolves, it seems to be still in progress as I write.
Reiser4 is clearly labeled as EXPERIMENTAL with notes that it should
only be used by developers, benchmarkers, and testers for now. It
passes fsx and dbench, it passes mongo.pl for ump, it crashes for
mongo.pl smp. We expect it to be suitable for removal of the
EXPERIMENTAL label before 2.6.0 ships (when it is suitable to remove it
from the rest of the kernel. ;-) )
I'd like to offer you a seminar on Reiser4 if you have time. I am in
the US/bayarea for Halloween and next month. (My kids get to try their
first Halloween today. I hope your kids have fun too.)
I won't send you the other Nikita patches emails as I see you are
already reading them. Please consider Nikita to be authorized as the
official maintainer of Reiser4 for the next month (until my return to
Moscow).
Best,
Hans
attached mail follows:
Hello, Linus,
This message starts set of 8 patches against your current BK tree to
include reiser4.
Changes to the core code are fairly small and trivial: mostly function
exports, plus one patch to share ->journal_info pointer with Ext3.
All patches are available at http://namesys.com/snapshots/2002.10.31/,
they can be applied in any order.
Utilities, including mkfs.reiser4 are available at
http://namesys.com/snapshots/2002.10.31/reiser4progs-0.1.0.tar.gz
Nikita.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.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 : Thu Oct 31 2002 - 22:00:56 EST