Re: Fastest way to "find / -mtime +7".....

["Ragnar Kjørstad" <reiserfs@ragnark.vestdata.no>]

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.



I once wrote a new hash for reiserfs3 specifically for maildir. This
hash caused files to be order in approximate creating order, matching
the inode order much closer. 


You will find both the patch and some benchmark results if you search
the archive (messageid 20010628030201.E380@vestdata.no), but speeded up
my testcase by a factor of 6. (My testcase read all the data too though.
I don't think I ever tested just "find . -ls")


In reiserfs3 the usefullness of the hash is limited as hashes are per
filesystem settings. (So it is only useful if you have a dedicated
maildir filesystem). I've lost track of reiserfs4 features - maybe you
can select hashes per directory now? Or maybe the whole thing is made
obsolete by putting the inodes with the directoryentries?




-- 
Ragnar Kjørstad
Software Engineer
Scali - http://www.scali.com
Scaling the Linux Datacenter