From: Daniel Phillips <phillips@bonn-fries.net>
To: Ville Herva <vherva@niksula.hut.fi>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Ext2 directory index, updated
Date: Mon, 5 Nov 2001 10:53:55 +0100 [thread overview]
Message-ID: <20011105095243Z16495-18972+84@humbolt.nl.linux.org> (raw)
In-Reply-To: <20011104022659Z16995-4784+750@humbolt.nl.linux.org> <20011105014225Z17055-18972+38@humbolt.nl.linux.org> <20011105094816.E26218@niksula.cs.hut.fi>
In-Reply-To: <20011105094816.E26218@niksula.cs.hut.fi>
On November 5, 2001 08:48 am, Ville Herva wrote:
> On Mon, Nov 05, 2001 at 02:43:28AM +0100, you [Daniel Phillips] claimed:
> >
> > Which kernel are you using? From 2.4.10 on ext2 has an accelerator in
> > ext2_find_entry - it caches the last lookup position. I'm wondering how that
> > affects this case.
>
> Is that the same optimization Ted T'so implemented for ext3 around 0.9.10? I
> thought it hadn't been ported the ext2...
Yes, Ted did it, earlier this year.
> BTW, I assume the ext2 dir index patch is roughly equivalent to FreeBSD
> dirhash and the the other patch resembles theFreeBSD dirperf patch?
> Have you looked at them? [http://www.osnews.com/story.php?news_id=153]
I *think* the performance of my dir index patch is roughly in line with BSD's
dirhash patch, for common cases. The big difference is that the BSD dirhash
is not persistent - the cache goes away when the directory is closed. So
there are loads that can break it badly, such as accessing files in large
directories randomly over a large disk. This forces the entire directory to
be read into cache, in the worst case, on every access. Another bad case is
first-time access. A million file directory is around 30 meg - it takes a
long time to read and hash all those blocks, just to open the first file.
They will have to implement a persistent index at some point. For common
cases though, the BSD approach is good.
I'll go into the gory details next week at ALS if people are insterested.
--
Daniel
next prev parent reply other threads:[~2001-11-05 9:53 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-11-04 2:28 Ext2 directory index, updated Daniel Phillips
2001-11-04 2:44 ` Daniel Phillips
2001-11-04 22:09 ` Christian Laursen
2001-11-04 22:24 ` Daniel Phillips
2001-11-04 22:54 ` Christian Laursen
2001-11-04 23:01 ` Daniel Phillips
2001-11-04 23:09 ` Gábor Lénárt
2001-11-05 22:10 ` Andreas Dilger
2001-11-06 0:38 ` Daniel Phillips
2001-11-05 1:43 ` Daniel Phillips
2001-11-05 7:48 ` Ville Herva
2001-11-05 9:53 ` Daniel Phillips [this message]
2001-11-05 22:59 ` Christian Laursen
2001-11-05 23:13 ` Daniel Phillips
2001-11-05 23:45 ` Andreas Dilger
2001-11-08 7:21 ` Christian Laursen
-- strict thread matches above, loose matches on Subject: below --
2002-03-04 11:03 Ext2 Directory Index, updated Daniel Phillips
2001-11-02 3:36 Ext2 directory index, updated Daniel Phillips
2001-11-02 5:04 ` Andreas Dilger
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=20011105095243Z16495-18972+84@humbolt.nl.linux.org \
--to=phillips@bonn-fries.net \
--cc=linux-kernel@vger.kernel.org \
--cc=vherva@niksula.hut.fi \
/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;
as well as URLs for NNTP newsgroup(s).