From: Jamie Lokier <jamie@shareable.org>
To: Evgeniy Polyakov <zbr@ioremap.net>
Cc: Phillip Susi <psusi@cfl.rr.com>,
linux-fsdevel@vger.kernel.org,
Linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: readahead on directories
Date: Wed, 21 Apr 2010 21:39:37 +0100 [thread overview]
Message-ID: <20100421203937.GX27575@shareable.org> (raw)
In-Reply-To: <20100421202134.GB25130@ioremap.net>
Evgeniy Polyakov wrote:
> On Wed, Apr 21, 2010 at 09:02:43PM +0100, Jamie Lokier (jamie@shareable.org) wrote:
> > FIEMAP might not be the answer, but what part of it requires fs
> > knowledge? It's supposed to be fs-independent. I agree it's not
> > always appropriate to use, and I don't know if it would be effective
> > anyway.
>
> At least we have to know whether given fs supports such interface.
> And more complex is to know how underlying fs is organized. What is
> extent, which types can it have, where exactly information about extent
> metadata is stored, i.e. where can we find what this object is about?
Ummm... Does any of that matter?
> And how to actually populate appropriate blocks into ram to speedup
> readdir()?
Blockdev readahead() :-)
> FIEMAP (which is file mapper btw :) is useful for information gathering
> about how fs is organized, but that's all I'm afraid.
That's all you need to start fetching from the blockdev. You can't
*use* the blockdev data, but that doesn't matter for this readahead
operation, only that they are approximately the right data blocks.
- Jamie
next prev parent reply other threads:[~2010-04-21 20:39 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-19 15:51 readahead on directories Phillip Susi
2010-04-21 0:44 ` Jamie Lokier
2010-04-21 14:57 ` Phillip Susi
2010-04-21 16:12 ` Jamie Lokier
2010-04-21 18:10 ` Phillip Susi
2010-04-21 20:22 ` Jamie Lokier
2010-04-21 20:59 ` Phillip Susi
2010-04-21 22:06 ` Jamie Lokier
2010-04-22 7:01 ` Brad Boyer
2010-04-22 14:26 ` Phillip Susi
2010-04-22 17:53 ` Jamie Lokier
2010-04-22 19:23 ` Phillip Susi
2010-04-22 20:35 ` Jamie Lokier
2010-04-22 21:22 ` Phillip Susi
2010-04-22 22:43 ` Jamie Lokier
2010-04-23 4:13 ` Phillip Susi
2010-04-21 18:38 ` Evgeniy Polyakov
2010-04-21 18:51 ` Jamie Lokier
2010-04-21 18:56 ` Evgeniy Polyakov
2010-04-21 20:02 ` Jamie Lokier
2010-04-21 20:21 ` Evgeniy Polyakov
2010-04-21 20:39 ` Jamie Lokier [this message]
2010-04-21 19:23 ` Phillip Susi
2010-04-21 20:01 ` Jamie Lokier
2010-04-21 20:13 ` Phillip Susi
2010-04-21 20:37 ` Jamie Lokier
2010-05-07 13:38 ` unified page and buffer cache? (was: readahead on directories) Phillip Susi
2010-05-07 13:53 ` Matthew Wilcox
2010-05-07 15:45 ` unified page and buffer cache? Phillip Susi
2010-05-07 18:30 ` Matthew Wilcox
2010-05-08 0:50 ` Phillip Susi
2010-05-08 0:46 ` tytso
2010-05-08 0:54 ` Phillip Susi
2010-05-08 12:52 ` tytso
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=20100421203937.GX27575@shareable.org \
--to=jamie@shareable.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=psusi@cfl.rr.com \
--cc=zbr@ioremap.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.