On Tue, 16 Dec 2008 14:56:35 -0500
"J. Bruce Fields" <bfields@xxxxxxxxxxxx> wrote:
> > + if (result == 0) {
> > + if (nlmsvc_check_overlap(block))
> > + requeue = false;
>
> So these check_overlap()'s are in attempt to ensure that grants for
> overlapping ranges get sent back to the client in some given order?
> What order is that exactly? (Do we know that the existing order is
> right?)
>
No, the idea was to have this code walk the entire list of blocks and
grant any block that the lock completely covers. But, I think we need to
check and make sure that block doesn't conflict with another grant,
correct? That's what that function is intended to do.
> After thinking a little more: the interface is a lot simpler if it's
> just a simple request and reply (with the reply for a lock identical to
> the request). I believe that's more or less what gfs2 is already do
> internally, if we look at the posix lock upcalls it's making to
> userspace. So it shouldn't be hard to fix gfs2 to hand us back a lock
> that doesn't take into account any coalescing. If it needs to keep an
> extra (unmodified) copy of the lock around, that's OK.
>
> Did you try that and find a reason that doesn't work?
>
> --b.
>
Agreed. That would be much simpler, I think...
I didn't try that, though I did consider it before wandering down the
rabbit hole. Dave, any thoughts?
--
Jeff Layton <jlayton@xxxxxxxxxx>
--
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
