From: Phillip Susi <psusi@cfl.rr.com>
To: Ted Ts'o <tytso@mit.edu>
Cc: Eric Sandeen <sandeen@redhat.com>,
"linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>
Subject: Re: Large directories and poor order correlation
Date: Mon, 14 Mar 2011 19:43:57 -0400 [thread overview]
Message-ID: <4D7EA83D.20400@cfl.rr.com> (raw)
In-Reply-To: <20110314215249.GE8120@thunk.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 03/14/2011 05:52 PM, Ted Ts'o wrote:
> Unfortunately the kernel can't do it, because a directory could be
> arbitrarily big, and kernel memory is non-swappable. In addition,
Buffers/cache is discardable though. Or does the entire htree have to
be kept in slab or something?
> what if a process opens a directory, starts calling readdir, pauses in
> the middle, and then holds onto it for days, weeks, or months?
The same thing that happened before htree?
> It's not hard to provide library routines that do the right thing, and
> I have written an LD_PRELOAD which intercepts opendir() and readdir()
> calls and does the sorting in userspace. Perhaps the right answer is
> getting this into libc, but I have exactly two words for you: "Uhlrich
> Drepper".
Wouldn't it be better to just have readdir() use the main directory,
which presumably is in a more sane ordering, instead of the htree? That
way you don't have to burn cpu and ram sorting on every opendir().
Also, I have checked some smaller directories and lsattr reports they
are NOT using indexing, yet still display poor correlation.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk1+qDkACgkQJ4UciIs+XuIktwCgi1u4T2x+igOw4feO0hNjzB9W
liIAmwRBdPiZMSfWpzu4+40xJsNXzouQ
=d4VX
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2011-03-14 23:43 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-14 20:24 Large directories and poor order correlation Phillip Susi
2011-03-14 20:37 ` Eric Sandeen
2011-03-14 20:52 ` Phillip Susi
2011-03-14 21:12 ` Eric Sandeen
2011-03-14 21:52 ` Ted Ts'o
2011-03-14 23:43 ` Phillip Susi [this message]
2011-03-15 0:14 ` Ted Ts'o
2011-03-15 14:01 ` Phillip Susi
2011-03-15 14:33 ` Rogier Wolff
2011-03-15 14:36 ` Ric Wheeler
2011-03-15 17:08 ` Ted Ts'o
2011-03-15 19:08 ` Phillip Susi
2011-03-16 1:50 ` Ted Ts'o
2011-03-15 7:59 ` Florian Weimer
2011-03-15 11:06 ` Theodore Tso
2011-03-15 11:23 ` Ric Wheeler
2011-03-15 11:38 ` Theodore Tso
2011-03-15 13:33 ` Rogier Wolff
2011-03-15 17:18 ` Ted Ts'o
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=4D7EA83D.20400@cfl.rr.com \
--to=psusi@cfl.rr.com \
--cc=linux-ext4@vger.kernel.org \
--cc=sandeen@redhat.com \
--cc=tytso@mit.edu \
/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.