linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Theodore Tso <tytso@mit.edu>
To: Florian Weimer <fw@deneb.enyo.de>
Cc: Zhang Huan <zhhuan@gmail.com>, linux-ext4@vger.kernel.org
Subject: Re: Question on readdir implementation
Date: Tue, 15 Sep 2009 14:38:49 -0400	[thread overview]
Message-ID: <20090915183849.GB15101@mit.edu> (raw)
In-Reply-To: <87ocpcf5wv.fsf@mid.deneb.enyo.de>

On Tue, Sep 15, 2009 at 05:56:32PM +0000, Florian Weimer wrote:
> * Theodore Tso:
> 
> > So this is something we could do in the future.  In practice, no one
> > has complained about this as far as NFS is concerned, so it's not high
> > priority for me to pursue.  Were you worried about this as a practical
> > matter, or as a theoretical one?
> 
> readdir returning entries in essentially randomized order is a
> practical performance problem for many things, from grep -r to tar. 8-(
> (My recent FIBMAP/FIEMAP question was related to that, too.)

Well, it's not _that_ hard for applications to sort the directory
entries by inode number.  I've written a LD_PRELOAD, called
spd_readdir() for people who want to use it.  The mutt application
does this natively, and it makes the problem go away.

We could do this in the kernel, but for very large directories, you
will end up pinning large amounts of memory --- and if an application
holds a directory fd open for a long time, the memory needs to be kept
pinned until the dfd is closed.  Still, for moderate sized
directories, it's a possibility.

						- Ted

  reply	other threads:[~2009-09-15 18:38 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-15  9:57 Question on readdir implementation Zhang Huan
2009-09-15 14:41 ` Andreas Dilger
2009-09-15 14:53 ` Theodore Tso
2009-09-15 17:56   ` Florian Weimer
2009-09-15 18:38     ` Theodore Tso [this message]
2009-09-16  5:47   ` Zhang Huan

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=20090915183849.GB15101@mit.edu \
    --to=tytso@mit.edu \
    --cc=fw@deneb.enyo.de \
    --cc=linux-ext4@vger.kernel.org \
    --cc=zhhuan@gmail.com \
    /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).