All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Briggs <jbriggs@esoft.com>
To: "Ragnar Kjørstad" <reiserfs@ragnark.vestdata.no>
Cc: Ed Walker <ewalker@surfcity.net>, reiserfs-list@namesys.com
Subject: Re: Fastest way to "find / -mtime +7".....
Date: Tue, 19 Jul 2005 16:00:23 -0600	[thread overview]
Message-ID: <1121810424.15596.19.camel@localhost> (raw)
In-Reply-To: <20050719200902.GM1508@vestdata.no>

[-- Attachment #1: Type: text/plain, Size: 1296 bytes --]

On Tue, 2005-07-19 at 22:09 +0200, Ragnar Kjørstad wrote:
> On Tue, Jul 19, 2005 at 12:48:53PM -0600, Jonathan Briggs wrote:
> > > this is pretty slow on reiser, at least compared with ext2/3, and I  
> > > understand that it may be because the find command returns the names  
> > > in a non-optimal order (ie readdir order?).
> > 
> > I think Reiser3 is slow more because with mtime, find has to stat each
> > file. 
> 
> The two issues are related.
> 
> Readdir will return the filenames in hash order. Find will then go and
> stat each file, still in hash order.
> 
> Problem is, the inodes are not sorted in directory hash order on the
> disk. They tend to be in approximate creation order. So, the disk access
> pattern is nearly random access, meaning every stat is likely to touch a
> new block and readahead is completely useless.
[snip]
How about some kind of stat-data readahead logic?  If the first two or
three directory entries are stat'd, queue up the rest (or next
hundred/thousand) of them.  If the disk queue is given the whole pile of
stat requests at once instead of one at a time, it should be able to
sort them into a reasonable order.

This might even be a VFS thing to do instead of per-FS.
-- 
Jonathan Briggs <jbriggs@esoft.com>
eSoft, Inc.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2005-07-19 22:00 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-19 17:55 Fastest way to "find / -mtime +7" Ed Walker
2005-07-19 18:48 ` Jonathan Briggs
2005-07-19 20:09   ` Ragnar Kjørstad
2005-07-19 22:00     ` Jonathan Briggs [this message]
2005-07-20 12:33       ` Alexander G. M. Smith
2005-07-20 16:26       ` Andreas Dilger
2005-07-20 20:44         ` Ragnar Kjørstad

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=1121810424.15596.19.camel@localhost \
    --to=jbriggs@esoft.com \
    --cc=ewalker@surfcity.net \
    --cc=reiserfs-list@namesys.com \
    --cc=reiserfs@ragnark.vestdata.no \
    /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.