> Alexander Viro wrote:
> > c) we have only two states for dentry - hashed and unhashed.
> > Life would be much easier if we had finer separation (e.g. special case
> > for dentry in process of lookup()). To be changed.
>
> Directory lookups following readdir(), and quite possibly following
> other lookups, would be faster if filesystems had the option of creating
> "dentry without inode", such that lookup would do iget() on them.
If anything, that will lead to readdir() flushing the heck out of dcache.
We had that system and we had dropped it.
> It only makes sense for filesystems where readdir() produces a key that
> it useful for a subsequent iget().
> I know there was some work on caching the pointer within a directory for
> lookup, and that B-trees will arrive for ext2 eventually. But neither
> of those can get the same performance as caching inode numbers, when
> seek times dominate inode read performance.
If you are doing massive lookups after readdir you are very likely to do
it sequentially. Moreover, you will create additional pressure on dcache
and I suspect that it will cancel all benefits. Allocation and balancing
are not cheap. And if you have big directories (otherwise it simply
doesn't make sense) you'll have to think about hash pollution too (albeit
it's less serious, IMO). Try it - you will get seriously more complex code
and a hit on performance.
-
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/