> By far the greatest overhead is reading the inodes at all!
>
> My program reads only about 5% (my guesstimate) of the inodes. The rest
> are elided by the "leaf optimisation" (also in GNU find) or, in my
> program, a heuristic-guided variant which finds equivalent solutions
> with fewer inode reads.
Details, please. In almost all cases when find(1) is applied to
really large trees it involves mode conditions (either -perm or -t), i.e.
lstat(2). What cases you are optimizing? And how are you doing it, BTW?
> So it is really bad to consider readdir() doing this at all the time,
> and an fcntl() to turn it on would be equally useless for anything
> except `ls -F' or `ls --colour'.
Or ls -l ;-)
> [ btw, did you see my patch for adding d_type behaviour to the readdir()
> callback for all filesystems? ]
Yes. I'ld still like to understand _what_ are you doing before commenting
on that. Are you sure that inode reads really dominate here? I would
expect large and nasty directory fiddling (quadratic by size) to take
quite some time...
BTW, lookup() is protected by lock on the parent, so that might be the
reason for contention.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/