lkml.org 
[lkml]   [2002]   [Mar]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] delayed disk block allocation
Andreas Dilger wrote:

>On Mar 04, 2002 00:41 -0500, Jeff Garzik wrote:
>
>>Andreas Dilger wrote:
>>
>>>Actually, there are a whole bunch of performance issues with 1kB block
>>>ext2 filesystems. For very small files, you are probably better off
>>>to have tails in EAs stored with the inode, or with other tails/EAs in
>>>a shared block. We discussed this on ext2-devel a few months ago, and
>>>while the current ext2 EA design is totally unsuitable for that, it
>>>isn't impossible to fix.
>>>
>>IMO the ext2 filesystem design is on it's last legs ;-) I tend to
>>think that a new filesystem efficiently handling these features is far
>>better than dragging ext2 kicking and screaming into the 2002's :)
>>
>
>That's why we have ext3 ;-). Given that reiserfs just barely has an
>fsck that finally works most of the time, and they are about to re-do
>the entire filesystem for reiser-v4 in 6 months, I'd rather stick with
>glueing features onto an ext2 core than rebuilding everything from
>scratch each time.
>
Isn't this that old evolution vs. design argument? ReiserFS is design,
code, tweak for a while, and then start to design again methodology. We
take novel designs and algorithms, and stick with them until they are
stable production code, and then we go back and do more novel
algorithms. Such a methodology is well suited for doing deep rewrites
at 5 year intervals.

No pain, no gain, or so we think. Rewriting the core is hard work.
Some people get success and then coast. Some people get success and
then accelerate. We're keeping the pedal on the metal. We're throwing
every penny we make into rebuilding the foundation of our filesystem.

ReiserFS V3 is pretty stable right now. Fsck is usually the last thing
to stabilize for a filesystem, and we were no exception to that rule.

ReiserFS V3 will last for probably another 3 years (though it will
remain supported for I imagine at least a decade, maybe more), with V4
gradually edging it out of the market as V4 gets more and more stable.
During at least the next year we will keep some staff adding minor
tweaks to V3. For instance, our layout policies will improve over the
next few months, journal relocation is about to move from Linux 2.5 to
2.4, and data write ordering code is being developed by Chris. I don't
know how long fsck maintenance for V3 will continue, but it will be at
least as long as users find bugs in it.

The biggest reason we are writing V4 from scratch is that it is a thing
of beauty. If you don't understand this, words will not explain it.

>
>
>Given that ext3, and htree, and all of the other ext2 'hacks' seem to
>do very well, I think it will continue to improve for some time to come.
>A wise man once said "I'm not dead yet".
>
>Cheers, Andreas
>--
>Andreas Dilger
>http://sourceforge.net/projects/ext2resize/
>http://www-mddsp.enel.ucalgary.ca/People/adilger/
>
>-
>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/
>
>



-
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/

\
 
 \ /
  Last update: 2005-03-22 13:24    [W:1.909 / U:0.360 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site