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.