LWN.net Logo

Reiser4, will double Linux FS performance, please apply

From:  Hans Reiser <reiser@namesys.com>
To:  Linus Torvalds <torvalds@transmeta.com>
Subject:  [BK][PATCH] Reiser4, will double Linux FS performance, please apply
Date:  Fri, 01 Nov 2002 00:23:45 +0300
Cc:  Linux Kernel <linux-kernel@vger.kernel.org>, Reiserfs-List@namesys.com

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



Copyright © 2002, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds