Messages in this thread | | | Date | Sun, 9 May 2004 21:03:16 +0530 | From | Dipankar Sarma <> | Subject | Re: dentry bloat. |
| |
On Sun, May 09, 2004 at 09:28:46AM +0200, Manfred Spraul wrote: > What's the prupose of d_move_count? > AFAICS it protects against a double rename: first to different bucket, > then back to original bucket. This changes the position of the dentry in > the hash chain and a concurrent lookup would skip entries. > d_lock wouldn't prevent that.
Actually, what may happen is that since the dentries are added in the front, a double move like that would result in hash chain traversal looping. Timing dependent and unlikely, but d_move_count avoided that theoritical possibility. It is not about skipping dentries which is safe because a miss would result in a real_lookup() anyway. If we do the comparison within d_lock, then atleast we are guaranteed to get the right file. The remaining question is whether we violate POSIX rename semantics in some twisted way.
> But I think d_bucket could be removed: for __d_lookup the test appears > to be redundant with the d_move_count test. The remaining users are not > performance critical, they could recalculate the bucket from d_parent > and d_name.hash.
Yes, afaics, d_move_count can effectively be used to work around the possibility of the dentry moving to a different hash bucket.
Thanks Dipankar - 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/
| |