From: Andi Kleen <andi@firstfloor.org>
To: Josef Bacik <josef@redhat.com>
Cc: linux-btrfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
viro@ZenIV.linux.org.uk, hch@lst.de, aarcange@redhat.com
Subject: Re: [PATCH 1/2] fs: add a DCACHE_NEED_LOOKUP flag for d_flags
Date: Fri, 20 May 2011 13:07:00 -0700 [thread overview]
Message-ID: <m2hb8pyw4b.fsf@firstfloor.org> (raw)
In-Reply-To: <1305827929-18491-1-git-send-email-josef@redhat.com> (Josef Bacik's message of "Thu, 19 May 2011 13:58:48 -0400")
Josef Bacik <josef@redhat.com> writes:
> Btrfs (and I'd venture most other fs's) stores its indexes in nice disk order
> for readdir, but unfortunately in the case of anything that stats the files in
> order that readdir spits back (like oh say ls) that means we still have to do
> the normal lookup of the file, which means looking up our other index and then
> looking up the inode. What I want is a way to create dummy dentries when we
> find them in readdir so that when ls or anything else subsequently does a
> stat(), we already have the location information in the dentry and can go
Funny I remember discussing this optimization a long time ago with
Andrea. But the problem is still that it has the potential to pollute
the dcache a lot when someone is reading a large directory.
Consider the find / case. You don't want that to turn over all
of your dcache.
So if you do that you need some way to put the dummy dentries on a
special LRU list that gets cleaned quickly and is kept small.
-Andi
--
ak@linux.intel.com -- Speaking for myself only
next prev parent reply other threads:[~2011-05-20 20:07 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-19 17:58 [PATCH 1/2] fs: add a DCACHE_NEED_LOOKUP flag for d_flags Josef Bacik
2011-05-19 17:58 ` [PATCH 2/2] Btrfs: load the key from the dir item in readdir into a fake dentry Josef Bacik
2011-05-19 19:03 ` [PATCH 1/2] fs: add a DCACHE_NEED_LOOKUP flag for d_flags Andreas Dilger
2011-05-19 19:43 ` Josef Bacik
2011-05-20 20:07 ` Andi Kleen [this message]
2011-05-20 20:51 ` Andreas Dilger
2011-05-20 21:31 ` Andi Kleen
2011-05-21 0:30 ` Josef Bacik
2011-05-21 3:00 ` Andi Kleen
2011-05-21 4:11 ` Dave Chinner
[not found] <adilger@dilger.ca, hch@lst.de>
2011-05-26 14:48 ` Josef Bacik
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=m2hb8pyw4b.fsf@firstfloor.org \
--to=andi@firstfloor.org \
--cc=aarcange@redhat.com \
--cc=hch@lst.de \
--cc=josef@redhat.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=viro@ZenIV.linux.org.uk \
/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.