On Fri, Apr 08, 2005 at 12:39:26PM -0700, Linus Torvalds wrote: > One of the reasons I do inode numbers in the "index" file (apart from > checking that the inode hasn't changed) is in fact that "stat()" is damn > slow if it causes seeks. Since your stat loop is entirely > > You can optimize your stat() patterns on traditional unix-like filesystems > by just sorting the stats by inode number (since the inode number is > historically a special index into the inode table - even when filesystems > distribute the inodes over several tables, sorting will generally do the > right thing from a seek perspective). It's a disgusting hack, but it > literally gets you orders-of-magnitude performance improvments in many > real-life cases.
It does, so why isn't there a way to do this without the disgusting hack? (Your words, not mine :) ) E.g, wouldn't a aio_stat() allow simular or better speedups in a way that doesn't depend on ext2/3 internals? I bet it would make a significant difference from things like "ls -l" in large uncached directories and imap-servers with maildir? -- Ragnar Kjørstad Software Engineer Scali - http://www.scali.com Scaling the Linux Datacenter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/