From: Andreas Dilger <adilger@clusterfs.com>
To: Jeff Garzik <jgarzik@mandrakesoft.com>
Cc: Daniel Phillips <phillips@bonn-fries.net>,
Andrew Morton <akpm@zip.com.au>,
lkml <linux-kernel@vger.kernel.org>
Subject: Re: [patch] delayed disk block allocation
Date: Sun, 3 Mar 2002 23:18:51 -0700 [thread overview]
Message-ID: <20020303231851.N4188@lynx.adilger.int> (raw)
In-Reply-To: <3C7F3B4A.41DB7754@zip.com.au> <E16hhuI-0000S6-00@starship.berlin> <20020304050450.GF353@matchmail.com> <20020303223103.J4188@lynx.adilger.int> <3C8308FE.FC4FA42@mandrakesoft.com>
In-Reply-To: <3C8308FE.FC4FA42@mandrakesoft.com>; from jgarzik@mandrakesoft.com on Mon, Mar 04, 2002 at 12:41:18AM -0500
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.
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/
next prev parent reply other threads:[~2002-03-04 6:23 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-03-01 8:26 Andrew Morton
2002-03-04 2:08 ` Daniel Phillips
2002-03-04 3:10 ` Jeff Garzik
2002-03-04 7:27 ` Andrew Morton
2002-03-04 5:04 ` Mike Fedyk
2002-03-04 5:31 ` Andreas Dilger
2002-03-04 5:40 ` Mike Fedyk
2002-03-04 6:14 ` Andreas Dilger
2002-03-04 5:41 ` Jeff Garzik
2002-03-04 6:18 ` Andreas Dilger [this message]
2002-03-04 15:02 ` Hans Reiser
2002-03-06 12:59 ` Pavel Machek
2002-03-04 7:53 ` Andrew Morton
2002-03-04 8:06 ` Daniel Phillips
2002-03-04 8:34 ` Andrew Morton
2002-03-04 7:20 ` Andrew Morton
2002-03-04 9:23 ` Daniel Phillips
2002-03-04 14:54 rwhron
2002-03-04 15:10 ` Jeff Garzik
2002-03-07 12:06 Etienne Lorrain
2002-03-07 14:47 ` Steve Lord
2002-03-07 17:30 ` Mike Fedyk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020303231851.N4188@lynx.adilger.int \
--to=adilger@clusterfs.com \
--cc=akpm@zip.com.au \
--cc=jgarzik@mandrakesoft.com \
--cc=linux-kernel@vger.kernel.org \
--cc=phillips@bonn-fries.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®