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! 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. --b. - 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
