On Fri, 8 Feb 2008 16:12:28 -0500 "J. Bruce Fields" <bfields@xxxxxxxxxxxx> wrote: > On Fri, Feb 08, 2008 at 03:54:14PM -0500, Jeff Layton wrote: > > Interesting. It's not clear me why the underlying filesystem would make > > any difference there. Though now that I look, it looks like fl_grant > > really only gets called from dlm code, and that queues up the block for > > an immediate grant callback attempt. So perhaps that's the reason. > > The asynchronous locking interface does something slightly cheesy for > blocking locks--instead of waiting for the filesystem to respond, it > just sends back a deny immediately (even if the lock might actually be > available), then responds later with a granted message when it discovers > it's available. > > That works, but we should make it just wait to send the reply to the > original lock request until we've got a real answer, as we do for > nonblocking lock requests. And in fact someone submitted a patch to do > that--I just haven't gotten the time to review it. Urp. > > So anyway the effect is that on ext3 this particular lock wouldn't have > required a grant reply, whereas on gfs2 it does. > > Of course, what this means is that we'd hit the same problem on ext3 too > if the lock request did in fact legitimately block. So grant callbacks > probably have never worked on ext3 over the loopback interface either. > Oops! > As best I can tell, the whole problem with rpc_pings was introduced when we moved everything to the rpcbind stuff. Before that we generally never did an rpc_ping when binding the client. This probably did work until that was introduced. > I bet nobody's ever noticed because we manage to recover by retrying the > lock after it's available (whereas in the gfs2 case the retry hits the > same problem). So in practice for ext3 this probably just means > blocking lock requests take a lot longer over loopback then they would > otherwise. And probably the only people that care about nlm performance > don't usually do local mounts like that. > -- Jeff Layton <jlayton@xxxxxxxxxx> - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
