> I actually think that the "start read-ahead for inode blocks when you do
> readdir" might be a bigger win, because that would be a _new_ kind of
> read-ahead that we haven't done before, and might improve performance for
> things like "ls -l" in the cold-cache situation..
This was exactly what I did in the example I gave Daniel, except
we went slightly further (ONLY if I/O was quiescent) and effectively
went through the readdir, if we found a directory, preloaded (effectively)
the blocks we'd need for a readdir() on that, and if we found a file,
preloaded the first few blocks (this will be harder if you've no
obvious logical map); before actually reading any of the stuff,
we'd get a list of the blocks to read, and sort it as per physical
layout. We also logically read ahead files as soon as they were
opened (we generally had the first few locks from the above
oepration). For directories with short files in, and/or recursive tree
operations, it was a big win. [It might be less of a win under Linux
as the peculiar environment this lived on had resource-fork-esque
stuff represented by directory like things.]
-- Alex Bligh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/