On 4/21/2010 2:51 PM, Jamie Lokier wrote: > Fwiw, I found sorting directories by inode and reading them in that > order help to reduce seeks, some 10 years ago. I implemented > something like 'find' which works like that, keeping a queue of > directories to read and things to open/stat, ordered by inode number > seen in d_ino before open/stat and st_ino after. However it did not > try to readahead the blocks inside a directory, or sort operations by > block number. It reduced some 'find'-like operations to about a > quarter of the time on cold cache. I still use that program sometimes > before "git status" ;-) Google "treescan" and "lokier" if you're > interested in trying it (though I use 0.7 which isn't published). That helps with open()ing or stat()ing the files since you access the inodes in order, but ureadahead already preloads all of the inode tables so this won't help. >> it is not about readdir(). Plain read() is synchronous too. But >> filesystem can respond to readahead calls and read next block to current >> one, while it won't do this for next direntry. > > I'm surprised it makes much difference, as directories are usually not > very large anyway. That's just it; it doesn't help. That's why I want to readahead() all of the directories at once instead of reading them one block at a time. > But if it does, go on, try FIEMAP and blockdev reading, you know you > want to :-) Why reinvent the wheel when that's readahead()'s job? As a workaround I'm about to try just threading all of the calls to open(). Each one will queue a read and block, but with them all doing so at once should fill the queue with plenty of reads. It is inefficient, but better than one block at a time. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
