Asynchronous is available: Use clone or pthreads.
More broadly: One of the ways to better I/O sorting is to make sure
you've got enough things in parallel that the I/O queue is never
empty, so what you issue has time to get sorted before it reaches the
head of the queue for dispatch. On the other hand, not so many things
in parallel that the queues fill up and throttle. Unfortunately it
only works if things aren't serialised by kernel locks - but there's been
a lot of work on lockless this and that in the kernel, which may help.
Back to your problem: You need a bunch of scattered block requests to
be queued and sorted sanely, and readdir doesn't do that, and even
waits for each block before issuing the next request.
Or does it?
A quick skim of fs/{ext3,ext4}/dir.c finds a call to
page_cache_sync_readahead. Doesn't that do any reading ahead? :-)
I/O is the probably the biggest cost, so it's more important to get
the I/O pattern you want than worrying about return values you'll discard.
If readdir() calls are slowed by lots of calls and libc, consider
using the getdirentries system call directly.
If not, fs/ext4/namei.c:ext4_dir_inode_operations points to
ext4_fiemap. So you may have luck calling FIEMAP or FIBMAP on the
directory, and then reading blocks using the block device. I'm not
sure if the cache loaded via the block device (when mounted) will then
be used for directory lookups.
-- Jamie
--
