From mboxrd@z Thu Jan 1 00:00:00 1970 From: "J. Bruce Fields" Subject: Re: [PATCH 10/10 v7] nfsd: Allows user un-mounting filesystem where nfsd exports base on Date: Thu, 16 Jul 2015 16:51:48 -0400 Message-ID: <20150716205148.GC10673@fieldses.org> References: <55A11010.6050005@gmail.com> <55A111A8.2040701@gmail.com> <20150713133934.6a4ef77d@noble> <20150715210756.GE21669@fieldses.org> <20150716094046.445c038b@noble> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Kinglong Mee , Al Viro , "linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Trond Myklebust To: NeilBrown Return-path: Content-Disposition: inline In-Reply-To: <20150716094046.445c038b@noble> Sender: linux-nfs-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: linux-fsdevel.vger.kernel.org On Thu, Jul 16, 2015 at 09:40:46AM +1000, NeilBrown wrote: > On Wed, 15 Jul 2015 17:07:56 -0400 "J. Bruce Fields" > 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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html