On Thu, Sep 03, 2015 at 04:35:37PM -0400, Jeff Layton wrote: > On Thu, 3 Sep 2015 16:20:16 -0400 > "J. Bruce Fields" <bfields@xxxxxxxxxxxx> wrote: > > > On Thu, Sep 03, 2015 at 03:54:17PM -0400, Jeff Layton wrote: > > > 2) getattrs: We're working around the problem with this new export > > > option, but if you don't use that then you can potentially deadlock > > > with NFS. It wants to take the i_mutex in its ->getattr operation but > > > knfsd calls vfs_getattr with that held to do post-op attrs. My initial > > > workaround was to drop the i_mutex before calling fh_getattr instead of > > > after, but then I hit the performance problem I described. > > > > > > 3) locking: proxying v3 locking is a painful mess. If the reexporter > > > reboots, it'll lose its lease on the main server, which will kick out > > > all of its state. At that point you can end up with another client > > > racing and getting your lock before the reexporter can come back up and > > > reclaim it. > > > > > > Our main use-case for this is pretty limited and doesn't involve file > > > locking (so far!). > > > > So this is the interest part, I guess.--b. > > > > Yeah. The locking one is a real bugger. We have a potential design for > a solution, but I'm not sure it'll be something we can open source. Actually it wasn't the locking I was curious about so much as the use case and whether it's something anyone else would care about. --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
