Messages in this thread | | | Date | Fri, 20 Feb 2004 19:48:22 +0100 | From | Ingo Molnar <> | Subject | Re: explicit dcache <-> user-space cache coherency, sys_mark_dir_clean(), O_CLEAN |
| |
* Linus Torvalds <torvalds@osdl.org> wrote:
> > there's another class of problems: is it an issue that directory renames > > that move this directory (higher up in the directory hierarchy of this > > directory) do not invalidate the cache? In that case there's no dnotify > > event either. > > This is one of the reasons why I worry about user-space caching. It's > just damn hard to get right.
this particular problem could be solved by walking down to the root dentry for every sys_manage_dir_cache() lookup and check that each dentry is still cache-valid. This involves some overhead, but it's still faster than doing the same from userspace. (ie. validating each previous path component at lookup time.) Since this doesnt change the dcache it ought to be doable via the rcu-read path and would thus still have pretty good SMP properties. [except when traversing mountpoints :-( ].
but this scheme also has other problems: who decides who is the 'cache manager'? What if there are two instances of fileservers both using the same fileset and also trying to do caching this way?
perhaps using a simple 64-bit generation counter would be better. Samba would get a new syscall to get the sum of each generation counter down to the root dentry - a total validation of the pathname. If the counter matches with that in the userspace cache entry then no need to re-create the cache. Such generation counters would be usable for multiple file servers as well. Hm?
> It's hard in kernel space too, of course, but we've had smart people > working on the dcache for years. So if we can sanely avoid > duplication, that would be a good thing.
i believe Samba already has what is in essence a duplication of the dcache. We could enable it to be fairly coherent, for Samba to be able to have an authorative 'does this file exist' answer without any excessive readdir()s.
Ingo - 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/
| |