On Thu, Jul 16, 2015 at 09:40:46AM +1000, NeilBrown wrote: > On Wed, 15 Jul 2015 17:07:56 -0400 "J. Bruce Fields" > <bfields@xxxxxxxxxxxx> wrote: > > > > Wow.... this is turning out to be a lot more complex that I imagined at > > > first (isn't that always the way!). > > > > > > There is a lot of good stuff here, but I think we can probably make it > > > simpler and so even better. > > > > I'm still not convinced that the expkey (Sorry, I meant an entry in the export cache, not the expkey cache.) > should have a dentry reference > > in the key in the first place. Fixing that would fix the immediate > > problem. > > ??? If we removed the dentry, how would you export a subdirectory of a > filesystem? I've been wondering if the export cache should really be keyed on the string representation of the path instead of the struct path. That's what the userspace interface uses. There's a related bug: if there are mountpoints at both /a and /a/b, then thanks to the lookup-underneath-mountpoint behavior of the server, an NFSv3 client looking that up will end up going underneath the first mountpoint and doing an export cache lookup for (vfsmnt, dentry) == (/, /a/b) When the server gets a response that starts with "/a/b", it interprets that as applying to the path (/a, /a/b), so doesn't recognize it as resolving the query about (/, /a/b). Well, at least I assume that's why I see "ls" hang if I run "ls /mnt/a/b" on the client. And there may be some better fix, but I always figured the root (hah) problem here was due to indexing the cache on struct path while the upcall interface uses the full path string. --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
